kola: add KubeVirt platform support by qinqon · Pull Request #4507 · coreos/coreos-assembler

qinqon · 2026-03-26T09:36:07Z

Summary

Add a new kubevirt platform to kola for testing CoreOS on KubeVirt VMs
Enable end-to-end testing of afterburn's KubeVirt metadata provider (ConfigDrive and NoCloud)
Extend external test framework to support network data files

Details

Platform implementation

API wrapper using sigs.k8s.io/controller-runtime client + kubevirt.io/api types (lightweight alternative to kubevirt.io/client-go)
SSH access via WebSocket port-forward through the KubeVirt API server (no virtctl binary dependency)
containerDisk support for FCOS images (cosa already builds these)
Per-test CloudInitType and NetworkData via MachineOptions

Closes #4508

External test framework

network_data.json in test dir → ConfigDrive cloud-init type (OpenStack convention)
network-config in test dir → NoCloud cloud-init type (cloud-init convention)
Silently ignored on platforms that don't support network data (qemu, aws, etc.)

New CLI flags

--kubevirt-kubeconfig     Path to kubeconfig
--kubevirt-namespace      Kubernetes namespace for VMs
--kubevirt-image          Container disk image pull spec
--kubevirt-cloud-init-type  Cloud-init type: configdrive or nocloud
--kubevirt-memory         VM memory (default 2Gi)
--kubevirt-cpus           VM CPUs (default 2)

New built-in tests

fcos.metadata.kubevirt.configdrive — verify afterburn metadata with ConfigDrive
fcos.metadata.kubevirt.nocloud — verify afterburn metadata with NoCloud

Test plan

go build ./mantle/cmd/kola/... compiles clean
go vet passes
Tested kola spawn against a kind cluster with KubeVirt — VM boots, SSH works through WebSocket tunnel
Tested kola run fcos.metadata.kubevirt.configdrive — PASS
Test kola run fcos.metadata.kubevirt.nocloud
Test external test with network_data.json file
Test external test with network-config file
Vendor directory completeness (go mod vendor)

TODO

We may need a mechanism to specify kubevirt VMs inetrfaces and network since that may be needed to propertly tests afterburn network data support.

🤖 Generated with Claude Code

openshift-ci · 2026-03-26T09:36:19Z

Hi @qinqon. Thanks for your PR.

I'm waiting for a coreos member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

gemini-code-assist

Code Review

This pull request integrates KubeVirt as a new platform into the mantle/kola testing framework, enabling VM lifecycle management and SSH port forwarding for KubeVirt-based tests. The changes include adding KubeVirt-specific options, API implementations, and machine/cluster logic. Review feedback highlights several areas for improvement: the VM deletion polling loop should specifically check for NotFound errors to prevent premature termination, rand.Read failures for VM name generation should panic to ensure unique names, and there are opportunities to refactor duplicated code for handling network data and KubeVirt metadata verification to improve conciseness and maintainability. Additionally, the Kubernetes config loading logic could be simplified for better readability.

gemini-code-assist · 2026-03-26T09:39:14Z

mantle/platform/api/kubevirt/api.go

+		if err != nil {
+			return true, nil // Gone
+		}


The current implementation incorrectly assumes that any error from a.client.Get means the VM is gone. This could lead to premature termination of the polling loop if a transient error occurs. You should specifically check for a NotFound error.

You'll need to add an import for k8s.io/apimachinery/pkg/api/errors as apierrors.

