linux/meta-virtualization.git/conf/layer.conf, branch scarthgap-5.0.5

conf/layer: add scarthgap compatibility

2024-03-15T17:16:33+00:00

Signed-off-by: Bruce Ashfield

conf: drop mickledore, only specify nanbield

2023-09-15T16:10:00+00:00

- mickledore was incorrectly spelled - we aren't actively going to test both branches with master, so go to only nanbield If there's demaand, and test results to support it, we can reconsider later. Signed-off-by: Bruce Ashfield

conf: update compatibility to match oe-core

2023-09-11T14:38:08+00:00

OE Core has bumped to the next version, we update to match. For now, we keep both mickledore and nanbield as compatible while progressing towards release. Signed-off-by: Bruce Ashfield

layer.conf: use docker-moby as preferred provider

2023-06-07T20:39:24+00:00

docker-ce has been deprecated, so switch to docker-moby as the preferred provider. Signed-off-by: Chen Qi 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

conf: mark layer compatible with mickledore

2023-01-04T01:24:47+00:00

Signed-off-by: Bruce Ashfield

layer.conf: set langdale compatibility

2022-09-30T03:08:52+00:00

Signed-off-by: Bruce Ashfield

conf: drop honister from compatibility

2022-02-22T00:31:32+00:00

The variable renames in OE core are parse errors, not warnings, so maintaining compatibility for both honister and kirkstone in the same branch isn't feasible. So we drop honister in preparation for release. Signed-off-by: Bruce Ashfield

conf: add kirkstone to layer compatibility

2022-02-18T13:59:50+00:00

Signed-off-by: Bruce Ashfield

config: introduce hostname generation hooks

2021-12-13T20:59:35+00:00

Overriding hostname in a .conf file, via base-files: HOST_NAME="k3s-host" hostname_pn-base-files = "${HOST_NAME}" Is always a valid option, but if it is not configured, we can easily have two hosts with the same name on the network, confusing adddress assignement, etc. This commit introduces a way to generate a unique hostname based on the uuid of the build host, and the machine being built. If virt-unique-hostname is added to IMAGE_FEATURES, like the following: IMAGE_FEATURES += "virt-unique-hostname" IMAGE_FEATURES[validitems] += "virt-unique-hostname" Then a rootfs postprocessing hook will override hostnae to something unique. Note: this means your image will be reproducible on a single builder, but not between them. Signed-off-by: Bruce Ashfield