QA » openQA Project

Not sure if it's just backend/kubevirt.pm that will help or if we need a change on the level of openQA. kubevirt can provide management of ressources for multiple VMs. If we would just need to control the available ressources by the number of openQA worker instances where each corresponds to one VM there would be no significant gain.

Ideas I can think of:

• Still first create a "backend/kubevirt.pm" for a 1:1 VM mapping. This could help to get some experience first
• Likely an initial "kubevirt" backend could be very similar to the "svirt" backend
• Maybe the current approach of multiple assignments as for the directly chained jobs can be used to assign multiple jobs in a row to kubevirt and then we can try to assign all these to kubevirt as ressources are available
• Use the concept of "assignment" to workers to check if the requested ressources for VMs are available and unassign again if not, without failing the test jobs. Maybe this is even something we could use for the qemu backend?

Wait. Why should a kubevirt backend block a helm chart for the openQA webui?

okurz wrote:

Wait. Why should a kubevirt backend block a helm chart for the openQA webui?

I flipped the relation to match the Blocked state. But honestly I'm not sure why either should be blocked. Maybe we can discuss this in the standup tomorrow?

sure we can. But I agree with you that the two tickets are not blocking each other, either way :) I have removed that blocking relationship.