From: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>
To: Henning Schild <henning.schild@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:50:10 +0100 [thread overview]
Message-ID: <159e6052-d297-74ee-a5a2-0b5e52262cb3@siemens.com> (raw)
In-Reply-To: <20210112123650.6ef81c19@md1za8fc.ad001.siemens.net>
On 12/01/2021 12:36, Henning Schild wrote:
> 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.
Probably lack of ISAR expersite... I don't know why using
SDK_FORMATS = "${@d.getVar("SDK_FORMATS", "tar")}"
fails. I've also tried
SDK_FORMATS ?= "tar"
and failed.
>
>> +sdk_tar() {
> I think this should be tar_xz or tar.xz
Why not... Will change it.
>
>> + # 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?
Do you mean the function "sdk_tar"? Not enough overlapping with the code in that function to make reuse meaningful.
>
>> + "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
Alternative?
Docker-in-Docker? I would do that.
Self-built? Not worth the effort, harder to keep compatibility.
>
>> + esac
>> + done
> This is using "umoci" and "skopeo", new runtime deps ... which might
> only be available/working in pretty bleeding edge debian.
Sorry, I forgot to mention it in the cover-letter.
Bleeding edge? Nope:
- Umoci is in Debian 10 (Buster, current stable).
- Skopeo is in Debian 11 (Bullseye, upcoming stable), it can be easily backported. I've done it on a KAS container, and I'd contribute that addition to that project too.
Silvano
>
> 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
--
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2021-01-12 11:50 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
2021-01-12 11:50 ` Silvano Cirujano Cuesta [this message]
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=159e6052-d297-74ee-a5a2-0b5e52262cb3@siemens.com \
--to=silvano.cirujano-cuesta@siemens.com \
--cc=henning.schild@siemens.com \
--cc=isar-users@googlegroups.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