if err != nil { if apierrors.IsNotFound(err) { return true, nil // Gone } return false, err // Propagate other errors to stop polling. }

gemini-code-assist · 2026-03-26T09:39:14Z

mantle/platform/machine/kubevirt/cluster.go

+	if _, err := rand.Read(b); err != nil {
+		plog.Errorf("failed to generate a random vmname: %v", err)
+	}


If rand.Read fails, the error is logged but the function continues with a zero-filled byte slice. This will result in non-unique VM names and could cause test flakiness. Since this function doesn't return an error, it should panic on failure to prevent creating VMs with predictable names.

Suggested change

if _, err := rand.Read(b); err != nil {

plog.Errorf("failed to generate a random vmname: %v", err)

}

if _, err := rand.Read(b); err != nil {

panic(fmt.Sprintf("failed to generate a random vmname: %v", err))

}

gemini-code-assist · 2026-03-26T09:39:15Z

mantle/kola/harness.go

+		} else if isreg && c.Name() == "network_data.json" {
+			if cloudInitType != "" {
+				return fmt.Errorf("found both network_data.json and network-config in %s; use only one", dir)
+			}
+			v, err := os.ReadFile(filepath.Join(dir, c.Name()))
+			if err != nil {
+				return errors.Wrapf(err, "reading %s", c.Name())
+			}
+			networkData = string(v)
+			cloudInitType = "configdrive"
+		} else if isreg && c.Name() == "network-config" {
+			if cloudInitType != "" {
+				return fmt.Errorf("found both network_data.json and network-config in %s; use only one", dir)
+			}
+			v, err := os.ReadFile(filepath.Join(dir, c.Name()))
+			if err != nil {
+				return errors.Wrapf(err, "reading %s", c.Name())
+			}
+			networkData = string(v)
+			cloudInitType = "nocloud"


There's some code duplication in handling network_data.json and network-config. You can refactor this to make it more concise and maintainable by combining the logic into a single if block.

Suggested change

} else if isreg && c.Name() == "network_data.json" {

if cloudInitType != "" {

return fmt.Errorf("found both network_data.json and network-config in %s; use only one", dir)

}

v, err := os.ReadFile(filepath.Join(dir, c.Name()))

if err != nil {

return errors.Wrapf(err, "reading %s", c.Name())

}

networkData = string(v)

cloudInitType = "configdrive"

} else if isreg && c.Name() == "network-config" {

if cloudInitType != "" {

return fmt.Errorf("found both network_data.json and network-config in %s; use only one", dir)

}

v, err := os.ReadFile(filepath.Join(dir, c.Name()))

if err != nil {

return errors.Wrapf(err, "reading %s", c.Name())

}

networkData = string(v)

cloudInitType = "nocloud"

} else if isreg && (c.Name() == "network_data.json" || c.Name() == "network-config") {

if cloudInitType != "" {

return fmt.Errorf("found both network_data.json and network-config in %s; use only one", dir)

}

v, err := os.ReadFile(filepath.Join(dir, c.Name()))

if err != nil {

return errors.Wrapf(err, "reading %s", c.Name())

}

networkData = string(v)

if c.Name() == "network_data.json" {

cloudInitType = "configdrive"

} else {

cloudInitType = "nocloud"

}

gemini-code-assist · 2026-03-26T09:39:15Z

mantle/kola/tests/metadata/contents.go

+func verifyKubeVirtConfigDrive(c cluster.TestCluster) {
+	opts := platform.MachineOptions{
+		CloudInitType: "configdrive",
+	}
+	_, err := c.NewMachineWithOptions(enableMetadataService, opts)
+	if err != nil {
+		c.Fatalf("Unable to create machine: %v", err)
+	}
+	verify(c, "AFTERBURN_KUBEVIRT_INSTANCE_ID", "AFTERBURN_KUBEVIRT_HOSTNAME")
+}
+
+func verifyKubeVirtNoCloud(c cluster.TestCluster) {
+	opts := platform.MachineOptions{
+		CloudInitType: "nocloud",
+	}
+	_, err := c.NewMachineWithOptions(enableMetadataService, opts)
+	if err != nil {
+		c.Fatalf("Unable to create machine: %v", err)
+	}
+	verify(c, "AFTERBURN_KUBEVIRT_INSTANCE_ID", "AFTERBURN_KUBEVIRT_HOSTNAME")
+}


The functions verifyKubeVirtConfigDrive and verifyKubeVirtNoCloud are nearly identical. To improve maintainability and reduce code duplication, you could extract the common logic into a helper function.

For example:

func verifyKubeVirt(c cluster.TestCluster, cloudInitType string) { opts := platform.MachineOptions{ CloudInitType: cloudInitType, } _, err := c.NewMachineWithOptions(enableMetadataService, opts) if err != nil { c.Fatalf("Unable to create machine: %v", err) } verify(c, "AFTERBURN_KUBEVIRT_INSTANCE_ID", "AFTERBURN_KUBEVIRT_HOSTNAME") } func verifyKubeVirtConfigDrive(c cluster.TestCluster) { verifyKubeVirt(c, "configdrive") } func verifyKubeVirtNoCloud(c cluster.TestCluster) { verifyKubeVirt(c, "nocloud") }

gemini-code-assist · 2026-03-26T09:39:15Z

mantle/platform/api/kubevirt/api.go

+	if opts.Kubeconfig != "" {
+		config, err = clientcmd.BuildConfigFromFlags("", opts.Kubeconfig)
+	} else {
+		// Try in-cluster first, fall back to default kubeconfig
+		config, err = rest.InClusterConfig()
+		if err != nil {
+			loadingRules := clientcmd.NewDefaultClientConfigLoadingRules()
+			configOverrides := &clientcmd.ConfigOverrides{}
+			config, err = clientcmd.NewNonInteractiveDeferredLoadingClientConfig(
+				loadingRules, configOverrides).ClientConfig()
+		}
+	}


The logic for loading the Kubernetes config can be simplified by using clientcmd.NewDefaultClientConfigLoadingRules more directly. This will make the code cleaner and more idiomatic.

loadingRules := clientcmd.NewDefaultClientConfigLoadingRules() if opts.Kubeconfig != "" { loadingRules.ExplicitPath = opts.Kubeconfig } configOverrides := &clientcmd.ConfigOverrides{} config, err = clientcmd.NewNonInteractiveDeferredLoadingClientConfig( loadingRules, configOverrides).ClientConfig()

Add a new "kubevirt" platform to kola for testing CoreOS on KubeVirt VMs. This enables end-to-end testing of afterburn's KubeVirt metadata provider, supporting both ConfigDrive and NoCloud cloud-init types. Platform implementation: - API wrapper using controller-runtime client + kubevirt.io/api types (lightweight alternative to kubevirt.io/client-go) - SSH access via WebSocket port-forward through the KubeVirt API server (no virtctl binary dependency) - containerDisk support for FCOS images (cosa already builds these) - Per-test CloudInitType and NetworkData via MachineOptions External test framework: - Detect network_data.json in test dir -> ConfigDrive cloud-init type - Detect network-config in test dir -> NoCloud cloud-init type - File naming follows real-world conventions (OpenStack / cloud-init) - Error if both files present in the same test directory - Silently ignored on platforms that don't support network data New CLI flags: --kubevirt-kubeconfig, --kubevirt-namespace, --kubevirt-image, --kubevirt-cloud-init-type, --kubevirt-memory, --kubevirt-cpus New tests: fcos.metadata.kubevirt.configdrive fcos.metadata.kubevirt.nocloud Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Add vendored dependencies for the new KubeVirt kola platform: - kubevirt.io/api v1.8.0 - sigs.k8s.io/controller-runtime v0.23.3 - k8s.io/client-go v0.35.3 - k8s.io/apimachinery v0.35.3 - k8s.io/api v0.35.3 - github.com/gorilla/websocket v1.5.4 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

travier · 2026-03-26T10:54:08Z

Let's use #4508 to track this. Parent issue in FCOS: coreos/fedora-coreos-tracker#1432

Add a workflow that builds a Fedora CoreOS KubeVirt OCI archive image using coreos-assembler. Runs on pull requests and can be triggered manually via workflow_dispatch. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

cosa init fails when the working directory is not empty. Use a separate temp directory for the cosa build and copy artifacts back for upload. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

openshift-ci · 2026-03-31T10:31:43Z

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

openshift-ci bot added the needs-ok-to-test label Mar 26, 2026

qinqon force-pushed the kubevirt-kola-platform branch from 52d3ba6 to 9eedd3d Compare March 26, 2026 09:36

gemini-code-assist bot reviewed Mar 26, 2026

View reviewed changes

qinqon and others added 2 commits March 26, 2026 10:47

qinqon force-pushed the kubevirt-kola-platform branch from 9eedd3d to 65687fd Compare March 26, 2026 09:48

qinqon mentioned this pull request Mar 26, 2026

kola: Add support for Kubevirt #4508

Open

qinqon and others added 2 commits March 26, 2026 12:28

ci: fix KubeVirt workflow by using separate build directory

cb2dd1c

cosa init fails when the working directory is not empty. Use a separate temp directory for the cosa build and copy artifacts back for upload. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

openshift-ci bot added the needs-rebase label Mar 31, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

kola: add KubeVirt platform support#4507

kola: add KubeVirt platform support#4507
qinqon wants to merge 4 commits intocoreos:mainfrom
qinqon:kubevirt-kola-platform

qinqon commented Mar 26, 2026 •

edited

Loading

Uh oh!

openshift-ci bot commented Mar 26, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Mar 26, 2026

Uh oh!

gemini-code-assist bot Mar 26, 2026

Uh oh!

gemini-code-assist bot Mar 26, 2026

Uh oh!

gemini-code-assist bot Mar 26, 2026

Uh oh!

gemini-code-assist bot Mar 26, 2026

Uh oh!

travier commented Mar 26, 2026

Uh oh!

openshift-ci bot commented Mar 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

qinqon commented Mar 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Details

Platform implementation

External test framework

New CLI flags

New built-in tests

Test plan

TODO

Uh oh!

openshift-ci bot commented Mar 26, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Mar 26, 2026

Choose a reason for hiding this comment

Uh oh!

travier commented Mar 26, 2026

Uh oh!

openshift-ci bot commented Mar 31, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

qinqon commented Mar 26, 2026 •

edited

Loading