linux/meta-virtualization.git/classes, branch hardknott-next

cni: introduce cni networking bbclass

2021-03-16T03:15:42+00:00

Signed-off-by: Bruce Ashfield

xen: retire the Raspberry Pi sdcard class

2020-08-11T19:58:37+00:00

The sdcard class in the meta-raspberrypi layer is now extensible with support for adding files such as hypervisor binaries to the boot partition, so this layer can switch to use that and drop the custom sdcard bbclass. Uses the new RPI_SDIMG_EXTRA_DEPENDS and DEPLOYPAYLOAD variables, and: IMAGE_CLASS: sdcard_image-rpi-xen => sdcard_image-rpi IMAGE_FSTYPE: rpi-xen-sdimg => rpi-sdimg Please note that the filename suffix of the image is changed by this. Also apply _raspberrypi4-64 scoping to the Raspberry Pi settings. Signed-off-by: Christopher Clark Signed-off-by: Bruce Ashfield

xen, raspberry pi: add Xen-specific SD card class

2020-07-06T20:25:56+00:00

At the moment the regular meta-raspberrypi SD card class does not allow for optional inclusion of extra files in the SD card boot partition without requiring those same files be present in the root filesystem. This affects hypervisor binaries, such as Xen, which do not necessarily belong within the guest filesystem. As a workaround, inherit the sdcard_image-rpi.bbclass and clone the main IMAGE_CMD function, adding the Xen-specific deploy that is needed. This can be retired when the parent class has extensibility added. Signed-off-by: Christopher Clark Signed-off-by: Bruce Ashfield

xen: apply layer settings when xen DISTRO_FEATURE is enabled

2020-07-06T20:25:55+00:00

These settings are necessary for Xen and enabling them here, using the same mechanism that is used by k8s in this layer, simplifies building images for Xen. - Ensure that Xen mode is enabled in QEMU. - On ARM platforms: enable Flattened Device Tree (FDT) support. Signed-off-by: Christopher Clark Signed-off-by: Bruce Ashfield

conf: defer DISTRO_FEATURE check to bbclass processing

2020-02-10T15:28:38+00:00

We were using USER_CLASS loading to allow conditional checking on DISTRO_FEATURES, which triggered distro feature specific version pinning. It was found that DISTRO_FEATURES set in local.conf is not consistently available at layer.conf parse time, hence our checks were not always working as expected (i.e. the version files are not included). If we move the DISTRO_FEATURE check to the bbclasses, and use it to trigger the include, we should have a consistent set of variable resolution and consistent behaviour. Signed-off-by: Bruce Ashfield

conf: add k8s distro feature

2019-12-10T07:25:21+00:00

Add support for a new distro feature to control kubernetes versions and related configuration. Signed-off-by: Bruce Ashfield

conf: fix meta-virt version / config include

2019-12-06T18:51:57+00:00

As was reported: https://lists.yoctoproject.org/g/meta-virtualization/message/4173?p=,,,20,0,0,0::Created,,conf%2Flayer.conf+is+broken,20,2,0,61269733 The conditional include of the meta-virt versions and config was not working properly due to parse time constraints. This commit fixes that by following the example of the meta-cube layer and instead using a user bbclass to load the .inc file after distro/distro features have been resolved by bitbake. Signed-off-by: Bruce Ashfield

containers: introduce image-oci

2019-02-27T16:46:25+00:00

This image class creates an oci image spec directory from a generated rootfs. The contents of the rootfs do not matter (i.e. they need not be container optimized), but by using the container image type and small footprint images, we can create directly executable container images. Once the tarball (or oci image directory) has been created of the OCI image, it can be manipulated by standard tools. For example, to create a runtime bundle from the oci image, the following can be done: Assuming the image name is "container-base": If the oci image was a tarball, extract it (skip, if a directory is being directly used) % tar xvf container-base--.rootfs-oci-latest-x86_64-linux.oci-image.tar And then create the bundle: % oci-image-tool create --ref name=latest container-base--.rootfs-oci container-base-oci-bundle Or to copy (push) the oci image to a docker registry, skopeo can be used (vary the tag based on the created oci image: % skopeo copy --dest-creds : oci:container-base--:latest docker://zeddii/container-base The following image variables are available to customize the details of the constructed image (defaults as shown): OCI_IMAGE_AUTHOR ?= "${PATCH_GIT_USER_NAME}" OCI_IMAGE_AUTHOR_EMAIL ?= "${PATCH_GIT_USER_EMAIL}" OCI_IMAGE_TAG ?= "latest" OCI_IMAGE_RUNTIME_UID ?= "" OCI_IMAGE_ARCH ?= "${TARGET_ARCH}" OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE_FEATURES'), d)}" OCI_IMAGE_ENTRYPOINT ?= "sh" OCI_IMAGE_ENTRYPOINT_ARGS ?= "" OCI_IMAGE_WORKINGDIR ?= "" //List of ports to expose from a container running this image: //PORT[/PROT] // format: /tcp, /udp, or (same as /tcp). OICI_IMAGE_PORTS ?= "" // key=value list of labels OCI_IMAGE_LABELS ?= "" // key=value list of environment variables OCI_IMAGE_ENV_VARS ?= "" Signed-off-by: Bruce Ashfield

sanity-meta-virt: Watch for SanityCheck event

2017-10-13T01:59:51+00:00

The ConfigParsed event is raised multiple times during a build which resulted in the sanity warning appearing up to 4 times per build. Instead we should be watching for the SanityCheck event (this is what the sanity checks in oe-core watch for). Signed-off-by: Paul Barker Signed-off-by: Bruce Ashfield

sanity-meta-virt: Make skip variable name layer specific

2017-10-13T01:59:51+00:00

The variable used to skip the sanity check should be named in a layer specific way. This will ensure there is no confusion if other layers use a similar sanity check. Signed-off-by: Paul Barker Signed-off-by: Bruce Ashfield