[PATCH V2 0/2] Add support for containerized root filesystems

[PATCH V2 0/2] Add support for containerized root filesystems

[Silvano Cirujano Cuesta]

This patch series provides support for containerized root filesystems,
for both target images and SDKs.

For containerized target images the new image type `container-img` has
been added.

For containerized SDKs the task `populate_sdk` has been extended.

Containerized root filesystems are easy to distribute and run, enabling
this way following scenarios:
 - Use ISAR to build container images meant to be run only in containers.
 - Use the same ISAR configuration to build images for containers, VMs
   and bare-metal.
 - Easy SDK distribution and "installation".
 - Quickly testing certain applications in the workstation using the
   target root filesystem.

In order to build containerized rootfilesystems `IMAGE_TYPE` as to be
`container-img`, additionally the container image format can be selected
with the variable `CONTAINER_FORMAT`. The default format is
`docker-archive`.

More information about its usage is documented in the file
docs/user_manual.md.

A PoC/demo of this functionality (only the SDK part) has been created
based on the project https://github.com/siemens/meta-iot2050.
Jan Kiszka already tested and liked it! =>
https://github.com/siemens/meta-iot2050/issues/86#issuecomment-768907845

In order to get a feeling about its usage (you need Docker or Podman),
follow these simple copy&paste instructions:
https://github.com/Silvanoc/meta-iot2050/blob/master/kas/BUILDING-SDK-CONTAINER.md#running-the-sdk
Build instructions are available in the upper part of that document.

Two new dependencies are required to create containerized root
filesystems (as specified in the documentation).

Typical container image management actions (e.g. push an image to a
container image regitry) are out of scope. Available tools (Docker,
Skopeo, Buildah, Podman,...) should be used for these actions.

A patch will follow this one to get the dependencies into the container
images being provided by the project
https://github.com/siemens/kas (for `kas-container`, for example).

Silvano Cirujano Cuesta (2):
  images: add support for container images
  docs: document creation of container images

 doc/user_manual.md                 | 127 +++++++++++++++++++++++++++++
 meta/classes/container-img.bbclass |  99 ++++++++++++++++++++++
 2 files changed, 226 insertions(+)
 create mode 100644 meta/classes/container-img.bbclass

-- 
2.30.0

[PATCH V2 1/2] images: add support for container images

[Silvano Cirujano Cuesta]

Add support for creation of container images with the build root
filesystems.

Extend also task "populate_sdk" to support the creation of a container image
containing the SDK.

Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
---
 meta/classes/container-img.bbclass | 99 ++++++++++++++++++++++++++++++
 1 file changed, 99 insertions(+)
 create mode 100644 meta/classes/container-img.bbclass

