9c686c4bb0
There are multiple different tools/techniques to generate OCI images. Many of these techniques are part of more complex workflows, or have many options that are needed as part of a larger system or are needed to provide flexibility in the tooling (i.e. they construct the container as well as build the OCI image, or they can push directly to a registry, etc). What we want within the build context of bitbake/oe is to not duplicate work that is done by bitbake, the other image bbclasses or the runtime part of the ecosystem. This means only the construction of an image-spec v1.x image without dependencies on build, or execution of the container within a tool. We'd also like the tool to not pull in multiple, unused dependencies that must be built native/native-sdk, etc, to support the simple use case. The requirements above exclude (for now) tools such as skopeo, umoci, buildah, img, orca-build, kaniko, scratchbuild, etc. Leading us to a from-scratch implementation .. or enter sloci-image. sloci-image is a simple CLI for packing a rootfs into a single layer OCI image. It can easily be extended, or ported to other language implementations in the future. But it brings nearly no native dependencies and is a pure/clean implementation of the image spec that integrates nicely in an oe/bitbake environment. Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> |
||
|---|---|---|
| classes | ||
| conf | ||
| docs | ||
| files | ||
| recipes-containers | ||
| recipes-core | ||
| recipes-devtools | ||
| recipes-extended | ||
| recipes-graphics/xorg-xserver | ||
| recipes-kernel/linux | ||
| recipes-networking | ||
| .gitignore | ||
| COPYING.MIT | ||
| README | ||
meta-virtualization
This layer provides support for building Xen, KVM, Libvirt, and associated packages necessary for constructing OE-based virtualized solutions.
The bbappend files for some recipes (e.g. linux-yocto) in this layer need to have 'virtualization' in DISTRO_FEATURES to have effect. To enable them, add in configuration file the following line.
DISTRO_FEATURES_append = " virtualization"
If meta-virtualization is included, but virtualization is not enabled as a distro feature a warning is printed at parse time:
You have included the meta-virtualization layer, but
'virtualization' has not been enabled in your DISTRO_FEATURES. Some bbappend files
may not take effect. See the meta-virtualization README for details on enabling
virtualization support.
If you know what you are doing, this warning can be disabled by setting the following variable in your configuration:
SKIP_META_VIRT_SANITY_CHECK = 1
Depending on your use case, there are other distro features in meta-virtualization that may also be enabled:
- xen: enables xen functionality in various packages (kernel, libvirt, etc)
- kvm: enables KVM configurations in the kernel and autoloads modules
- aufs: enables aufs support in docker and linux-yocto
- x11: enable xen and libvirt functionality related to x11
- selinux: enables functionality in libvirt and lxc
- systemd: enable systemd services and unit files (for recipes for support)
- sysvinit: enable sysvinit scripts (for recipes with support)
Dependencies
This layer depends on:
URI: git://github.com/openembedded/openembedded-core.git branch: master revision: HEAD prio: default
URI: git://github.com/openembedded/meta-openembedded.git branch: master revision: HEAD layers: meta-oe meta-networking meta-filesystems meta-python
BBFILE_PRIORITY_openembedded-layer = "4"
Required for Xen XSM policy: URI: git://git.yoctoproject.org/meta-selinux branch: master revision: HEAD prio: default
Required for Ceph: URI: git://git.yoctoproject.org/meta-cloud-services branch: master revision: HEAD prio: default
Maintenance
Send pull requests, patches, comments or questions to meta-virtualization@yoctoproject.org
Maintainer: Bruce Ashfield bruce.ashfield@gmail.com
When sending single patches, please using something like: $ git send-email -1 -M --to meta-virtualization@yoctoproject.org --subject-prefix='meta-virtualization][PATCH'
License
All metadata is MIT licensed unless otherwise stated. Source code included in tree for individual recipes is under the LICENSE stated in each recipe (.bb file) unless otherwise stated.