<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/meta-virtualization.git/classes, branch mickledore</title>
<subtitle>Mirror of git.yoctoproject.org/meta-virtualization</subtitle>
<id>https://git.enea.com/cgit/linux/meta-virtualization.git/atom?h=mickledore</id>
<link rel='self' href='https://git.enea.com/cgit/linux/meta-virtualization.git/atom?h=mickledore'/>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/'/>
<updated>2023-03-20T13:06:47+00:00</updated>
<entry>
<title>conf: make container recipes parseable when virtualization is not set</title>
<updated>2023-03-20T13:06:47+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-03-20T13:04:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=df08c3643f4a8920cd6ce90b8d6a5099d7543e61'/>
<id>urn:sha1:df08c3643f4a8920cd6ce90b8d6a5099d7543e61</id>
<content type='text'>
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 &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>conf: introduce container configuration values</title>
<updated>2023-03-08T22:08:02+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-03-02T20:49:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=534e8b6ed7016aff57794dd66645556f5994d151'/>
<id>urn:sha1:534e8b6ed7016aff57794dd66645556f5994d151</id>
<content type='text'>
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 &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>containers: introduce container-host class</title>
<updated>2023-02-17T20:21:53+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2023-02-17T20:14:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=85beb6ba2810ebeda74bbb5dab405ec697b8da02'/>
<id>urn:sha1:85beb6ba2810ebeda74bbb5dab405ec697b8da02</id>
<content type='text'>
Introducing a small (at the moment) class that represents configuration
and processing required to prepare a target image to be a container
host.

A recipe that requires container configuration should inherit this
class, and the container-host-config package will be added as a
RDEPENDS, and install common configuration files.

In the future, additional functionality or dependencies will be added
here to synchronize the configuration of multiple container host
packages.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>oci-image: create two different tar outputs</title>
<updated>2023-02-10T17:36:11+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2022-12-09T23:21:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=16c89216dc24021f574e7740b9f8a6e4ed112b9c'/>
<id>urn:sha1:16c89216dc24021f574e7740b9f8a6e4ed112b9c</id>
<content type='text'>
The original tar output of the oci image followed the sloci-image
convention of putting the oci contents into a subdirectory in the
tarball. This allows it to work directly with skopeo, etc, but it
isn't the format that tools like podman expect in an oci-image
tarball.

We move the original format to have "-dir" in the name, and let
the more simply named one be the oci-image format as expcted by
various 3rd party tools

   1) image_name.tar: compatible with oci tar format, blobs and
      rootfs are at the top level. Can load directly from something like podman

   2) image_name-dir.tar: original format from meta-virt, is just a
      tar'd up oci image directory (compatible with skopeo :dir format)

We also fix a bug in the sloci-image backend, where the sloci tar
was removing the raw oci image directory leaving a dangling symlink.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>image-oci-umoci: add convenience symlink for oci image tar</title>
<updated>2022-12-07T21:12:33+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2022-11-07T16:22:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=c005181688c391f950d5feb79df00cde025cee9b'/>
<id>urn:sha1:c005181688c391f950d5feb79df00cde025cee9b</id>
<content type='text'>
We have been symlinking the -oci image directory for a while, but
we can also create a shorted convenience symlink for the tar'd
version of that directory.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>image-oci-sloci: add convenience symlinks in deploy</title>
<updated>2022-12-07T21:12:33+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2022-11-07T16:21:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=2aea6f9ab3f2bbec7cc3c162db5383fdd8ba29ea'/>
<id>urn:sha1:2aea6f9ab3f2bbec7cc3c162db5383fdd8ba29ea</id>
<content type='text'>
To sync the sloci OCI image backend with the umoci variant, create
shortened convenience symlinks for the image and image.tar in the
deploy directory.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>image-oci-umoci: add convenience symlink to latest image</title>
<updated>2022-09-12T20:45:26+00:00</updated>
<author>
<name>Bruce Ashfield</name>
<email>bruce.ashfield@gmail.com</email>
</author>
<published>2022-09-12T20:21:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=4254c4a732c03ea66689f941276ac62aaac6c632'/>
<id>urn:sha1:4254c4a732c03ea66689f941276ac62aaac6c632</id>
<content type='text'>
Symlink the date-time based image name, to just the imagename-oci.

This makes scripting use of the deployed container much simpler.

Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>image-oci-umoci: add parameter for stop signal</title>
<updated>2022-07-15T21:14:57+00:00</updated>
<author>
<name>Vasileios Anagnostopoulos</name>
<email>vasileios.anagnostopoulos@siemens.com</email>
</author>
<published>2022-07-12T12:26:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=fb14913e224ba97786bc9b192a8b6d4a8d1592b9'/>
<id>urn:sha1:fb14913e224ba97786bc9b192a8b6d4a8d1592b9</id>
<content type='text'>
Add an optional parameter that allows to override the stop
signal that is used.

Signed-off-by: Vasileios Anagnostopoulos &lt;vasileios.anagnostopoulos@siemens.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>image-oci-umoci: properly handle tags other than latest</title>
<updated>2022-07-15T21:14:57+00:00</updated>
<author>
<name>Pascal Bach</name>
<email>pascal.bach@siemens.com</email>
</author>
<published>2022-07-12T12:26:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=064a96fe1b3618370408c7a784abf035f0d56934'/>
<id>urn:sha1:064a96fe1b3618370408c7a784abf035f0d56934</id>
<content type='text'>
Signed-off-by: Pascal Bach &lt;pascal.bach@siemens.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
<entry>
<title>xen: Disable highmem on qemuarm</title>
<updated>2022-06-20T16:08:37+00:00</updated>
<author>
<name>Michal Orzel</name>
<email>michal.orzel@arm.com</email>
</author>
<published>2022-06-09T09:57:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.enea.com/cgit/linux/meta-virtualization.git/commit/?id=b9a94a5fb6f608d53ddbfe2a60cbc8a670922550'/>
<id>urn:sha1:b9a94a5fb6f608d53ddbfe2a60cbc8a670922550</id>
<content type='text'>
By default, highmem option is enabled for machine types later than
virt-2.12. This allows qemu to place devices and RAM in physical
address space above 32-bits. This can cause issues as according to the
documentation Xen supports up to 12GiB of physical address space.
Recently the issue was observed using runqemu, that was causing Linux
running on top of Xen to stall when trying to access ECAM space placed
by qemu at 256GiB mark. Even though this issue is most probably related
to QEMU and not Xen (the investigation showed that it can map ECAM
space correctly), it is best to avoid such issues by disabling highmem
on qemuarm.

Signed-off-by: Michal Orzel &lt;michal.orzel@arm.com&gt;
Reviewed-by: Bertrand Marquis &lt;bertrand.marquis@arm.com&gt;
Reviewed-by: Christopher Clark &lt;christopher.w.clark@gmail.com&gt;
Signed-off-by: Bruce Ashfield &lt;bruce.ashfield@gmail.com&gt;
</content>
</entry>
</feed>
