* [PATCH 0/2] Add support for containerized SDKs
@ 2021-02-05 9:08 Silvano Cirujano Cuesta
2021-02-05 9:08 ` [PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
2021-02-05 9:08 ` [PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta
0 siblings, 2 replies; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 9:08 UTC (permalink / raw)
To: isar-users
This patch series extends the SDK creation task `populate_sdk` to enable
the creation of container images (different formats that can be
simultaneously generated supported) providing the SDK. Containerized
SDKs are easy to distribute and run and are therefore quickly spreading.
The SDK format available until this patch (.tar.xz of SDK rootfs that
can be chrooted to) remains available and is the default. Even for those
wanting to use the here called `tar-xz` format it's possible to use
container images as "packaging" medium (simple to get tools -script,
skopeo,...- can help on this, if needed).
More information about its usage is documented in the file
docs/user_manual.md.
A PoC/demo of this functionality 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 SDKs (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.
This patch series addresses the comments and concerns raised in the RFC
called "support generation of sdk container images".
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):
sdk: support creation of container image
docs: document usage of sdk container images
doc/user_manual.md | 79 +++++++++++++++++
meta/classes/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
2 files changed, 176 insertions(+), 7 deletions(-)
--
2.30.0
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] sdk: support creation of container image
2021-02-05 9:08 [PATCH 0/2] Add support for containerized SDKs Silvano Cirujano Cuesta
@ 2021-02-05 9:08 ` Silvano Cirujano Cuesta
2021-02-05 11:07 ` Jan Kiszka
2021-02-05 9:08 ` [PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta
1 sibling, 1 reply; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 9:08 UTC (permalink / raw)
To: isar-users
Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
1 file changed, 97 insertions(+), 7 deletions(-)
diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
index a8c708a..082b16d 100644
--- a/meta/classes/image-sdk-extension.bbclass
+++ b/meta/classes/image-sdk-extension.bbclass
@@ -6,10 +6,81 @@
# This class extends the image.bbclass to supply the creation of a sdk
SDK_INCLUDE_ISAR_APT ?= "0"
+SDK_FORMATS ?= "tar-xz"
+
+sdk_tar_xz() {
+ # Copy mount_chroot.sh for convenience
+ sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
+
+ # Create SDK archive
+ cd -P ${SDKCHROOT_DIR}/..
+ sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
+ -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
+ bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
+}
+
+sdk_container_images() {
+ local cmd="/bin/dash"
+ local empty_tag="empty"
+ local full_tag="latest"
+ local oci_img_dir="${WORKDIR}/oci-image"
+ local sdk_container_formats="$1"
+
+ # prepare OCI container image skeleton
+ 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 SDK root filesystem as the flesh of the skeleton
+ sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
+
+ # 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
+ sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
+ image_name="isar-${sdk_id}"
+ image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
+ for sdk_format in ${sdk_container_formats} ; do
+ case "${sdk_format}" in
+ "docker-archive" | "oci-archive")
+ if [ "${sdk_format}" = "oci-archive" ] ; then
+ target="${sdk_format}:${image_archive}:latest"
+ else
+ target="${sdk_format}:${image_archive}:${image_name}:latest"
+ fi
+ skopeo --insecure-policy copy \
+ "oci:${oci_img_dir}:${full_tag}" "${target}"
+ xz -T0 "${image_archive}"
+ bbnote "Containerized SDK available in ${image_archive}.xz"
+ ;;
+ "oci")
+ tar --create --xz --directory "${oci_img_dir}" \
+ --file "${image_archive}.xz" .
+ bbnote "Containerized SDK available in ${image_archive}.xz"
+ ;;
+ "docker-daemon" | "containers-storage")
+ skopeo --insecure-policy copy \
+ "oci:${oci_img_dir}:${full_tag}" \
+ "${sdk_format}:${image_name}:latest"
+ bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
+ ;;
+ esac
+ done
+}
do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
do_populate_sdk[depends] = "sdkchroot:do_build"
-do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
+do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
do_populate_sdk() {
if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
# Copy isar-apt with deployed Isar packages
@@ -48,12 +119,31 @@ do_populate_sdk() {
done
done
- # Copy mount_chroot.sh for convenience
- sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
+ # separate SDK formats: TAR and container formats
+ container_formats=""
+ for sdk_format in ${SDK_FORMATS} ; do
+ case ${sdk_format} in
+ "tar-xz")
+ sdk_tar_xz
+ ;;
+ "docker-archive" | "oci" | "oci-archive")
+ container_formats="${container_formats} ${sdk_format}"
+ ;;
+ "docker-daemon" | "containers-storage")
+ if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
+ die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
+ fi
+ ;;
+ *)
+ die "unsupported SDK format specified: ${sdk_format}"
+ ;;
+ esac
+ done
- # Create SDK archive
- cd -P ${SDKCHROOT_DIR}/..
- sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
- -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
+ # generate the SDK in all the desired container formats
+ if [ -n "${container_formats}" ] ; then
+ bbnote "Generating SDK container in${container_formats} format"
+ sdk_container_images "${container_formats}"
+ fi
}
addtask populate_sdk after do_rootfs
--
2.30.0
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] sdk: support creation of container image
2021-02-05 9:08 ` [PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
@ 2021-02-05 11:07 ` Jan Kiszka
2021-02-05 11:24 ` Silvano Cirujano Cuesta
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2021-02-05 11:07 UTC (permalink / raw)
To: [ext] Silvano Cirujano Cuesta, isar-users
On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
> Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
> 1 file changed, 97 insertions(+), 7 deletions(-)
>
> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
> index a8c708a..082b16d 100644
> --- a/meta/classes/image-sdk-extension.bbclass
> +++ b/meta/classes/image-sdk-extension.bbclass
> @@ -6,10 +6,81 @@
> # This class extends the image.bbclass to supply the creation of a sdk
>
> SDK_INCLUDE_ISAR_APT ?= "0"
> +SDK_FORMATS ?= "tar-xz"
> +
> +sdk_tar_xz() {
> + # Copy mount_chroot.sh for convenience
> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
> +
> + # Create SDK archive
> + cd -P ${SDKCHROOT_DIR}/..
> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
> +}
> +
> +sdk_container_images() {
> + local cmd="/bin/dash"
> + local empty_tag="empty"
> + local full_tag="latest"
> + local oci_img_dir="${WORKDIR}/oci-image"
> + local sdk_container_formats="$1"
> +
> + # prepare OCI container image skeleton
> + 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 SDK root filesystem as the flesh of the skeleton
> + sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
> +
> + # 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
> + sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
> + image_name="isar-${sdk_id}"
> + image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
> + for sdk_format in ${sdk_container_formats} ; do
> + case "${sdk_format}" in
> + "docker-archive" | "oci-archive")
> + if [ "${sdk_format}" = "oci-archive" ] ; then
> + target="${sdk_format}:${image_archive}:latest"
> + else
> + target="${sdk_format}:${image_archive}:${image_name}:latest"
> + fi
> + skopeo --insecure-policy copy \
> + "oci:${oci_img_dir}:${full_tag}" "${target}"
> + xz -T0 "${image_archive}"
> + bbnote "Containerized SDK available in ${image_archive}.xz"
> + ;;
> + "oci")
> + tar --create --xz --directory "${oci_img_dir}" \
> + --file "${image_archive}.xz" .
> + bbnote "Containerized SDK available in ${image_archive}.xz"
> + ;;
> + "docker-daemon" | "containers-storage")
> + skopeo --insecure-policy copy \
> + "oci:${oci_img_dir}:${full_tag}" \
> + "${sdk_format}:${image_name}:latest"
> + bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
> + ;;
> + esac
> + done
> +}
>
> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
> do_populate_sdk[depends] = "sdkchroot:do_build"
> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
> do_populate_sdk() {
> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
> # Copy isar-apt with deployed Isar packages
> @@ -48,12 +119,31 @@ do_populate_sdk() {
> done
> done
>
> - # Copy mount_chroot.sh for convenience
> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
> + # separate SDK formats: TAR and container formats
> + container_formats=""
> + for sdk_format in ${SDK_FORMATS} ; do
> + case ${sdk_format} in
> + "tar-xz")
> + sdk_tar_xz
> + ;;
> + "docker-archive" | "oci" | "oci-archive")
> + container_formats="${container_formats} ${sdk_format}"
> + ;;
> + "docker-daemon" | "containers-storage")
> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
> + fi
> + ;;
> + *)
> + die "unsupported SDK format specified: ${sdk_format}"
> + ;;
> + esac
> + done
>
> - # Create SDK archive
> - cd -P ${SDKCHROOT_DIR}/..
> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
> + # generate the SDK in all the desired container formats
> + if [ -n "${container_formats}" ] ; then
> + bbnote "Generating SDK container in${container_formats} format"
> + sdk_container_images "${container_formats}"
> + fi
> }
> addtask populate_sdk after do_rootfs
>
How much of this would be reusable of generating a container from a
target rootfs? We should avoid shuffling code around if we can already
line things up nicely while introducing it.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] sdk: support creation of container image
2021-02-05 11:07 ` Jan Kiszka
@ 2021-02-05 11:24 ` Silvano Cirujano Cuesta
2021-02-05 11:29 ` Jan Kiszka
0 siblings, 1 reply; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 11:24 UTC (permalink / raw)
To: Jan Kiszka, isar-users
On 05/02/2021 12:07, Jan Kiszka wrote:
> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>> Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
>> 1 file changed, 97 insertions(+), 7 deletions(-)
>>
>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
>> index a8c708a..082b16d 100644
>> --- a/meta/classes/image-sdk-extension.bbclass
>> +++ b/meta/classes/image-sdk-extension.bbclass
>> @@ -6,10 +6,81 @@
>> # This class extends the image.bbclass to supply the creation of a sdk
>>
>> SDK_INCLUDE_ISAR_APT ?= "0"
>> +SDK_FORMATS ?= "tar-xz"
>> +
>> +sdk_tar_xz() {
>> + # Copy mount_chroot.sh for convenience
>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>> +
>> + # Create SDK archive
>> + cd -P ${SDKCHROOT_DIR}/..
>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
>> +}
>> +
>> +sdk_container_images() {
>> + local cmd="/bin/dash"
>> + local empty_tag="empty"
>> + local full_tag="latest"
>> + local oci_img_dir="${WORKDIR}/oci-image"
>> + local sdk_container_formats="$1"
>> +
>> + # prepare OCI container image skeleton
>> + 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 SDK root filesystem as the flesh of the skeleton
>> + sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
>> +
>> + # 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
>> + sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
>> + image_name="isar-${sdk_id}"
>> + image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
>> + for sdk_format in ${sdk_container_formats} ; do
>> + case "${sdk_format}" in
>> + "docker-archive" | "oci-archive")
>> + if [ "${sdk_format}" = "oci-archive" ] ; then
>> + target="${sdk_format}:${image_archive}:latest"
>> + else
>> + target="${sdk_format}:${image_archive}:${image_name}:latest"
>> + fi
>> + skopeo --insecure-policy copy \
>> + "oci:${oci_img_dir}:${full_tag}" "${target}"
>> + xz -T0 "${image_archive}"
>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>> + ;;
>> + "oci")
>> + tar --create --xz --directory "${oci_img_dir}" \
>> + --file "${image_archive}.xz" .
>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>> + ;;
>> + "docker-daemon" | "containers-storage")
>> + skopeo --insecure-policy copy \
>> + "oci:${oci_img_dir}:${full_tag}" \
>> + "${sdk_format}:${image_name}:latest"
>> + bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
>> + ;;
>> + esac
>> + done
>> +}
>>
>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
>> do_populate_sdk[depends] = "sdkchroot:do_build"
>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
>> do_populate_sdk() {
>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
>> # Copy isar-apt with deployed Isar packages
>> @@ -48,12 +119,31 @@ do_populate_sdk() {
>> done
>> done
>>
>> - # Copy mount_chroot.sh for convenience
>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>> + # separate SDK formats: TAR and container formats
>> + container_formats=""
>> + for sdk_format in ${SDK_FORMATS} ; do
>> + case ${sdk_format} in
>> + "tar-xz")
>> + sdk_tar_xz
>> + ;;
>> + "docker-archive" | "oci" | "oci-archive")
>> + container_formats="${container_formats} ${sdk_format}"
>> + ;;
>> + "docker-daemon" | "containers-storage")
>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
>> + fi
>> + ;;
>> + *)
>> + die "unsupported SDK format specified: ${sdk_format}"
>> + ;;
>> + esac
>> + done
>>
>> - # Create SDK archive
>> - cd -P ${SDKCHROOT_DIR}/..
>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>> + # generate the SDK in all the desired container formats
>> + if [ -n "${container_formats}" ] ; then
>> + bbnote "Generating SDK container in${container_formats} format"
>> + sdk_container_images "${container_formats}"
>> + fi
>> }
>> addtask populate_sdk after do_rootfs
>>
> How much of this would be reusable of generating a container from a
> target rootfs? We should avoid shuffling code around if we can already
> line things up nicely while introducing it.
With that reuse in mind I can refactor the code to have a class that can be reused for both SDK and target rootfs. It's not a big deal.
Is it somehow related to the huge "some image classes" thread that is active right now?
Silvano
>
> Jan
>
--
Siemens AG, T RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] sdk: support creation of container image
2021-02-05 11:24 ` Silvano Cirujano Cuesta
@ 2021-02-05 11:29 ` Jan Kiszka
2021-02-05 17:52 ` Silvano Cirujano Cuesta
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2021-02-05 11:29 UTC (permalink / raw)
To: Silvano Cirujano Cuesta, isar-users
On 05.02.21 12:24, Silvano Cirujano Cuesta wrote:
>
> On 05/02/2021 12:07, Jan Kiszka wrote:
>> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>>> Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
>>> 1 file changed, 97 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
>>> index a8c708a..082b16d 100644
>>> --- a/meta/classes/image-sdk-extension.bbclass
>>> +++ b/meta/classes/image-sdk-extension.bbclass
>>> @@ -6,10 +6,81 @@
>>> # This class extends the image.bbclass to supply the creation of a sdk
>>>
>>> SDK_INCLUDE_ISAR_APT ?= "0"
>>> +SDK_FORMATS ?= "tar-xz"
>>> +
>>> +sdk_tar_xz() {
>>> + # Copy mount_chroot.sh for convenience
>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>> +
>>> + # Create SDK archive
>>> + cd -P ${SDKCHROOT_DIR}/..
>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
>>> +}
>>> +
>>> +sdk_container_images() {
>>> + local cmd="/bin/dash"
>>> + local empty_tag="empty"
>>> + local full_tag="latest"
>>> + local oci_img_dir="${WORKDIR}/oci-image"
>>> + local sdk_container_formats="$1"
>>> +
>>> + # prepare OCI container image skeleton
>>> + 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 SDK root filesystem as the flesh of the skeleton
>>> + sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
>>> +
>>> + # 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
>>> + sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
>>> + image_name="isar-${sdk_id}"
>>> + image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
>>> + for sdk_format in ${sdk_container_formats} ; do
>>> + case "${sdk_format}" in
>>> + "docker-archive" | "oci-archive")
>>> + if [ "${sdk_format}" = "oci-archive" ] ; then
>>> + target="${sdk_format}:${image_archive}:latest"
>>> + else
>>> + target="${sdk_format}:${image_archive}:${image_name}:latest"
>>> + fi
>>> + skopeo --insecure-policy copy \
>>> + "oci:${oci_img_dir}:${full_tag}" "${target}"
>>> + xz -T0 "${image_archive}"
>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>> + ;;
>>> + "oci")
>>> + tar --create --xz --directory "${oci_img_dir}" \
>>> + --file "${image_archive}.xz" .
>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>> + ;;
>>> + "docker-daemon" | "containers-storage")
>>> + skopeo --insecure-policy copy \
>>> + "oci:${oci_img_dir}:${full_tag}" \
>>> + "${sdk_format}:${image_name}:latest"
>>> + bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
>>> + ;;
>>> + esac
>>> + done
>>> +}
>>>
>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
>>> do_populate_sdk[depends] = "sdkchroot:do_build"
>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
>>> do_populate_sdk() {
>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
>>> # Copy isar-apt with deployed Isar packages
>>> @@ -48,12 +119,31 @@ do_populate_sdk() {
>>> done
>>> done
>>>
>>> - # Copy mount_chroot.sh for convenience
>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>> + # separate SDK formats: TAR and container formats
>>> + container_formats=""
>>> + for sdk_format in ${SDK_FORMATS} ; do
>>> + case ${sdk_format} in
>>> + "tar-xz")
>>> + sdk_tar_xz
>>> + ;;
>>> + "docker-archive" | "oci" | "oci-archive")
>>> + container_formats="${container_formats} ${sdk_format}"
>>> + ;;
>>> + "docker-daemon" | "containers-storage")
>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
>>> + fi
>>> + ;;
>>> + *)
>>> + die "unsupported SDK format specified: ${sdk_format}"
>>> + ;;
>>> + esac
>>> + done
>>>
>>> - # Create SDK archive
>>> - cd -P ${SDKCHROOT_DIR}/..
>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>> + # generate the SDK in all the desired container formats
>>> + if [ -n "${container_formats}" ] ; then
>>> + bbnote "Generating SDK container in${container_formats} format"
>>> + sdk_container_images "${container_formats}"
>>> + fi
>>> }
>>> addtask populate_sdk after do_rootfs
>>>
>> How much of this would be reusable of generating a container from a
>> target rootfs? We should avoid shuffling code around if we can already
>> line things up nicely while introducing it.
>
> With that reuse in mind I can refactor the code to have a class that can be reused for both SDK and target rootfs. It's not a big deal.
>
> Is it somehow related to the huge "some image classes" thread that is active right now?
>
Not directly related, but container images would fall into that same
category.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] sdk: support creation of container image
2021-02-05 11:29 ` Jan Kiszka
@ 2021-02-05 17:52 ` Silvano Cirujano Cuesta
2021-02-05 18:20 ` Jan Kiszka
0 siblings, 1 reply; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 17:52 UTC (permalink / raw)
To: Jan Kiszka, isar-users
On 05/02/2021 12:29, Jan Kiszka wrote:
> On 05.02.21 12:24, Silvano Cirujano Cuesta wrote:
>> On 05/02/2021 12:07, Jan Kiszka wrote:
>>> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>>>> Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
>>>> 1 file changed, 97 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
>>>> index a8c708a..082b16d 100644
>>>> --- a/meta/classes/image-sdk-extension.bbclass
>>>> +++ b/meta/classes/image-sdk-extension.bbclass
>>>> @@ -6,10 +6,81 @@
>>>> # This class extends the image.bbclass to supply the creation of a sdk
>>>>
>>>> SDK_INCLUDE_ISAR_APT ?= "0"
>>>> +SDK_FORMATS ?= "tar-xz"
>>>> +
>>>> +sdk_tar_xz() {
>>>> + # Copy mount_chroot.sh for convenience
>>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>>> +
>>>> + # Create SDK archive
>>>> + cd -P ${SDKCHROOT_DIR}/..
>>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
>>>> +}
>>>> +
>>>> +sdk_container_images() {
>>>> + local cmd="/bin/dash"
>>>> + local empty_tag="empty"
>>>> + local full_tag="latest"
>>>> + local oci_img_dir="${WORKDIR}/oci-image"
>>>> + local sdk_container_formats="$1"
>>>> +
>>>> + # prepare OCI container image skeleton
>>>> + 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 SDK root filesystem as the flesh of the skeleton
>>>> + sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
>>>> +
>>>> + # 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
>>>> + sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
>>>> + image_name="isar-${sdk_id}"
>>>> + image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
>>>> + for sdk_format in ${sdk_container_formats} ; do
>>>> + case "${sdk_format}" in
>>>> + "docker-archive" | "oci-archive")
>>>> + if [ "${sdk_format}" = "oci-archive" ] ; then
>>>> + target="${sdk_format}:${image_archive}:latest"
>>>> + else
>>>> + target="${sdk_format}:${image_archive}:${image_name}:latest"
>>>> + fi
>>>> + skopeo --insecure-policy copy \
>>>> + "oci:${oci_img_dir}:${full_tag}" "${target}"
>>>> + xz -T0 "${image_archive}"
>>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>>> + ;;
>>>> + "oci")
>>>> + tar --create --xz --directory "${oci_img_dir}" \
>>>> + --file "${image_archive}.xz" .
>>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>>> + ;;
>>>> + "docker-daemon" | "containers-storage")
>>>> + skopeo --insecure-policy copy \
>>>> + "oci:${oci_img_dir}:${full_tag}" \
>>>> + "${sdk_format}:${image_name}:latest"
>>>> + bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
>>>> + ;;
>>>> + esac
>>>> + done
>>>> +}
>>>>
>>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
>>>> do_populate_sdk[depends] = "sdkchroot:do_build"
>>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
>>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
>>>> do_populate_sdk() {
>>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
>>>> # Copy isar-apt with deployed Isar packages
>>>> @@ -48,12 +119,31 @@ do_populate_sdk() {
>>>> done
>>>> done
>>>>
>>>> - # Copy mount_chroot.sh for convenience
>>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>>> + # separate SDK formats: TAR and container formats
>>>> + container_formats=""
>>>> + for sdk_format in ${SDK_FORMATS} ; do
>>>> + case ${sdk_format} in
>>>> + "tar-xz")
>>>> + sdk_tar_xz
>>>> + ;;
>>>> + "docker-archive" | "oci" | "oci-archive")
>>>> + container_formats="${container_formats} ${sdk_format}"
>>>> + ;;
>>>> + "docker-daemon" | "containers-storage")
>>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
>>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
>>>> + fi
>>>> + ;;
>>>> + *)
>>>> + die "unsupported SDK format specified: ${sdk_format}"
>>>> + ;;
>>>> + esac
>>>> + done
>>>>
>>>> - # Create SDK archive
>>>> - cd -P ${SDKCHROOT_DIR}/..
>>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>>> + # generate the SDK in all the desired container formats
>>>> + if [ -n "${container_formats}" ] ; then
>>>> + bbnote "Generating SDK container in${container_formats} format"
>>>> + sdk_container_images "${container_formats}"
>>>> + fi
>>>> }
>>>> addtask populate_sdk after do_rootfs
>>>>
>>> How much of this would be reusable of generating a container from a
>>> target rootfs? We should avoid shuffling code around if we can already
>>> line things up nicely while introducing it.
>> With that reuse in mind I can refactor the code to have a class that can be reused for both SDK and target rootfs. It's not a big deal.
>>
>> Is it somehow related to the huge "some image classes" thread that is active right now?
>>
> Not directly related, but container images would fall into that same
> category.
What do you have in mind? How should I structure the functions, classes, tasks,...?
In a separate bbclass providing only generic functions that can containerize whatever rootfs (e.g. target) they're given (currently only for the SDK calling them from "populate_sdk")? Similar to "debianize.bbclass". Something I can do easily.
In a separate bbclass following the pattern of the other "-img.bclass" (e.g. "container-img.bbclass")? I mean providing not only functions even new tasks. Would be harder to accomplish.
Are the "-img.bbclass" classes only for target images? I wonder why "targz-img.bbclass" doesn't take care of "packaging" also the SDK. Not because of code reuse (too short code, to many differences on the TAR call), but for logical consistency.
Silvano
>
> Jan
>
--
Siemens AG, T RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 1/2] sdk: support creation of container image
2021-02-05 17:52 ` Silvano Cirujano Cuesta
@ 2021-02-05 18:20 ` Jan Kiszka
0 siblings, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2021-02-05 18:20 UTC (permalink / raw)
To: Silvano Cirujano Cuesta, isar-users
On 05.02.21 18:52, Silvano Cirujano Cuesta wrote:
>
> On 05/02/2021 12:29, Jan Kiszka wrote:
>> On 05.02.21 12:24, Silvano Cirujano Cuesta wrote:
>>> On 05/02/2021 12:07, Jan Kiszka wrote:
>>>> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>>>>> Extend 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/image-sdk-extension.bbclass | 104 +++++++++++++++++++++--
>>>>> 1 file changed, 97 insertions(+), 7 deletions(-)
>>>>>
>>>>> diff --git a/meta/classes/image-sdk-extension.bbclass b/meta/classes/image-sdk-extension.bbclass
>>>>> index a8c708a..082b16d 100644
>>>>> --- a/meta/classes/image-sdk-extension.bbclass
>>>>> +++ b/meta/classes/image-sdk-extension.bbclass
>>>>> @@ -6,10 +6,81 @@
>>>>> # This class extends the image.bbclass to supply the creation of a sdk
>>>>>
>>>>> SDK_INCLUDE_ISAR_APT ?= "0"
>>>>> +SDK_FORMATS ?= "tar-xz"
>>>>> +
>>>>> +sdk_tar_xz() {
>>>>> + # Copy mount_chroot.sh for convenience
>>>>> + sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>>>> +
>>>>> + # Create SDK archive
>>>>> + cd -P ${SDKCHROOT_DIR}/..
>>>>> + sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>>>> + -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>>>> + bbnote "SDK rootfs available in ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz"
>>>>> +}
>>>>> +
>>>>> +sdk_container_images() {
>>>>> + local cmd="/bin/dash"
>>>>> + local empty_tag="empty"
>>>>> + local full_tag="latest"
>>>>> + local oci_img_dir="${WORKDIR}/oci-image"
>>>>> + local sdk_container_formats="$1"
>>>>> +
>>>>> + # prepare OCI container image skeleton
>>>>> + 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 SDK root filesystem as the flesh of the skeleton
>>>>> + sudo cp -a "${SDKCHROOT_DIR}"/* "${oci_img_dir}_unpacked/rootfs/"
>>>>> +
>>>>> + # 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
>>>>> + sdk_id="sdk-${DISTRO}-${DISTRO_ARCH}"
>>>>> + image_name="isar-${sdk_id}"
>>>>> + image_archive="${DEPLOY_DIR_IMAGE}/${sdk_id}-${sdk_format}.tar"
>>>>> + for sdk_format in ${sdk_container_formats} ; do
>>>>> + case "${sdk_format}" in
>>>>> + "docker-archive" | "oci-archive")
>>>>> + if [ "${sdk_format}" = "oci-archive" ] ; then
>>>>> + target="${sdk_format}:${image_archive}:latest"
>>>>> + else
>>>>> + target="${sdk_format}:${image_archive}:${image_name}:latest"
>>>>> + fi
>>>>> + skopeo --insecure-policy copy \
>>>>> + "oci:${oci_img_dir}:${full_tag}" "${target}"
>>>>> + xz -T0 "${image_archive}"
>>>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>>>> + ;;
>>>>> + "oci")
>>>>> + tar --create --xz --directory "${oci_img_dir}" \
>>>>> + --file "${image_archive}.xz" .
>>>>> + bbnote "Containerized SDK available in ${image_archive}.xz"
>>>>> + ;;
>>>>> + "docker-daemon" | "containers-storage")
>>>>> + skopeo --insecure-policy copy \
>>>>> + "oci:${oci_img_dir}:${full_tag}" \
>>>>> + "${sdk_format}:${image_name}:latest"
>>>>> + bbnote "Containerized SDK available in ${sdk_format} as '${image_name}:latest'"
>>>>> + ;;
>>>>> + esac
>>>>> + done
>>>>> +}
>>>>>
>>>>> do_populate_sdk[stamp-extra-info] = "${DISTRO}-${MACHINE}"
>>>>> do_populate_sdk[depends] = "sdkchroot:do_build"
>>>>> -do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT"
>>>>> +do_populate_sdk[vardeps] += "SDK_INCLUDE_ISAR_APT SDK_FORMATS"
>>>>> do_populate_sdk() {
>>>>> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
>>>>> # Copy isar-apt with deployed Isar packages
>>>>> @@ -48,12 +119,31 @@ do_populate_sdk() {
>>>>> done
>>>>> done
>>>>>
>>>>> - # Copy mount_chroot.sh for convenience
>>>>> - sudo cp ${SCRIPTSDIR}/mount_chroot.sh ${SDKCHROOT_DIR}
>>>>> + # separate SDK formats: TAR and container formats
>>>>> + container_formats=""
>>>>> + for sdk_format in ${SDK_FORMATS} ; do
>>>>> + case ${sdk_format} in
>>>>> + "tar-xz")
>>>>> + sdk_tar_xz
>>>>> + ;;
>>>>> + "docker-archive" | "oci" | "oci-archive")
>>>>> + container_formats="${container_formats} ${sdk_format}"
>>>>> + ;;
>>>>> + "docker-daemon" | "containers-storage")
>>>>> + if [ -f /.dockerenv ] || [ -f /run/.containerenv ] ; then
>>>>> + die "Adding the SDK container image to a container runtime (${sdk_format}) not supported if running from a container (e.g. 'kas-container')"
>>>>> + fi
>>>>> + ;;
>>>>> + *)
>>>>> + die "unsupported SDK format specified: ${sdk_format}"
>>>>> + ;;
>>>>> + esac
>>>>> + done
>>>>>
>>>>> - # Create SDK archive
>>>>> - cd -P ${SDKCHROOT_DIR}/..
>>>>> - sudo tar --transform="s|^rootfs|sdk-${DISTRO}-${DISTRO_ARCH}|" \
>>>>> - -c rootfs | xz -T0 > ${DEPLOY_DIR_IMAGE}/sdk-${DISTRO}-${DISTRO_ARCH}.tar.xz
>>>>> + # generate the SDK in all the desired container formats
>>>>> + if [ -n "${container_formats}" ] ; then
>>>>> + bbnote "Generating SDK container in${container_formats} format"
>>>>> + sdk_container_images "${container_formats}"
>>>>> + fi
>>>>> }
>>>>> addtask populate_sdk after do_rootfs
>>>>>
>>>> How much of this would be reusable of generating a container from a
>>>> target rootfs? We should avoid shuffling code around if we can already
>>>> line things up nicely while introducing it.
>>> With that reuse in mind I can refactor the code to have a class that can be reused for both SDK and target rootfs. It's not a big deal.
>>>
>>> Is it somehow related to the huge "some image classes" thread that is active right now?
>>>
>> Not directly related, but container images would fall into that same
>> category.
>
> What do you have in mind? How should I structure the functions, classes, tasks,...?
>
> In a separate bbclass providing only generic functions that can containerize whatever rootfs (e.g. target) they're given (currently only for the SDK calling them from "populate_sdk")? Similar to "debianize.bbclass". Something I can do easily.
>
> In a separate bbclass following the pattern of the other "-img.bclass" (e.g. "container-img.bbclass")? I mean providing not only functions even new tasks. Would be harder to accomplish.
>
Yes, that is what I was thinking of (and that user on our internal issue
tracker as well, if you recall): Drop-in replacement for existing target
image classes, e.g. selected via IMAGE_TYPE.
> Are the "-img.bbclass" classes only for target images? I wonder why "targz-img.bbclass" doesn't take care of "packaging" also the SDK. Not because of code reuse (too short code, to many differences on the TAR call), but for logical consistency.
So far, this is the logic. I didn't dig into the commonalities between
the sdk tarball and that - later added - targz-img. Maybe that is worth
to refactor when adding something like the container formats.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/2] docs: document usage of sdk container images
2021-02-05 9:08 [PATCH 0/2] Add support for containerized SDKs Silvano Cirujano Cuesta
2021-02-05 9:08 ` [PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
@ 2021-02-05 9:08 ` Silvano Cirujano Cuesta
2021-02-05 11:07 ` Jan Kiszka
1 sibling, 1 reply; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 9:08 UTC (permalink / raw)
To: isar-users
Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
---
doc/user_manual.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/doc/user_manual.md b/doc/user_manual.md
index a4f3d1d..7863241 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+.
@@ -834,6 +838,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
+
+User specifies the variable `SDK_FORMAT` providing a space-separated list of SDK formats to generate.
+
+Supported formats are:
+ - `tar-xz`: (default) is the non-containerized format that results from following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)"
+ - `docker-archive`: 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 `SDK_FORMATS`).
+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 SDK formats to generate available to the task
+
+For one-shot builds (use `local.conf` otherwise):
+
+```
+export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SDK_FORMATS"
+export SDK_FORMATS="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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] docs: document usage of sdk container images
2021-02-05 9:08 ` [PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta
@ 2021-02-05 11:07 ` Jan Kiszka
2021-02-05 14:58 ` Silvano Cirujano Cuesta
0 siblings, 1 reply; 11+ messages in thread
From: Jan Kiszka @ 2021-02-05 11:07 UTC (permalink / raw)
To: [ext] Silvano Cirujano Cuesta, isar-users
On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
> ---
> doc/user_manual.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 79 insertions(+)
>
> diff --git a/doc/user_manual.md b/doc/user_manual.md
> index a4f3d1d..7863241 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`.
This packages should probably also be listed under
https://github.com/ilbers/isar/blob/master/doc/user_manual.md#install-host-tools,
as optional and with a pointer to here for all the details.
> +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+.
> @@ -834,6 +838,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
> +
> +User specifies the variable `SDK_FORMAT` providing a space-separated list of SDK formats to generate.
> +
> +Supported formats are:
> + - `tar-xz`: (default) is the non-containerized format that results from following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)"
> + - `docker-archive`: 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 `SDK_FORMATS`).
> +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 SDK formats to generate available to the task
> +
> +For one-shot builds (use `local.conf` otherwise):
> +
> +```
> +export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SDK_FORMATS"
> +export SDK_FORMATS="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
>
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] docs: document usage of sdk container images
2021-02-05 11:07 ` Jan Kiszka
@ 2021-02-05 14:58 ` Silvano Cirujano Cuesta
2021-02-05 18:21 ` Jan Kiszka
0 siblings, 1 reply; 11+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-02-05 14:58 UTC (permalink / raw)
To: Jan Kiszka, isar-users
On 05/02/2021 12:07, Jan Kiszka wrote:
> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
>> ---
>> doc/user_manual.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 79 insertions(+)
>>
>> diff --git a/doc/user_manual.md b/doc/user_manual.md
>> index a4f3d1d..7863241 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`.
> This packages should probably also be listed under
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Filbers%2Fisar%2Fblob%2Fmaster%2Fdoc%2Fuser_manual.md%23install-host-tools&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C6b8f60d2fae94496197d08d8c9c6403a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637481200603194744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VF1U9PGhurVgbH%2BoILbmSfAnBYWUL%2BwylXZ0N2xoG6g%3D&reserved=0,
> as optional and with a pointer to here for all the details.
I'm puzzled now. That's the document and section where this addition goes to... Am I missing something?
Silvano
>> +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+.
>> @@ -834,6 +838,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
>> +
>> +User specifies the variable `SDK_FORMAT` providing a space-separated list of SDK formats to generate.
>> +
>> +Supported formats are:
>> + - `tar-xz`: (default) is the non-containerized format that results from following the instructions in "[Create an ISAR SDK root filesystem](#create-an-isar-sdk-root-filesystem)"
>> + - `docker-archive`: an archive containing a Docker image that can be imported with [`docker import`](https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.docker.com%2Fengine%2Freference%2Fcommandline%2Fimport%2F&data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C6b8f60d2fae94496197d08d8c9c6403a%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637481200603194744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fMI3heAmHRkFvQj3euZcbFYS0wkhIjM3hyw5FzOjyes%3D&reserved=0)
>> + - `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 `SDK_FORMATS`).
>> +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 SDK formats to generate available to the task
>> +
>> +For one-shot builds (use `local.conf` otherwise):
>> +
>> +```
>> +export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE SDK_FORMATS"
>> +export SDK_FORMATS="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
>>
> Jan
>
--
Siemens AG, T RDA IOT SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [PATCH 2/2] docs: document usage of sdk container images
2021-02-05 14:58 ` Silvano Cirujano Cuesta
@ 2021-02-05 18:21 ` Jan Kiszka
0 siblings, 0 replies; 11+ messages in thread
From: Jan Kiszka @ 2021-02-05 18:21 UTC (permalink / raw)
To: [ext] Silvano Cirujano Cuesta, isar-users
On 05.02.21 15:58, [ext] Silvano Cirujano Cuesta wrote:
>
> On 05/02/2021 12:07, Jan Kiszka wrote:
>> On 05.02.21 10:08, [ext] Silvano Cirujano Cuesta wrote:
>>> Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
>>> ---
>>> doc/user_manual.md | 79 ++++++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 79 insertions(+)
>>>
>>> diff --git a/doc/user_manual.md b/doc/user_manual.md
>>> index a4f3d1d..7863241 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`.
>> This packages should probably also be listed under
>> https://github.com/ilbers/isar/blob/master/doc/user_manual.md#install-host-tools
>> as optional and with a pointer to here for all the details.
>
> I'm puzzled now. That's the document and section where this addition goes to... Am I missing something?
>
Forget it, missed that it is already in the right section.
Jan
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-02-05 18:21 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-05 9:08 [PATCH 0/2] Add support for containerized SDKs Silvano Cirujano Cuesta
2021-02-05 9:08 ` [PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
2021-02-05 11:07 ` Jan Kiszka
2021-02-05 11:24 ` Silvano Cirujano Cuesta
2021-02-05 11:29 ` Jan Kiszka
2021-02-05 17:52 ` Silvano Cirujano Cuesta
2021-02-05 18:20 ` Jan Kiszka
2021-02-05 9:08 ` [PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta
2021-02-05 11:07 ` Jan Kiszka
2021-02-05 14:58 ` Silvano Cirujano Cuesta
2021-02-05 18:21 ` Jan Kiszka
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox