# Mantle to start KubeVirt VMs ## Summary: Support something like kola run -p kubevirt --kubevirt-kubeconfig /path/to/kubeconfig --container=quay.io/fedora/fedora-coreos-kubevirt:stable --build=XYZ - Copied in from https://github.com/coreos/fedora-coreos-tracker/issues/1432#issuecomment-1538355053 - Add support to mantle/kola to start/test kubevirt VMs - Add a `kola-kubevirt` pipeline job that will upload the container to the registry in cluster and then run kola tests. - this includes figuring out what credentials we can use to push the container and start the VMs --- ## TODO list - Adding a KubeVirt API to /home/gursewak/work/code/coreos-assembler/mantle/platform/api - adding the kubevirt platform - start an instance with an Ignition config that we created - delete an instance - networking (this one might be tricky) - we use SSH to talk with machines to run the tests - we usually assume IP addresses are public - for kubevirt I'm not sure how to reach the instances using a "public" IP - there might be some code we need to add to expose a public SSHable interface - might be able to reference the gangplank code to see what libraries to use for talking to kubernetes/OpenShift and also examples of how to interact with them. - https://github.com/coreos/coreos-assembler/blob/main/gangplank/internal/ocp/cosa-pod.go - Add cmd/ore support for KubeVirt - `cmd/ore/kubevirt.go` and `cmd/ore/kubevirt/kubevirt.go` - Add KubeVirt support in mantle/cmd/kola/kola.go - add things like --kubevirt-kubeconfig here - Add needed options for KubeVirt in mantle/cmd/kola/options.go --- - In the pipeline job: - We will mirror what we do for some other tests (look at kola-openstack.Jenkinsfile) where we grab the image, upload it, test, then delete the image. - Image uploading - can we use the same credential for image uploading as we do for testing? - skopeo cp /path/to/file.ociarchve example.com/fcos:38.20230101.0.1 - Run the test - Delete the image from the registry - Do we use the same `fedora-coreos-pipeline` namespace or do we create a new project specifically for kubevirt testing? - pros - less setup (less credentials to manage) - don't have to ask someone for a new namespace (both upstream and downstream) - cons - pollutes the namespace a bit (we need to make sure VMs don't get left running)