linux/meta-virtualization.git/classes/meta-virt-container-cfg.bbclass, branch master-next

container-registry: make IMAGE_FEATURES local to image recipes

2026-03-12T17:29:17+00:00

Remove the global IMAGE_FEATURES[validitems] registration entirely. Setting it in layer.conf or a globally-inherited bbclass changes the varflag value, which gets pulled into the signature of every recipe that depends on IMAGE_FEATURES — causing yocto-check-layer signature change failures. Image recipes that use the container-registry feature already set IMAGE_FEATURES[validitems] locally (e.g. container-image-host.bb). Users who want the feature in their own images add the one-liner: IMAGE_FEATURES[validitems] += "container-registry" Signed-off-by: Bruce Ashfield

container-registry: make IMAGE_FEATURES conditional on distro features

2026-03-11T23:34:27+00:00

Move the container-registry IMAGE_FEATURES[validitems] registration from layer.conf into meta-virt-container-cfg.bbclass where it can be gated on DISTRO_FEATURES. The validitems varflag is now only registered when vcontainer or virtualization is in DISTRO_FEATURES. layer.conf is parsed before distro features are known, so inline Python cannot be used there. The bbclass is loaded via USER_CLASSES (deferred parsing) and already handles container profile configuration. Signed-off-by: Bruce Ashfield

conf: make container recipes parseable when virtualization is not set

2023-03-20T13:06:47+00:00

The container stack flexibilty features set defaults (like other parts of the layer) when 'virtualization' is in the distro features. That reqirement means that the recipes fail parsing and QA checks when the distro feature isn't enabled. The defaults are currently safe for a virtualization enabled and disabled configuration, so we include them in either case. Signed-off-by: Bruce Ashfield

conf: introduce container configuration values

2023-03-08T22:08:02+00:00

From the configuration file itself: These variables represent groupings of functionality in the CNCF landscape. In particular, they are areas where there is a choice between more than one implementation or an area where abstraction is beneficial. The contents of the variables are are runtime components that recipes may use for RDEPENDS. Build dependencies are not typically flexible, so do not currently have DEPENDS equivalents for the components (i.e. DEPENDS on runc versus crun). Distro features such as kubernetes or other container stacks can be used to set different defaults for these variables. Note: these are "global" values, since they represent choices. If more than of a grouping is required on target, then the variable can be appended or set to multiple values. That being said, Recipes should generally agree on the values, hence the global namespace. Recipe specific choices can still be done, but they risk conflicting on target or causing runtime issues / errors. ## CNCF "components" # engines: docker-ce/docker-moby, virtual-containerd, cri-o, podman VIRTUAL-RUNTIME_container_engine ??= "podman" # runtime: runc, crun, runv, runx VIRTUAL-RUNTIME_container_runtime ??= "virtual-runc" # networking: cni, netavark VIRTUAL-RUNTIME_container_networking ??= "cni" # dns: cni, aardvark-dns VIRTUAL-RUNTIME_container_dns ??= "cni" # orchestration: k8s, k3s VIRTUAL-RUNTIME_container_orchestration ??= "k3s" ## Kubernetes terminology "components" VIRTUAL-RUNTIME_cri ??= "containerd" VIRTUAL-RUNTIME_cni ??= "cni" Signed-off-by: Bruce Ashfield