diff --git a/meta/classes/container-img.bbclass b/meta/classes/container-img.bbclass
new file mode 100644
index 0000000..85d9fb4
--- /dev/null
+++ b/meta/classes/container-img.bbclass
@@ -0,0 +1,99 @@
+# This software is a part of ISAR.
+# Copyright (C) Siemens AG, 2021
+#
+# SPDX-License-Identifier: MIT
+#
+# This class provides the tasks 'containerize_rootfs' and 'containerize_sdk'
+# to create container images containing the target rootfs and the SDK
+# respectively.
+
+CONTAINER_FORMAT ?= "docker-archive"
+
+containerize_rootfs() {
+    local cmd="/bin/dash"
+    local empty_tag="empty"
+    local full_tag="latest"
+    local oci_img_dir="${WORKDIR}/oci-image"
+    local rootfs="$1"
+    local rootfs_id="$2"
+
+    # prepare OCI container image skeleton
+    bbdebug 1 "prepare OCI container image skeleton"
+    rm -rf "${oci_img_dir}"
+    sudo umoci init --layout "${oci_img_dir}"
+    sudo umoci new --image "${oci_img_dir}:${empty_tag}"
+    sudo umoci config --image "${oci_img_dir}:${empty_tag}" \
+        --config.cmd="${cmd}"
+    sudo umoci unpack --image "${oci_img_dir}:${empty_tag}" \
+        "${oci_img_dir}_unpacked"
+
+    # add root filesystem as the flesh of the skeleton
+    sudo cp -a "${rootfs}"/* "${oci_img_dir}_unpacked/rootfs/"
+
+    # pack container image
+    bbdebug 1 "pack container image"
+    sudo umoci repack --image "${oci_img_dir}:${full_tag}" \
+        "${oci_img_dir}_unpacked"
+    sudo umoci remove --image "${oci_img_dir}:${empty_tag}"
+    sudo rm -rf "${oci_img_dir}_unpacked"
+
+    # no root needed anymore
+    sudo chown --recursive $(id -u):$(id -g) "${oci_img_dir}"
+
+    # convert the OCI container image to the desired format
+    image_name="isar-${rootfs_id}"
+    for image_type in ${CONTAINER_FORMAT} ; do
+        image_archive="${DEPLOY_DIR_IMAGE}/${rootfs_id}-${image_type}.tar"
+        bbdebug 1 "Creating container image type: ${image_type}"
+        case "${image_type}" in
+            "docker-archive" | "oci-archive")
+                if [ "${image_type}" = "oci-archive" ] ; then
+                    target="${image_type}:${image_archive}:latest"
+                else
+                    target="${image_type}:${image_archive}:${image_name}:latest"
+                fi
+                rm -f "${image_archive}" "${image_archive}.xz"
+                bbdebug 2 "Converting OCI image to ${image_type}"
+                skopeo --insecure-policy copy \
+                    "oci:${oci_img_dir}:${full_tag}" "${target}"
+                bbdebug 2 "Compressing image"
+                xz -T0 "${image_archive}"
+                ;;
+            "oci")
+                tar --create --xz --directory "${oci_img_dir}" \
+                    --file "${image_archive}.xz" .
+                ;;
+            "docker-daemon" | "containers-storage")
+                skopeo --insecure-policy copy \
+                    "oci:${oci_img_dir}:${full_tag}" \
+                    "${image_type}:${image_name}:latest"
+                ;;
+            *)
+                die "Unsupported format for containerize_rootfs: ${image_type}"
+                ;;
+        esac
+    done
+}
+
+do_container_image[stamp-extra-info] = "${DISTRO}-${MACHINE}"
+do_container_image[vardeps] += "CONTAINER_FORMAT"
+do_container_image(){
+    rootfs_id="${DISTRO}-${DISTRO_ARCH}"
+
+    bbnote "Generate container image in these formats: ${CONTAINER_FORMAT}"
+    containerize_rootfs "${IMAGE_ROOTFS}" "${rootfs_id}"
+}
+
+addtask container_image before do_image after do_image_tools
+
+do_container_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
+do_container_sdk[vardeps] += "CONTAINER_FORMAT"
+do_container_sdk(){
+    rootfs_id="sdk-${DISTRO}-${DISTRO_ARCH}"
+
+    bbnote "Generate containerized SDK in these formats: ${CONTAINER_FORMAT}"
+    containerize_rootfs "${SDKCHROOT_DIR}" "${rootfs_id}"
+}
+
+addtask container_sdk after do_populate_sdk
+
-- 
2.30.0

[PATCH V2 2/2] docs: document creation of container images

[Silvano Cirujano Cuesta]

Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
---
 doc/user_manual.md | 127 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 127 insertions(+)

diff --git a/doc/user_manual.md b/doc/user_manual.md
index a4f3d1d..6b72a16 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -19,6 +19,7 @@ Copyright (C) 2016-2019, ilbers GmbH
  - [Add a Custom Application](#add-a-custom-application)
  - [Enabling Cross-compilation](#isar-cross-compilation)
  - [Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)
+ - [Create a containerized ISAR SDK root filesystem](#create-a-containerized-isar-sdk-root-filesystem)
  - [Creation of local apt repo caching upstream Debian packages](#creation-of-local-apt-repo-caching-upstream-debian-packages)
 
 
@@ -84,6 +85,9 @@ If your host is >= buster, also install the following package.
 apt install python3-distutils
 ```
 
+If you want to generate containerized SDKs, also install the following packages: `umoci` and `skopeo`.
+Umoci is provided by Debian Buster and can be installed with `apt install umoci`, Skopeo is provided by Debian Bullseye/Unstable and has to be installed either manually downloading the DEB and installing it (no other packages required) or with `apt install -t bullseye skopeo` (if unstable/bullseye included in `/etc/apt/sources.list[.d]`).
+
 Notes:
 
 * BitBake requires Python 3.4+.
@@ -223,6 +227,54 @@ qemu-system-x86_64 -m 256M -nographic -bios edk2/Build/OvmfX64/RELEASE_*/FV/OVMF
 qemu-system-i386 -m 256M -nographic -hda tmp/deploy/images/qemui386/isar-image-base-debian-buster-qemui386.wic.img
 ```
 
+### Generate container image with root-filesystem
+
+A runnable container image is generated if you set IMAGE_TYPE to 'container-img'.
+Getting a container image can be the main purpose of an ISAR configuration, but not only.
+A container image created from an ISAR configuration meant for bare-metal or virtual machines can be helpfull to test certain applications which requirements (e.g. libraries) can be easily resolved in a containerized environment.
+
+Container images can be generated in different formats, selected with the variable `CONTAINER_FORMAT`. One or more (whitespace separated) of following options can be given:
+ - `docker-archive`: (default) an archive containing a Docker image that can be imported with [`docker import`](https://docs.docker.com/engine/reference/commandline/import/)
+ - `docker-daemon`: resulting container image is made available on the local Docker Daemon
+ - `containers-storage`: resulting container image is made available to tools using containers/storage back-end (e.g. Podman, CRIO, buildah,...)
+ - `oci-archive`: an archive containing an OCI image, mostly for archiving as seed for any of the above formats
+
+Following formats don't work if running `bitbake ...` (to build the image) from inside of a container (e.g. using `kas-container`): `docker-daemon` and `containers-storage`.
+It's technically possible, but requires making host resources (e.g. the Docker Daemon socket) accessible in the container.
+What can endanger the stability and security of the host.
+
+The resulting container image archives (only for `docker-archive` and `oci-archive`) are made available as `tmp/deploy/images/${MACHINE}/${DISTRO}-${DISTRO_ARCH}-${container_format}.tar.xz` (being `container_format` each one of the formats specified in `CONTAINER_FORMAT`).
+
+### Example
+
+ - Make the relevant environment variables available to the task
+
+For one-shot builds (use `local.conf` otherwise):
+
+```
+export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE IMAGE_TYPE CONTAINER_FORMAT"
+export IMAGE_TYPE="container-img"
+export CONTAINER_FORMAT="docker-archive"
+```
+
+ - Trigger creation of container image from root filesystem
+
+```
+bitbake mc:qemuarm-buster:isar-image-base
+```
+
+ - Load the container image into the Docker Daemon
+
+```
+xzcat build/tmp/deploy/images/qemuarm/debian-buster-armhf-docker-archive.tar.xz | docker load
+```
+
+ - Run a container using the container image (following commands starting with `#~:` are to be run in the container)
+
+```
+docker run --rm -ti --volume "$(pwd):/build" isar-buster-armhf:latest
+```
+
 ---
 
 ## Terms and Definitions
@@ -834,6 +886,81 @@ ii  crossbuild-essential-armhf           12.3                   all          Inf
 ~#
 ```
 
+## Create a containerized ISAR SDK root filesystem
+
+### Motivation
+
+Distributing and using the SDK root filesystem created following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)" becomes easier using container images (at least for those using containers anyway)
+A "containerized" SDK adds to those advantages of a normal SDK root filesystem the comfort of container images.
+
+### Approach
+
+Create container image with SDK root filesystem with installed cross-toolchain for target architecture and ability to install already prebuilt target binary artifacts.
+Developer:
+ - runs a container based on the resulting container image mounting the source code to be built,
+ - develops applications for target platform on the container and
+ - leaves the container getting the results on the mounted directory.
+
+### Solution
+
+A container image containing the SDK is generated if you set IMAGE_TYPE to 'container-img'.
+
+Container images can be generated in different formats, selected with the variable `CONTAINER_FORMAT`. One or more (space separated) of following options can be given:
+ - `docker-archive`: (default) an archive containing a Docker image that can be imported with [`docker import`](https://docs.docker.com/engine/reference/commandline/import/)
+ - `docker-daemon`: resulting container image is made available on the local Docker Daemon
+ - `containers-storage`: resulting container image is made available to tools using containers/storage back-end (e.g. Podman, CRIO, buildah,...)
+ - `oci-archive`: an archive containing an OCI image, mostly for archiving as seed for any of the above formats
+
+User manually triggers creation of SDK formats for his target platform by launching the task `do_populate_sdk` for target image, f.e.
+`bitbake -c do_populate_sdk mc:${MACHINE}-${DISTRO}:isar-image-base`.
+Packages that should be additionally installed into the SDK can be appended to `SDK_PREINSTALL` (external repositories) and `SDK_INSTALL` (self-built).
+
+Following formats don't work if running `bitbake -c do_populate_sdk ...` (to generate the containerized SDK) from inside of a container (e.g. using `kas-container`): `docker-daemon` and `containers-storage`.
+It's technically possible, but requires making host resources (e.g. the Docker Daemon socket) accessible in the container.
+What can endanger the stability and security of the host.
+
+The resulting SDK formats are archived into `tmp/deploy/images/${MACHINE}/sdk-${DISTRO}-${DISTRO_ARCH}-${sdk_format}.tar.xz` (being `sdk_format` each one of the formats specified in `CONTAINER_FORMAT`).
+The SDK container directory `/isar-apt` contains a copy of isar-apt repo with locally prebuilt target debian packages (for <HOST_DISTRO>).
+One may get into an SDK container and install required target packages with the help of `apt-get install <package_name>:<DISTRO_ARCH>` command.
+The directory with the source code to develop on should be mounted on the container (with `--volume <host-directory>:<container-directory>`) to be able to edit files in the host with an IDE and build in the container.
+
+### Example
+
+ - Make the relevant environment variables available to the task
+
+For one-shot builds (use `local.conf` otherwise):
+
+```
+export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE IMAGE_TYPE CONTAINER_FORMAT"
+export IMAGE_TYPE="container-img"
+export CONTAINER_FORMAT="docker-archive"
+```
+
+ - Trigger creation of SDK root filesystem
+
+```
+bitbake -c do_populate_sdk mc:qemuarm-buster:isar-image-base
+```
+
+ - Load the SDK container image into the Docker Daemon
+
+```
+xzcat build/tmp/deploy/images/qemuarm/sdk-debian-buster-armhf-docker-archive.tar.xz | docker load
+```
+
+ - Run a container using the SDK container image (following commands starting with `#~:` are to be run in the container)
+
+```
+docker run --rm -ti --volume "$(pwd):/build" isar-sdk-buster-armhf:latest
+```
+
+ - Check that cross toolchains are installed
+
+```
+:~# dpkg -l | grep crossbuild-essential-armhf
+ii  crossbuild-essential-armhf           12.3                   all          Informational list of cross-build-essential packages
+```
+
 ## Creation of local apt repo caching upstream Debian packages
 
 ### Motivation
-- 
2.30.0

Re: [PATCH V2 0/2] Add support for containerized root filesystems

[Jan Kiszka]

On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote:
> This patch series provides support for containerized root filesystems,
> for both target images and SDKs.
> 
> For containerized target images the new image type `container-img` has
> been added.
> 
> For containerized SDKs the task `populate_sdk` has been extended.
> 
> Containerized root filesystems are easy to distribute and run, enabling
> this way following scenarios:
>  - Use ISAR to build container images meant to be run only in containers.
>  - Use the same ISAR configuration to build images for containers, VMs
>    and bare-metal.
>  - Easy SDK distribution and "installation".
>  - Quickly testing certain applications in the workstation using the
>    target root filesystem.
> 
> In order to build containerized rootfilesystems `IMAGE_TYPE` as to be
> `container-img`, additionally the container image format can be selected
> with the variable `CONTAINER_FORMAT`. The default format is
> `docker-archive`.
> 

But you dropped control over building the SDK (and only the SDK) as
container, didn't you? Where did that SDK_FORMATS go?

Jan

> More information about its usage is documented in the file
> docs/user_manual.md.
> 
> A PoC/demo of this functionality (only the SDK part) has been created
> based on the project https://github.com/siemens/meta-iot2050.
> Jan Kiszka already tested and liked it! =>
> https://github.com/siemens/meta-iot2050/issues/86#issuecomment-768907845
> 
> In order to get a feeling about its usage (you need Docker or Podman),
> follow these simple copy&paste instructions:
> https://github.com/Silvanoc/meta-iot2050/blob/master/kas/BUILDING-SDK-CONTAINER.md#running-the-sdk
> Build instructions are available in the upper part of that document.
> 
> Two new dependencies are required to create containerized root
> filesystems (as specified in the documentation).
> 
> Typical container image management actions (e.g. push an image to a
> container image regitry) are out of scope. Available tools (Docker,
> Skopeo, Buildah, Podman,...) should be used for these actions.
> 
> A patch will follow this one to get the dependencies into the container
> images being provided by the project
> https://github.com/siemens/kas (for `kas-container`, for example).
> 
> Silvano Cirujano Cuesta (2):
>   images: add support for container images
>   docs: document creation of container images
> 
>  doc/user_manual.md                 | 127 +++++++++++++++++++++++++++++
>  meta/classes/container-img.bbclass |  99 ++++++++++++++++++++++
>  2 files changed, 226 insertions(+)
>  create mode 100644 meta/classes/container-img.bbclass
> 

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux

Re: [PATCH V2 0/2] Add support for containerized root filesystems

[Silvano Cirujano Cuesta]

On 09/02/2021 17:50, Jan Kiszka wrote:
> On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote:
>> This patch series provides support for containerized root filesystems,
>> for both target images and SDKs.
>>
>> For containerized target images the new image type `container-img` has
>> been added.
>>
>> For containerized SDKs the task `populate_sdk` has been extended.
>>
>> Containerized root filesystems are easy to distribute and run, enabling
>> this way following scenarios:
>>  - Use ISAR to build container images meant to be run only in containers.
>>  - Use the same ISAR configuration to build images for containers, VMs
>>    and bare-metal.
>>  - Easy SDK distribution and "installation".
>>  - Quickly testing certain applications in the workstation using the
>>    target root filesystem.
>>
>> In order to build containerized rootfilesystems `IMAGE_TYPE` as to be
>> `container-img`, additionally the container image format can be selected
>> with the variable `CONTAINER_FORMAT`. The default format is
>> `docker-archive`.
>>
> But you dropped control over building the SDK (and only the SDK) as
> container, didn't you? Where did that SDK_FORMATS go?
>
> Jan

Yes, if we want to have so much control, them we'll need at least 3 variables instead of 2. But I can introduce them, if desired.

Two of them to select the container format(s) to generate. For these I'd propose CONTAINER_FORMAT and SDK_FORMAT.

Another one to select the build of a container image for target, IMAGE_TYPE="container-img" would be my proposal.

The selection of containerized SDK would be implicit with the presence of a valid SDK_FORMAT. If that selection should be explicit, then a 4th variable would be needed.

I don't have a strong opinion on this, so simply make a wish.

  Silvano
>
>> More information about its usage is documented in the file
>> docs/user_manual.md.
>>
>> A PoC/demo of this functionality (only the SDK part) has been created
>> based on the project https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fmeta-iot2050&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=odtZPJwWKcqoXH5VrvsRtfqDzHS8wwYSS0M6WsNtzmU%3D&reserved=0.
>> Jan Kiszka already tested and liked it! =>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fmeta-iot2050%2Fissues%2F86%23issuecomment-768907845&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bXFPjdM8f5VwsFozf5vGHoMRwfo6kv2D%2FxvL76mtZtw%3D&reserved=0
>>
>> In order to get a feeling about its usage (you need Docker or Podman),
>> follow these simple copy&paste instructions:
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FSilvanoc%2Fmeta-iot2050%2Fblob%2Fmaster%2Fkas%2FBUILDING-SDK-CONTAINER.md%23running-the-sdk&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mONGFofFottYo4fVJ%2BMADZ%2Fx%2FZ6NmOj8w6POjw1FlAk%3D&reserved=0
>> Build instructions are available in the upper part of that document.
>>
>> Two new dependencies are required to create containerized root
>> filesystems (as specified in the documentation).
>>
>> Typical container image management actions (e.g. push an image to a
>> container image regitry) are out of scope. Available tools (Docker,
>> Skopeo, Buildah, Podman,...) should be used for these actions.
>>
>> A patch will follow this one to get the dependencies into the container
>> images being provided by the project
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fsiemens%2Fkas&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7Cb07a56105809427e9b7308d8cd1ac275%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637484862105605050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=X2OZUddd2z%2BWIRHIZuSdBXTI%2BJvr9Jh%2FXw%2BgrqO1Ni4%3D&reserved=0 (for `kas-container`, for example).
>>
>> Silvano Cirujano Cuesta (2):
>>   images: add support for container images
>>   docs: document creation of container images
>>
>>  doc/user_manual.md                 | 127 +++++++++++++++++++++++++++++
>>  meta/classes/container-img.bbclass |  99 ++++++++++++++++++++++
>>  2 files changed, 226 insertions(+)
>>  create mode 100644 meta/classes/container-img.bbclass
>>
-- 
Siemens AG, T RDA IOT SES-DE
Corporate Competence Center Embedded Linux

Re: [PATCH V2 0/2] Add support for containerized root filesystems

[Jan Kiszka]

On 09.02.21 18:37, Silvano Cirujano Cuesta wrote:
> 
> On 09/02/2021 17:50, Jan Kiszka wrote:
>> On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote:
>>> This patch series provides support for containerized root filesystems,
>>> for both target images and SDKs.
>>>
>>> For containerized target images the new image type `container-img` has
>>> been added.
>>>
>>> For containerized SDKs the task `populate_sdk` has been extended.
>>>
>>> Containerized root filesystems are easy to distribute and run, enabling
>>> this way following scenarios:
>>>  - Use ISAR to build container images meant to be run only in containers.
>>>  - Use the same ISAR configuration to build images for containers, VMs
>>>    and bare-metal.
>>>  - Easy SDK distribution and "installation".
>>>  - Quickly testing certain applications in the workstation using the
>>>    target root filesystem.
>>>
>>> In order to build containerized rootfilesystems `IMAGE_TYPE` as to be
>>> `container-img`, additionally the container image format can be selected
>>> with the variable `CONTAINER_FORMAT`. The default format is
>>> `docker-archive`.
>>>
>> But you dropped control over building the SDK (and only the SDK) as
>> container, didn't you? Where did that SDK_FORMATS go?
>>
>> Jan
> 
> Yes, if we want to have so much control, them we'll need at least 3 variables instead of 2. But I can introduce them, if desired.
> 
> Two of them to select the container format(s) to generate. For these I'd propose CONTAINER_FORMAT and SDK_FORMAT.
> 
> Another one to select the build of a container image for target, IMAGE_TYPE="container-img" would be my proposal.
> 
> The selection of containerized SDK would be implicit with the presence of a valid SDK_FORMAT. If that selection should be explicit, then a 4th variable would be needed.
> 
> I don't have a strong opinion on this, so simply make a wish.

There are two use cases (target image format = container, SDK =
container), and those should be independently configurable.

I was fine with your previous way of configuring the SDK_FORMATS. Here,
we should add container-img as another IMAGE_TYPE, further configurable
regarding its output formats (CONTAINER_FORMATS). And both use cases
should share container-img.bbclass for their common bits.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux