From: Henning Schild <henning.schild@siemens.com>
To: "[ext] Silvano Cirujano Cuesta" <silvano.cirujano-cuesta@siemens.com>
Cc: isar-users@googlegroups.com
Subject: Re: [RFC PATCH 1/2] sdk: support creation of container image
Date: Tue, 12 Jan 2021 12:36:50 +0100 [thread overview]
Message-ID: <20210112123650.6ef81c19@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <20210112103338.14712-2-silvano.cirujano-cuesta@siemens.com>
Am Tue, 12 Jan 2021 11:33:37 +0100
schrieb "[ext] Silvano Cirujano Cuesta"
<silvano.cirujano-cuesta@siemens.com>:
> 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 | 99
> ++++++++++++++++++++++-- 1 file changed, 92 insertions(+), 7
> deletions(-)
>
> diff --git a/meta/classes/image-sdk-extension.bbclass
> b/meta/classes/image-sdk-extension.bbclass index a8c708a..9317256
> 100644 --- a/meta/classes/image-sdk-extension.bbclass
> +++ b/meta/classes/image-sdk-extension.bbclass
> @@ -6,10 +6,77 @@
> # This class extends the image.bbclass to supply the creation of a
> sdk
> SDK_INCLUDE_ISAR_APT ?= "0"
> +SDK_GENERATE_FORMATS = "${@d.getVar("SDK_FORMATS", "tar")}"
I do not understand why there are two variables, maybe one is enough.
And i think a ?= assignment would be a better choice here.
> +sdk_tar() {
I think this should be tar_xz or 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 +}
> +
> +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}"
> + ;;
> + "oci")
> + tar --create --xz --directory "${oci_img_dir}" \
> + --file "${image_archive}.xz" .
> + ;;
do we not already have tar_xz code we can maybe reuse?
> + "docker-daemon" | "containers-storage")
> + skopeo --insecure-policy copy \
> + "oci:${oci_img_dir}:${full_tag}" \
> + "${sdk_format}:${image_name}:latest"
> + ;;
i really would not trust "skopeo" to generate valid docker images, the
container world is full of incompatible stuff and compat fake news
> + esac
> + done
This is using "umoci" and "skopeo", new runtime deps ... which might
only be available/working in pretty bleeding edge debian.
Henning
> +}
>
> 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_GENERATE_FORMATS" do_populate_sdk() {
> if [ "${SDK_INCLUDE_ISAR_APT}" = "1" ]; then
> # Copy isar-apt with deployed Isar packages
> @@ -48,12 +115,30 @@ 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_GENERATE_FORMATS} ; do
> + case ${sdk_format} in
> + tar)
> + sdk_tar
> + ;;
> + "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
> + sdk_container_images "${container_formats}"
> + fi
> }
> addtask populate_sdk after do_rootfs
next prev parent reply other threads:[~2021-01-12 11:36 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-12 10:33 [RFC PATCH 0/2] support generation of sdk container images Silvano Cirujano Cuesta
2021-01-12 10:33 ` [RFC PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
2021-01-12 11:36 ` Henning Schild [this message]
2021-01-12 11:50 ` Silvano Cirujano Cuesta
2021-01-12 14:50 ` Jan Kiszka
2021-01-12 17:08 ` Silvano Cirujano Cuesta
2021-01-12 17:36 ` Henning Schild
2021-01-12 17:54 ` Silvano Cirujano Cuesta
2021-01-12 18:04 ` Jan Kiszka
2021-01-12 20:46 ` Silvano Cirujano Cuesta
2021-01-12 10:33 ` [RFC PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta
2021-01-12 11:40 ` Henning Schild
2021-01-12 12:03 ` Silvano Cirujano Cuesta
2021-01-12 12:18 ` Henning Schild
2021-01-12 14:52 ` Silvano Cirujano Cuesta
2021-01-12 14:56 ` Jan Kiszka
2021-01-12 15:12 ` Silvano Cirujano Cuesta
2021-01-12 15:14 ` Jan Kiszka
2021-01-12 15:11 ` Henning Schild
2021-01-12 16:26 ` Silvano Cirujano Cuesta
2021-01-14 13:56 ` [RFC PATCH 0/2] support generation " Silvano Cirujano Cuesta
2021-01-14 18:32 ` Henning Schild
2021-01-15 8:11 ` Silvano Cirujano Cuesta
2021-01-15 7:09 ` Jan Kiszka
2021-01-15 8:16 ` Silvano Cirujano Cuesta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210112123650.6ef81c19@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=silvano.cirujano-cuesta@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox