controllers: support addon artifact images

[ANJANA-ARK]

Add support for installing custom kernel/initrd artifacts from container images in DaemonSet mode. Introduces osc-kata-addons-install.sh script and ConfigMap-based configuration (kata-addon-artifacts).

Reuses extract_container_image from lib.sh. Minimal changes to existing flows. Provider-specific config updates (configuration-se.toml, configuration-tdx.toml, etc.) based on ConfigMap provider field.

[openshift-ci]

Hi @ANJANA-ARK. Thanks for your PR.

I'm waiting for a github.com 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. Regular contributors should join the org to skip this step.

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.

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.

[Pacho20]

Could you explain how this would be executed in the script? Currently, the controller cannot set upgrade as the action for the DaemonSet. Do you have plans to extend the controller to handle that?

[Pacho20]

Both the installation and uninstallation use "/etc/kata-containers/.addon-version". I don’t see /usr used anywhere else. I’m not very familiar with Kata - does it create this file? Otherwise, the upgrade would always call install_addons.

[beraldoleal]

username?

[beraldoleal]

are we introducing this new cm or should we use kataconfig? @gkurz any comments here?

[beraldoleal]

Do you mind expanding a bit on the comments why this version is needed? In which situation we could have OSC version installed X and here using Y?

[beraldoleal]

Do plan to add a specific log msg here? If not, this if is unnecessary.

[beraldoleal]

I haven't tested my proposal, but maybe a less verbose method, with two structures for optional and mandatory?

	var cm corev1.ConfigMap
	if err := r.Client.Get(context.Background(),
		types.NamespacedName{Name: "kata-addon-artifacts", Namespace: OperatorNamespace},
		&cm,
	); err != nil {
		if !errors.IsNotFound(err) {
			r.Log.Error(err, "Failed to get addon ConfigMap")
		}
		return nil
	}

	data := cm.Data

	// --- Mandatory variables ---
	mandatory := []struct {
		key, env string
	}{
		{"addonImage", "ADDON_IMAGE"},
	}

	var envs []corev1.EnvVar
	for _, v := range mandatory {
		val := data[v.key]
		if val == "" {
			return nil // mandatory missing → addon not configured
		}
		envs = append(envs, corev1.EnvVar{Name: v.env, Value: val})
	}

	// --- Optional variables ---
	optional := []struct {
		key, env string
	}{
		{"provider", "ADDON_PROVIDER"},
		{"kernelPath", "ADDON_KERNEL_PATH"},
		{"initrdPath", "ADDON_INITRD_PATH"},
		{"version", "ADDON_VERSION"},
	}

	for _, v := range optional {
		val := data[v.key]
		if v.key == "version" && val == "" {
			val = extractVersionFromImage(data["addonImage"])
		}
		if val != "" {
			envs = append(envs, corev1.EnvVar{Name: v.env, Value: val})
		}
	}

	r.Log.Info("Addon artifacts configured", "image", data["addonImage"])
	return envs

[gkurz]

AFAIK this is for IBM SE only and it is unlikely to change anytime soon. Let's keep it simple and drop that.

[gkurz]

It seems that all this logic could be replaced with a simple config drop in. Something like :

cat<<EOF>/etc/kata-containers/kata-se/config.d/coco-guest.toml
[hypervisor.qemu]
kernel = "${kernel_path}"
initrd = "${initrd_path}"
EOF