* [RFC PATCH 0/2] support generation of sdk container images
@ 2021-01-12 10:33 Silvano Cirujano Cuesta
2021-01-12 10:33 ` [RFC PATCH 1/2] sdk: support creation of container image Silvano Cirujano Cuesta
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Silvano Cirujano Cuesta @ 2021-01-12 10:33 UTC (permalink / raw)
To: isar-users
This patch series adds to the SDK generation (task `populate_sdk`) the
possibility of generating container images containing the SDK in
different formats (multiple formats can be generated at once).
Up-to-now the task `populate_sdk` generates the sdk root filesystem (in
both as a file tree and in a tarball) that can be chrooted to. The same
root filesystem can be easily distributed as a container image and
started as a container.
It's even possible extracting the root filesystem from a container
image, using the container image format only as a sort of packaging
system for easy distribution.
More information about its usage is documented in the file
docs/user_manual.md.
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.
Silvano Cirujano Cuesta (2):
sdk: support creation of container image
docs: document usage of sdk container images
doc/user_manual.md | 70 +++++++++++++++++
meta/classes/image-sdk-extension.bbclass | 99 ++++++++++++++++++++++--
2 files changed, 162 insertions(+), 7 deletions(-)
--
2.29.2
^ permalink raw reply [flat|nested] 25+ messages in thread* [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 10:33 [RFC PATCH 0/2] support generation of sdk container images Silvano Cirujano Cuesta @ 2021-01-12 10:33 ` Silvano Cirujano Cuesta 2021-01-12 11:36 ` Henning Schild 2021-01-12 17:36 ` Henning Schild 2021-01-12 10:33 ` [RFC PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta 2021-01-14 13:56 ` [RFC PATCH 0/2] support generation " Silvano Cirujano Cuesta 2 siblings, 2 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 10:33 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 | 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")}" + +sdk_tar() { + # 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" . + ;; + "docker-daemon" | "containers-storage") + skopeo --insecure-policy copy \ + "oci:${oci_img_dir}:${full_tag}" \ + "${sdk_format}:${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_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 -- 2.29.2 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 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 2021-01-12 17:36 ` Henning Schild 1 sibling, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-12 11:36 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta; +Cc: isar-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 11:36 ` Henning Schild @ 2021-01-12 11:50 ` Silvano Cirujano Cuesta 2021-01-12 14:50 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 11:50 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users 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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 11:50 ` Silvano Cirujano Cuesta @ 2021-01-12 14:50 ` Jan Kiszka 2021-01-12 17:08 ` Silvano Cirujano Cuesta 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2021-01-12 14:50 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, Henning Schild; +Cc: isar-users On 12.01.21 12:50, [ext] Silvano Cirujano Cuesta wrote: > > 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. How did it fail - because this is how it should look like. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 14:50 ` Jan Kiszka @ 2021-01-12 17:08 ` Silvano Cirujano Cuesta 0 siblings, 0 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 17:08 UTC (permalink / raw) To: Jan Kiszka, Henning Schild; +Cc: isar-users On 12/01/2021 15:50, Jan Kiszka wrote: > On 12.01.21 12:50, [ext] Silvano Cirujano Cuesta wrote: >> 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. > How did it fail - because this is how it should look like. Using `SDK_FORMATS ?= "tar"` and not providing any value for SDK_FORMATS (so using the default), `bitbake -e` doesn't show SDK_FORMATS at all and therefore I thought it was failing. I've retried with `SDK_FORMATS ?= "tar"` and it works. I'll fix it. Silvano > > Jan > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 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 17:36 ` Henning Schild 2021-01-12 17:54 ` Silvano Cirujano Cuesta 1 sibling, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-12 17:36 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta; +Cc: isar-users 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")}" > + > +sdk_tar() { > + # 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" . > + ;; > + "docker-daemon" | "containers-storage") > + skopeo --insecure-policy copy \ > + "oci:${oci_img_dir}:${full_tag}" \ > + "${sdk_format}:${image_name}:latest" > + ;; Jan proposed to make the SDK class wider than x86(64). How is this going to affect docker? (i intentionally use "docker" as synonym for all sorts of ...) The proposed changes should be tested for riscv and arm64 as well. Henning > + 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_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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 17:36 ` Henning Schild @ 2021-01-12 17:54 ` Silvano Cirujano Cuesta 2021-01-12 18:04 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 17:54 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users On 12/01/2021 18: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")}" >> + >> +sdk_tar() { >> + # 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" . >> + ;; >> + "docker-daemon" | "containers-storage") >> + skopeo --insecure-policy copy \ >> + "oci:${oci_img_dir}:${full_tag}" \ >> + "${sdk_format}:${image_name}:latest" >> + ;; > Jan proposed to make the SDK class wider than x86(64). How is this > going to affect docker? (i intentionally use "docker" as synonym for all > sorts of ...) I intentionally use container instead of Docker where it's not docker-only. > > The proposed changes should be tested for riscv and arm64 as well. Do you mean hosts or targets? Assuming you're talking about RISC-V and ARM64 targets... This functionality is merely packaging the cross-buildchain that up-to-now could be generated with "populate_sdk", whatever was supported should be supported by this patch. Of course, the changes should be tested for different combinations. Feel free to test it for those architectures, as long as we are in the discussion round I'm fine with the "whatever was supported should be supported by this patch" that I've written above. I'd really test if only before contributing the final patches for integration. Silvano > > Henning > >> + 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_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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 17:54 ` Silvano Cirujano Cuesta @ 2021-01-12 18:04 ` Jan Kiszka 2021-01-12 20:46 ` Silvano Cirujano Cuesta 0 siblings, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2021-01-12 18:04 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, Henning Schild; +Cc: isar-users On 12.01.21 18:54, [ext] Silvano Cirujano Cuesta wrote: > > On 12/01/2021 18: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")}" >>> + >>> +sdk_tar() { >>> + # 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" . >>> + ;; >>> + "docker-daemon" | "containers-storage") >>> + skopeo --insecure-policy copy \ >>> + "oci:${oci_img_dir}:${full_tag}" \ >>> + "${sdk_format}:${image_name}:latest" >>> + ;; >> Jan proposed to make the SDK class wider than x86(64). How is this >> going to affect docker? (i intentionally use "docker" as synonym for all >> sorts of ...) > I intentionally use container instead of Docker where it's not docker-only. >> >> The proposed changes should be tested for riscv and arm64 as well. > > Do you mean hosts or targets? Assuming you're talking about RISC-V and ARM64 targets... > > This functionality is merely packaging the cross-buildchain that up-to-now could be generated with "populate_sdk", whatever was supported should be supported by this patch. > > Of course, the changes should be tested for different combinations. Feel free to test it for those architectures, as long as we are in the discussion round I'm fine with the "whatever was supported should be supported by this patch" that I've written above. I'd really test if only before contributing the final patches for integration. > Agreed. I don't see any arch-specific blocker here. Both skopeo and umoci are available for our "new" host arch, arm64. RISC-V is still no official Debian target, thus may break for any reason on any day. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 1/2] sdk: support creation of container image 2021-01-12 18:04 ` Jan Kiszka @ 2021-01-12 20:46 ` Silvano Cirujano Cuesta 0 siblings, 0 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 20:46 UTC (permalink / raw) To: Jan Kiszka, Henning Schild; +Cc: isar-users On 12/01/2021 19:04, Jan Kiszka wrote: > On 12.01.21 18:54, [ext] Silvano Cirujano Cuesta wrote: >> On 12/01/2021 18: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")}" >>>> + >>>> +sdk_tar() { >>>> + # 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" . >>>> + ;; >>>> + "docker-daemon" | "containers-storage") >>>> + skopeo --insecure-policy copy \ >>>> + "oci:${oci_img_dir}:${full_tag}" \ >>>> + "${sdk_format}:${image_name}:latest" >>>> + ;; >>> Jan proposed to make the SDK class wider than x86(64). How is this >>> going to affect docker? (i intentionally use "docker" as synonym for all >>> sorts of ...) >> I intentionally use container instead of Docker where it's not docker-only. >>> The proposed changes should be tested for riscv and arm64 as well. >> Do you mean hosts or targets? Assuming you're talking about RISC-V and ARM64 targets... >> >> This functionality is merely packaging the cross-buildchain that up-to-now could be generated with "populate_sdk", whatever was supported should be supported by this patch. >> >> Of course, the changes should be tested for different combinations. Feel free to test it for those architectures, as long as we are in the discussion round I'm fine with the "whatever was supported should be supported by this patch" that I've written above. I'd really test if only before contributing the final patches for integration. >> > Agreed. I don't see any arch-specific blocker here. Both skopeo and > umoci are available for our "new" host arch, arm64. RISC-V is still no > official Debian target, thus may break for any reason on any day. I have to admit I didn't expect Henning to mean ARM64 and RISC-V for the host... Anyway, as Jan says, ARM64 is supported for umoci and skopeo. Not only that, even the unofficial RISC-V port is providing umoci and I'd expect skopeo to become also supported in the upcoming future. The architecture of the host shouldn't be a big deal as long as it's supported by Debian, since neither umoci nor skopeo are using any "container-specific" technology. They simply build tarballed archives with a fixed format, write JSON documents, calculate SHA256 checksums and build file trees with a specified structure. Everything (except for the fixed TAR format) can be built with a shell script using very common tools like sed, jq, sha256sum,... Silvano > > Jan > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* [RFC PATCH 2/2] docs: document usage of sdk container images 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 10:33 ` Silvano Cirujano Cuesta 2021-01-12 11:40 ` Henning Schild 2021-01-14 13:56 ` [RFC PATCH 0/2] support generation " Silvano Cirujano Cuesta 2 siblings, 1 reply; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 10:33 UTC (permalink / raw) To: isar-users Signed-off-by: Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com> --- doc/user_manual.md | 70 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) diff --git a/doc/user_manual.md b/doc/user_manual.md index a4f3d1d..ff779b1 100644 --- a/doc/user_manual.md +++ b/doc/user_manual.md @@ -834,6 +834,76 @@ 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`: is the 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`: (not supported from inside of a container) resulting container image is made available on the local Docker Daemon + - `containers-storage`: (not supported from inside of a container) 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). + +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.29.2 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 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 0 siblings, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-12 11:40 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta; +Cc: isar-users Am Tue, 12 Jan 2021 11:33:38 +0100 schrieb "[ext] Silvano Cirujano Cuesta" <silvano.cirujano-cuesta@siemens.com>: > Signed-off-by: Silvano Cirujano Cuesta > <silvano.cirujano-cuesta@siemens.com> --- > doc/user_manual.md | 70 > ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 > insertions(+) > > diff --git a/doc/user_manual.md b/doc/user_manual.md > index a4f3d1d..ff779b1 100644 > --- a/doc/user_manual.md > +++ b/doc/user_manual.md > @@ -834,6 +834,76 @@ 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`: is the 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`: (not supported from inside of a container) > resulting container image is made available on the local Docker Daemon > + - `containers-storage`: (not supported from inside of a container) > 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 + Maybe a script to postprocess the one tarball we have would be a better option. I do not understand why skopeo can not be used inside docker or podman, but we _really_ should not motivate anyone to run isar plain. Otherwise i agree that a bitbake task is a good idea and much better than postprocessing outside of the build system. Henning > +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). + +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 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 11:40 ` Henning Schild @ 2021-01-12 12:03 ` Silvano Cirujano Cuesta 2021-01-12 12:18 ` Henning Schild 0 siblings, 1 reply; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 12:03 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users On 12/01/2021 12:40, Henning Schild wrote: > Am Tue, 12 Jan 2021 11:33:38 +0100 > schrieb "[ext] Silvano Cirujano Cuesta" > <silvano.cirujano-cuesta@siemens.com>: > >> Signed-off-by: Silvano Cirujano Cuesta >> <silvano.cirujano-cuesta@siemens.com> --- >> doc/user_manual.md | 70 >> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >> insertions(+) >> >> diff --git a/doc/user_manual.md b/doc/user_manual.md >> index a4f3d1d..ff779b1 100644 >> --- a/doc/user_manual.md >> +++ b/doc/user_manual.md >> @@ -834,6 +834,76 @@ 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`: is the 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%7C6d633ba6640c4aead4d708d8b6eed929%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460484244549509%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7IUAPBdmVGffqPs08B%2BaU%2FGzX7PWi4ABLxOJ70KjrAg%3D&reserved=0) >> + - `docker-daemon`: (not supported from inside of a container) >> resulting container image is made available on the local Docker Daemon >> + - `containers-storage`: (not supported from inside of a container) >> 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 + > Maybe a script to postprocess the one tarball we have would be a better > option. I do not understand why skopeo can not be used inside docker or > podman, but we _really_ should not motivate anyone to run isar plain. > Otherwise i agree that a bitbake task is a good idea and much better > than postprocessing outside of the build system. What do you mean by post-processing? I mean, a Docker image is nothing else but a couple of JSON and TAR files using a fixed file tree structure, with SHAs... But anyway writing something that does it is like reinventing the wheel, that's what tools like Umoci, Skopeo,... are for. My first PoC was in fact just a shell script post-processing the TAR file. Technically feasible, but it doesn't feel like a comfortable workflow... The initial idea was from Jan Kiszka (I forgot to add a "Suggested-by" to the commits) and after some discussion about the convenience of integrating it, I agreed that the workflow feels much better this way. Skopeo can be used inside of Docker or Podman, it's in fact what I'm doing. What doesn't work is adding the container image to a Docker Daemon (unless you pass the Docker socket to the container, what I wouldn't do) or containers/storage system (mounting the storage directory, what I wouldn't do). IMO the target users should know how to handle docker-archives (I can add that "docker load" has to be used). Silvano > > Henning > >> +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). + +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 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 12:03 ` Silvano Cirujano Cuesta @ 2021-01-12 12:18 ` Henning Schild 2021-01-12 14:52 ` Silvano Cirujano Cuesta 0 siblings, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-12 12:18 UTC (permalink / raw) To: Silvano Cirujano Cuesta; +Cc: isar-users Am Tue, 12 Jan 2021 13:03:18 +0100 schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: > On 12/01/2021 12:40, Henning Schild wrote: > > Am Tue, 12 Jan 2021 11:33:38 +0100 > > schrieb "[ext] Silvano Cirujano Cuesta" > > <silvano.cirujano-cuesta@siemens.com>: > > > >> Signed-off-by: Silvano Cirujano Cuesta > >> <silvano.cirujano-cuesta@siemens.com> --- > >> doc/user_manual.md | 70 > >> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 > >> insertions(+) > >> > >> diff --git a/doc/user_manual.md b/doc/user_manual.md > >> index a4f3d1d..ff779b1 100644 > >> --- a/doc/user_manual.md > >> +++ b/doc/user_manual.md > >> @@ -834,6 +834,76 @@ 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`: is the 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%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7Cd97fc3d66aed4a29eb8e08d8b6f20e68%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460498015543275%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1Ug2lVy%2F0mmsVu3GjTA6gYuOj9rp8gFNouuvUHkBKvQ%3D&reserved=0) > >> + - `docker-daemon`: (not supported from inside of a container) > >> resulting container image is made available on the local Docker > >> Daemon > >> + - `containers-storage`: (not supported from inside of a > >> container) 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 + > > Maybe a script to postprocess the one tarball we have would be a > > better option. I do not understand why skopeo can not be used > > inside docker or podman, but we _really_ should not motivate anyone > > to run isar plain. Otherwise i agree that a bitbake task is a good > > idea and much better than postprocessing outside of the build > > system. > > What do you mean by post-processing? I mean, a Docker image is > nothing else but a couple of JSON and TAR files using a fixed file > tree structure, with SHAs... But anyway writing something that does > it is like reinventing the wheel, that's what tools like Umoci, > Skopeo,... are for. I mean some sort of script that needs to be called after bitbake. Not nice but can be done outside of a container. > My first PoC was in fact just a shell script post-processing the TAR > file. Technically feasible, but it doesn't feel like a comfortable > workflow... Doing that in bitbake is for sure the best solution, given it works. > The initial idea was from Jan Kiszka (I forgot to add a > "Suggested-by" to the commits) and after some discussion about the > convenience of integrating it, I agreed that the workflow feels much > better this way. > > Skopeo can be used inside of Docker or Podman, it's in fact what I'm > doing. What doesn't work is adding the container image to a Docker > Daemon (unless you pass the Docker socket to the container, what I > wouldn't do) or containers/storage system (mounting the storage > directory, what I wouldn't do). IMO the target users should know how > to handle docker-archives (I can add that "docker load" has to be > used). Maybe i am just confused by the two "(not supported from inside of a container)". Does this mean one can not create the images, or not use ... or not both? The answer should probably made more clear in the docs. If creation works and only use fails, that is all fine. If creation inside a container does not work ... i would refrain from writing that code in bitbake and go post-process (extra shell script or only doc) with it. Henning > Silvano > > > > > Henning > > > >> +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). + +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 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 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:11 ` Henning Schild 0 siblings, 2 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 14:52 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users On 12/01/2021 13:18, Henning Schild wrote: > Am Tue, 12 Jan 2021 13:03:18 +0100 > schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: > >> On 12/01/2021 12:40, Henning Schild wrote: >>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>> schrieb "[ext] Silvano Cirujano Cuesta" >>> <silvano.cirujano-cuesta@siemens.com>: >>> >>>> Signed-off-by: Silvano Cirujano Cuesta >>>> <silvano.cirujano-cuesta@siemens.com> --- >>>> doc/user_manual.md | 70 >>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >>>> insertions(+) >>>> >>>> diff --git a/doc/user_manual.md b/doc/user_manual.md >>>> index a4f3d1d..ff779b1 100644 >>>> --- a/doc/user_manual.md >>>> +++ b/doc/user_manual.md >>>> @@ -834,6 +834,76 @@ 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`: is the 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%7C2e13fa7588f34212393508d8b6f43140%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460507195377080%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=oevvzWybG30IG2D1fMNPQRcfsfuvYSj1afdrIUF1ABw%3D&reserved=0) >>>> + - `docker-daemon`: (not supported from inside of a container) >>>> resulting container image is made available on the local Docker >>>> Daemon >>>> + - `containers-storage`: (not supported from inside of a >>>> container) 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 + >>> Maybe a script to postprocess the one tarball we have would be a >>> better option. I do not understand why skopeo can not be used >>> inside docker or podman, but we _really_ should not motivate anyone >>> to run isar plain. Otherwise i agree that a bitbake task is a good >>> idea and much better than postprocessing outside of the build >>> system. >> What do you mean by post-processing? I mean, a Docker image is >> nothing else but a couple of JSON and TAR files using a fixed file >> tree structure, with SHAs... But anyway writing something that does >> it is like reinventing the wheel, that's what tools like Umoci, >> Skopeo,... are for. > I mean some sort of script that needs to be called after bitbake. Not > nice but can be done outside of a container. Hmmm, obviously, but seems to be so obvious for me isn't that obvious :-) The additions DON'T NEED to run in a container, but CAN be run in a container (e.g. kas-container). If running bitbake OUTSIDE of a container (e.g. VM), then the formats "docker-daemon" and "containers-storage" should work like a charm. If running bitbake INSIDE of a container (e.g. kas-container), then the formats "docker-daemon" and "containers-storage" won't work. I don't know if doc/user_manual.md is the right place for all the clarifications that appear to be missing (this one and the dependency on skopeo and umoci), but they are clearly needed. > >> My first PoC was in fact just a shell script post-processing the TAR >> file. Technically feasible, but it doesn't feel like a comfortable >> workflow... > Doing that in bitbake is for sure the best solution, given it works. Of course, it works! ;-) > >> The initial idea was from Jan Kiszka (I forgot to add a >> "Suggested-by" to the commits) and after some discussion about the >> convenience of integrating it, I agreed that the workflow feels much >> better this way. >> >> Skopeo can be used inside of Docker or Podman, it's in fact what I'm >> doing. What doesn't work is adding the container image to a Docker >> Daemon (unless you pass the Docker socket to the container, what I >> wouldn't do) or containers/storage system (mounting the storage >> directory, what I wouldn't do). IMO the target users should know how >> to handle docker-archives (I can add that "docker load" has to be >> used). > Maybe i am just confused by the two "(not supported from inside of a > container)". Does this mean one can not create the images, or not use > ... or not both? > The answer should probably made more clear in the docs. > > If creation works and only use fails, that is all fine. If creation > inside a container does not work ... i would refrain from writing that > code in bitbake and go post-process (extra shell script or only doc) > with it. As mentioned above, running bitbake for building the SDK container image can be run from inside and outside of a container. The only difference is that running in a container the host shouldn't be reachable and therefore the formats "docker-daemon" and "containers-storage" shouldn't work. If SDK_FORMAT = "tar", then only the currently existing format (tarballed root filesystem) gets generated. If SDK_FORMAT = "tar docker-archive", then you get both the old format and a docker image archive that can be loaded on any Docker installation. Possible scenarios (probably too much information for the documentation): - Project A has a build system that generates a SDK container running bitbake without a container selecting SDK_FORMAT="docker-daemon". After finalizing pushes the SDK docker image to a container image registry (docker push ...). Developers pull the SDK container image from the container image registry (docker pull ...), start a container based on the image and mounting the directory with the source code, edit the source code on the host IDE and build in the container with the provided SDK. - Project B has a build system that generates a SDK container running bitbake with a container selecting SDK_FORMAT="tar docker-archive". Since the project doesn't have any container image registry, it distributes the container image using a network share. Team B1 do have a container image registry and distributes the image internally using it. BTW, without Team B1 project B wouldn't need anything but "tar". Clearer now? Silvano > > Henning > >> Silvano >> >>> Henning >>> >>>> +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). + +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 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 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:11 ` Henning Schild 1 sibling, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2021-01-12 14:56 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, Henning Schild; +Cc: isar-users On 12.01.21 15:52, [ext] Silvano Cirujano Cuesta wrote: > On 12/01/2021 13:18, Henning Schild wrote: >> Am Tue, 12 Jan 2021 13:03:18 +0100 >> schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: >> >>> On 12/01/2021 12:40, Henning Schild wrote: >>>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>>> schrieb "[ext] Silvano Cirujano Cuesta" >>>> <silvano.cirujano-cuesta@siemens.com>: >>>> >>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>> <silvano.cirujano-cuesta@siemens.com> --- >>>>> doc/user_manual.md | 70 >>>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >>>>> insertions(+) >>>>> >>>>> diff --git a/doc/user_manual.md b/doc/user_manual.md >>>>> index a4f3d1d..ff779b1 100644 >>>>> --- a/doc/user_manual.md >>>>> +++ b/doc/user_manual.md >>>>> @@ -834,6 +834,76 @@ 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`: is the 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`: (not supported from inside of a container) >>>>> resulting container image is made available on the local Docker >>>>> Daemon >>>>> + - `containers-storage`: (not supported from inside of a >>>>> container) 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 + >>>> Maybe a script to postprocess the one tarball we have would be a >>>> better option. I do not understand why skopeo can not be used >>>> inside docker or podman, but we _really_ should not motivate anyone >>>> to run isar plain. Otherwise i agree that a bitbake task is a good >>>> idea and much better than postprocessing outside of the build >>>> system. >>> What do you mean by post-processing? I mean, a Docker image is >>> nothing else but a couple of JSON and TAR files using a fixed file >>> tree structure, with SHAs... But anyway writing something that does >>> it is like reinventing the wheel, that's what tools like Umoci, >>> Skopeo,... are for. >> I mean some sort of script that needs to be called after bitbake. Not >> nice but can be done outside of a container. > > Hmmm, obviously, but seems to be so obvious for me isn't that obvious :-) > > The additions DON'T NEED to run in a container, but CAN be run in a container (e.g. kas-container). > > If running bitbake OUTSIDE of a container (e.g. VM), then the formats "docker-daemon" and "containers-storage" should work like a charm. > > If running bitbake INSIDE of a container (e.g. kas-container), then the formats "docker-daemon" and "containers-storage" won't work. > > I don't know if doc/user_manual.md is the right place for all the clarifications that appear to be missing (this one and the dependency on skopeo and umoci), but they are clearly needed. > Those tools need to be documented as new Isar host dependencies IF someone wants to build container images. Reasoning for choosing those (implementation aspect) can also go into the commit log that adds the bbclass. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 14:56 ` Jan Kiszka @ 2021-01-12 15:12 ` Silvano Cirujano Cuesta 2021-01-12 15:14 ` Jan Kiszka 0 siblings, 1 reply; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 15:12 UTC (permalink / raw) To: Jan Kiszka, Henning Schild; +Cc: isar-users On 12/01/2021 15:56, Jan Kiszka wrote: > On 12.01.21 15:52, [ext] Silvano Cirujano Cuesta wrote: >> On 12/01/2021 13:18, Henning Schild wrote: >>> Am Tue, 12 Jan 2021 13:03:18 +0100 >>> schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: >>> >>>> On 12/01/2021 12:40, Henning Schild wrote: >>>>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>>>> schrieb "[ext] Silvano Cirujano Cuesta" >>>>> <silvano.cirujano-cuesta@siemens.com>: >>>>> >>>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>>> <silvano.cirujano-cuesta@siemens.com> --- >>>>>> doc/user_manual.md | 70 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >>>>>> insertions(+) >>>>>> >>>>>> diff --git a/doc/user_manual.md b/doc/user_manual.md >>>>>> index a4f3d1d..ff779b1 100644 >>>>>> --- a/doc/user_manual.md >>>>>> +++ b/doc/user_manual.md >>>>>> @@ -834,6 +834,76 @@ 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`: is the 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%7C6a0a8aa1fd304e41741b08d8b70a3f6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460601925357755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=p7vacUr8Zs2X3zl183OaHjCLoTT8E10qXjkhWwC4N8c%3D&reserved=0 >>>>>> + - `docker-daemon`: (not supported from inside of a container) >>>>>> resulting container image is made available on the local Docker >>>>>> Daemon >>>>>> + - `containers-storage`: (not supported from inside of a >>>>>> container) 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 + >>>>> Maybe a script to postprocess the one tarball we have would be a >>>>> better option. I do not understand why skopeo can not be used >>>>> inside docker or podman, but we _really_ should not motivate anyone >>>>> to run isar plain. Otherwise i agree that a bitbake task is a good >>>>> idea and much better than postprocessing outside of the build >>>>> system. >>>> What do you mean by post-processing? I mean, a Docker image is >>>> nothing else but a couple of JSON and TAR files using a fixed file >>>> tree structure, with SHAs... But anyway writing something that does >>>> it is like reinventing the wheel, that's what tools like Umoci, >>>> Skopeo,... are for. >>> I mean some sort of script that needs to be called after bitbake. Not >>> nice but can be done outside of a container. >> Hmmm, obviously, but seems to be so obvious for me isn't that obvious :-) >> >> The additions DON'T NEED to run in a container, but CAN be run in a container (e.g. kas-container). >> >> If running bitbake OUTSIDE of a container (e.g. VM), then the formats "docker-daemon" and "containers-storage" should work like a charm. >> >> If running bitbake INSIDE of a container (e.g. kas-container), then the formats "docker-daemon" and "containers-storage" won't work. >> >> I don't know if doc/user_manual.md is the right place for all the clarifications that appear to be missing (this one and the dependency on skopeo and umoci), but they are clearly needed. >> > Those tools need to be documented as new Isar host dependencies IF > someone wants to build container images. Reasoning for choosing those > (implementation aspect) can also go into the commit log that adds the > bbclass. Host dependencies can be declared, right? Can I somehow make those dependencies depend on SDK_FORMATS? I'm not adding any new bbclass, only modifying the existing one. You mean patch "[RFC PATCH 1/2] sdk: support creation of container image"? My first approach was adding a new bbclass, but find this approach is more cohesive. Silvano > > Jan > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 15:12 ` Silvano Cirujano Cuesta @ 2021-01-12 15:14 ` Jan Kiszka 0 siblings, 0 replies; 25+ messages in thread From: Jan Kiszka @ 2021-01-12 15:14 UTC (permalink / raw) To: Silvano Cirujano Cuesta, Henning Schild; +Cc: isar-users On 12.01.21 16:12, Silvano Cirujano Cuesta wrote: > > On 12/01/2021 15:56, Jan Kiszka wrote: >> On 12.01.21 15:52, [ext] Silvano Cirujano Cuesta wrote: >>> On 12/01/2021 13:18, Henning Schild wrote: >>>> Am Tue, 12 Jan 2021 13:03:18 +0100 >>>> schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: >>>> >>>>> On 12/01/2021 12:40, Henning Schild wrote: >>>>>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>>>>> schrieb "[ext] Silvano Cirujano Cuesta" >>>>>> <silvano.cirujano-cuesta@siemens.com>: >>>>>> >>>>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>>>> <silvano.cirujano-cuesta@siemens.com> --- >>>>>>> doc/user_manual.md | 70 >>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >>>>>>> insertions(+) >>>>>>> >>>>>>> diff --git a/doc/user_manual.md b/doc/user_manual.md >>>>>>> index a4f3d1d..ff779b1 100644 >>>>>>> --- a/doc/user_manual.md >>>>>>> +++ b/doc/user_manual.md >>>>>>> @@ -834,6 +834,76 @@ 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`: is the 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`: (not supported from inside of a container) >>>>>>> resulting container image is made available on the local Docker >>>>>>> Daemon >>>>>>> + - `containers-storage`: (not supported from inside of a >>>>>>> container) 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 + >>>>>> Maybe a script to postprocess the one tarball we have would be a >>>>>> better option. I do not understand why skopeo can not be used >>>>>> inside docker or podman, but we _really_ should not motivate anyone >>>>>> to run isar plain. Otherwise i agree that a bitbake task is a good >>>>>> idea and much better than postprocessing outside of the build >>>>>> system. >>>>> What do you mean by post-processing? I mean, a Docker image is >>>>> nothing else but a couple of JSON and TAR files using a fixed file >>>>> tree structure, with SHAs... But anyway writing something that does >>>>> it is like reinventing the wheel, that's what tools like Umoci, >>>>> Skopeo,... are for. >>>> I mean some sort of script that needs to be called after bitbake. Not >>>> nice but can be done outside of a container. >>> Hmmm, obviously, but seems to be so obvious for me isn't that obvious :-) >>> >>> The additions DON'T NEED to run in a container, but CAN be run in a container (e.g. kas-container). >>> >>> If running bitbake OUTSIDE of a container (e.g. VM), then the formats "docker-daemon" and "containers-storage" should work like a charm. >>> >>> If running bitbake INSIDE of a container (e.g. kas-container), then the formats "docker-daemon" and "containers-storage" won't work. >>> >>> I don't know if doc/user_manual.md is the right place for all the clarifications that appear to be missing (this one and the dependency on skopeo and umoci), but they are clearly needed. >>> >> Those tools need to be documented as new Isar host dependencies IF >> someone wants to build container images. Reasoning for choosing those >> (implementation aspect) can also go into the commit log that adds the >> bbclass. > > Host dependencies can be declared, right? Can I somehow make those dependencies depend on SDK_FORMATS? > Only verbally, see beginning of user manual. > I'm not adding any new bbclass, only modifying the existing one. You mean patch "[RFC PATCH 1/2] sdk: support creation of container image"? > Ah, indeed. > My first approach was adding a new bbclass, but find this approach is more cohesive. > Fine with me. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 14:52 ` Silvano Cirujano Cuesta 2021-01-12 14:56 ` Jan Kiszka @ 2021-01-12 15:11 ` Henning Schild 2021-01-12 16:26 ` Silvano Cirujano Cuesta 1 sibling, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-12 15:11 UTC (permalink / raw) To: Silvano Cirujano Cuesta; +Cc: isar-users Am Tue, 12 Jan 2021 15:52:53 +0100 schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: > On 12/01/2021 13:18, Henning Schild wrote: > > Am Tue, 12 Jan 2021 13:03:18 +0100 > > schrieb Silvano Cirujano Cuesta > > <silvano.cirujano-cuesta@siemens.com>: > >> On 12/01/2021 12:40, Henning Schild wrote: > >>> Am Tue, 12 Jan 2021 11:33:38 +0100 > >>> schrieb "[ext] Silvano Cirujano Cuesta" > >>> <silvano.cirujano-cuesta@siemens.com>: > >>> > >>>> Signed-off-by: Silvano Cirujano Cuesta > >>>> <silvano.cirujano-cuesta@siemens.com> --- > >>>> doc/user_manual.md | 70 > >>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 > >>>> insertions(+) > >>>> > >>>> diff --git a/doc/user_manual.md b/doc/user_manual.md > >>>> index a4f3d1d..ff779b1 100644 > >>>> --- a/doc/user_manual.md > >>>> +++ b/doc/user_manual.md > >>>> @@ -834,6 +834,76 @@ 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`: is the 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%7Cde173c00-e982-4fda-8644-47edf4671d63%40ad011.siemens.com%7C6debb708331c4458499308d8b709c297%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460599822778290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iAJ9RTgmXSiZJhSlqinclxLduxg1FXJYJ%2Bt8%2Beqc4g0%3D&reserved=0) > >>>> + - `docker-daemon`: (not supported from inside of a container) > >>>> resulting container image is made available on the local Docker > >>>> Daemon > >>>> + - `containers-storage`: (not supported from inside of a > >>>> container) 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 + > >>> Maybe a script to postprocess the one tarball we have would be a > >>> better option. I do not understand why skopeo can not be used > >>> inside docker or podman, but we _really_ should not motivate > >>> anyone to run isar plain. Otherwise i agree that a bitbake task > >>> is a good idea and much better than postprocessing outside of the > >>> build system. > >> What do you mean by post-processing? I mean, a Docker image is > >> nothing else but a couple of JSON and TAR files using a fixed file > >> tree structure, with SHAs... But anyway writing something that does > >> it is like reinventing the wheel, that's what tools like Umoci, > >> Skopeo,... are for. > > I mean some sort of script that needs to be called after bitbake. > > Not nice but can be done outside of a container. > > Hmmm, obviously, but seems to be so obvious for me isn't that obvious > :-) > > The additions DON'T NEED to run in a container, but CAN be run in a > container (e.g. kas-container). > > If running bitbake OUTSIDE of a container (e.g. VM), then the formats > "docker-daemon" and "containers-storage" should work like a charm. > > If running bitbake INSIDE of a container (e.g. kas-container), then > the formats "docker-daemon" and "containers-storage" won't work. > > I don't know if doc/user_manual.md is the right place for all the > clarifications that appear to be missing (this one and the dependency > on skopeo and umoci), but they are clearly needed. > > > > >> My first PoC was in fact just a shell script post-processing the > >> TAR file. Technically feasible, but it doesn't feel like a > >> comfortable workflow... > > Doing that in bitbake is for sure the best solution, given it > > works. > Of course, it works! ;-) > > > >> The initial idea was from Jan Kiszka (I forgot to add a > >> "Suggested-by" to the commits) and after some discussion about the > >> convenience of integrating it, I agreed that the workflow feels > >> much better this way. > >> > >> Skopeo can be used inside of Docker or Podman, it's in fact what > >> I'm doing. What doesn't work is adding the container image to a > >> Docker Daemon (unless you pass the Docker socket to the container, > >> what I wouldn't do) or containers/storage system (mounting the > >> storage directory, what I wouldn't do). IMO the target users > >> should know how to handle docker-archives (I can add that "docker > >> load" has to be used). > > Maybe i am just confused by the two "(not supported from inside of a > > container)". Does this mean one can not create the images, or not > > use ... or not both? > > The answer should probably made more clear in the docs. > > > > If creation works and only use fails, that is all fine. If creation > > inside a container does not work ... i would refrain from writing > > that code in bitbake and go post-process (extra shell script or > > only doc) with it. > > As mentioned above, running bitbake for building the SDK container > image can be run from inside and outside of a container. The only > difference is that running in a container the host shouldn't be > reachable and therefore the formats "docker-daemon" and > "containers-storage" shouldn't work. > > If SDK_FORMAT = "tar", then only the currently existing format > (tarballed root filesystem) gets generated. If SDK_FORMAT = "tar > docker-archive", then you get both the old format and a docker image > archive that can be loaded on any Docker installation. > > Possible scenarios (probably too much information for the > documentation): > > - Project A has a build system that generates a SDK container running > bitbake without a container selecting SDK_FORMAT="docker-daemon". > After finalizing pushes the SDK docker image to a container image > registry (docker push ...). Developers pull the SDK container image > from the container image registry (docker pull ...), start a > container based on the image and mounting the directory with the > source code, edit the source code on the host IDE and build in the > container with the provided SDK. > > - Project B has a build system that generates a SDK container running > bitbake with a container selecting SDK_FORMAT="tar docker-archive". > Since the project doesn't have any container image registry, it > distributes the container image using a network share. Team B1 do > have a container image registry and distributes the image internally > using it. BTW, without Team B1 project B wouldn't need anything but > "tar". > > Clearer now? I think so. One bitbake call in a container will not work for most of what you propose. It all needs another bitbake call outside ... which i would call "post-processing". That is not nice, there is no need to even write that in bitbake, maybe even harm because it leads people to running isar native. Lets face it, its again containers causing problems with containers. I say add a few words to the documentation and let the container boys deal with that stuff, outside of isar. In a code-base far far away. But that is just my frustrated take from all the container crap that is popping up all over the place, causing more problems than it solves. Henning > > Silvano > > > > > Henning > > > >> Silvano > >> > >>> Henning > >>> > >>>> +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). + +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 > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 2/2] docs: document usage of sdk container images 2021-01-12 15:11 ` Henning Schild @ 2021-01-12 16:26 ` Silvano Cirujano Cuesta 0 siblings, 0 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-12 16:26 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users On 12/01/2021 16:11, Henning Schild wrote: > Am Tue, 12 Jan 2021 15:52:53 +0100 > schrieb Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>: > >> On 12/01/2021 13:18, Henning Schild wrote: >>> Am Tue, 12 Jan 2021 13:03:18 +0100 >>> schrieb Silvano Cirujano Cuesta >>> <silvano.cirujano-cuesta@siemens.com>: >>>> On 12/01/2021 12:40, Henning Schild wrote: >>>>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>>>> schrieb "[ext] Silvano Cirujano Cuesta" >>>>> <silvano.cirujano-cuesta@siemens.com>: >>>>> >>>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>>> <silvano.cirujano-cuesta@siemens.com> --- >>>>>> doc/user_manual.md | 70 >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 >>>>>> insertions(+) >>>>>> >>>>>> diff --git a/doc/user_manual.md b/doc/user_manual.md >>>>>> index a4f3d1d..ff779b1 100644 >>>>>> --- a/doc/user_manual.md >>>>>> +++ b/doc/user_manual.md >>>>>> @@ -834,6 +834,76 @@ 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`: is the 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%7Cac350d26903a48f170ca08d8b70c52e7%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460610844428609%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=fkge4VhJrr7UJtMrsWAGhIfG6i0Ho9Wf0eOGhLXA2Q8%3D&reserved=0) >>>>>> + - `docker-daemon`: (not supported from inside of a container) >>>>>> resulting container image is made available on the local Docker >>>>>> Daemon >>>>>> + - `containers-storage`: (not supported from inside of a >>>>>> container) 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 + >>>>> Maybe a script to postprocess the one tarball we have would be a >>>>> better option. I do not understand why skopeo can not be used >>>>> inside docker or podman, but we _really_ should not motivate >>>>> anyone to run isar plain. Otherwise i agree that a bitbake task >>>>> is a good idea and much better than postprocessing outside of the >>>>> build system. >>>> What do you mean by post-processing? I mean, a Docker image is >>>> nothing else but a couple of JSON and TAR files using a fixed file >>>> tree structure, with SHAs... But anyway writing something that does >>>> it is like reinventing the wheel, that's what tools like Umoci, >>>> Skopeo,... are for. >>> I mean some sort of script that needs to be called after bitbake. >>> Not nice but can be done outside of a container. >> Hmmm, obviously, but seems to be so obvious for me isn't that obvious >> :-) >> >> The additions DON'T NEED to run in a container, but CAN be run in a >> container (e.g. kas-container). >> >> If running bitbake OUTSIDE of a container (e.g. VM), then the formats >> "docker-daemon" and "containers-storage" should work like a charm. >> >> If running bitbake INSIDE of a container (e.g. kas-container), then >> the formats "docker-daemon" and "containers-storage" won't work. >> >> I don't know if doc/user_manual.md is the right place for all the >> clarifications that appear to be missing (this one and the dependency >> on skopeo and umoci), but they are clearly needed. >> >>> >>>> My first PoC was in fact just a shell script post-processing the >>>> TAR file. Technically feasible, but it doesn't feel like a >>>> comfortable workflow... >>> Doing that in bitbake is for sure the best solution, given it >>> works. >> Of course, it works! ;-) >>> >>>> The initial idea was from Jan Kiszka (I forgot to add a >>>> "Suggested-by" to the commits) and after some discussion about the >>>> convenience of integrating it, I agreed that the workflow feels >>>> much better this way. >>>> >>>> Skopeo can be used inside of Docker or Podman, it's in fact what >>>> I'm doing. What doesn't work is adding the container image to a >>>> Docker Daemon (unless you pass the Docker socket to the container, >>>> what I wouldn't do) or containers/storage system (mounting the >>>> storage directory, what I wouldn't do). IMO the target users >>>> should know how to handle docker-archives (I can add that "docker >>>> load" has to be used). >>> Maybe i am just confused by the two "(not supported from inside of a >>> container)". Does this mean one can not create the images, or not >>> use ... or not both? >>> The answer should probably made more clear in the docs. >>> >>> If creation works and only use fails, that is all fine. If creation >>> inside a container does not work ... i would refrain from writing >>> that code in bitbake and go post-process (extra shell script or >>> only doc) with it. >> As mentioned above, running bitbake for building the SDK container >> image can be run from inside and outside of a container. The only >> difference is that running in a container the host shouldn't be >> reachable and therefore the formats "docker-daemon" and >> "containers-storage" shouldn't work. >> >> If SDK_FORMAT = "tar", then only the currently existing format >> (tarballed root filesystem) gets generated. If SDK_FORMAT = "tar >> docker-archive", then you get both the old format and a docker image >> archive that can be loaded on any Docker installation. >> >> Possible scenarios (probably too much information for the >> documentation): >> >> - Project A has a build system that generates a SDK container running >> bitbake without a container selecting SDK_FORMAT="docker-daemon". >> After finalizing pushes the SDK docker image to a container image >> registry (docker push ...). Developers pull the SDK container image >> from the container image registry (docker pull ...), start a >> container based on the image and mounting the directory with the >> source code, edit the source code on the host IDE and build in the >> container with the provided SDK. >> >> - Project B has a build system that generates a SDK container running >> bitbake with a container selecting SDK_FORMAT="tar docker-archive". >> Since the project doesn't have any container image registry, it >> distributes the container image using a network share. Team B1 do >> have a container image registry and distributes the image internally >> using it. BTW, without Team B1 project B wouldn't need anything but >> "tar". >> >> Clearer now? > I think so. One bitbake call in a container will not work for most of > what you propose. It all needs another bitbake call outside ... which i > would call "post-processing". That is not nice, there is no need to even > write that in bitbake, maybe even harm because it leads people to > running isar native. I'm not sure if we are on the same page... bitbake -c populate_sdk ... runs in a container as long as neither "docker-daemon" nor "containers-storage" are in SDK_FORMATS. I could simply remove "docker-daemon" and "containers-storage" from the list and everything would run INSIDE or OUTSIDE of a container. > > Lets face it, its again containers causing problems with containers. It's not containers causing problems with containers. It's software contained by containers :-) The reason for running the whole thing in a container doesn't have anything to do with this patch. The fact of running it in a container is posing certain limits to the whole environment and this patch is being affected by these limits. Let's say so, this patch (or the limitations if might face) is "just another victim" of the ISAR requirements that motivate the usage of containers. In fact I wouldn't see the need for running this functionality inside a container in a Yocto environment (it's not really ISAR-specific and probably with small changes should work). > > I say add a few words to the documentation and let the container boys > deal with that stuff, outside of isar. In a code-base far far away. But > that is just my frustrated take from all the container crap that is > popping up all over the place, causing more problems than it solves. This is not for "container fanboys" or so, but rather "just another packaging". It's possible distributing the SDK root filesystem in a Debian package, or an RPM package, or an Alpine package, or an Arch package,... but distributing container images is in certain environments easier. I've heard of more SDKs being distributed as container images, that's why I would expect the demand to exist. But I don't have so much contact with the ISAR users as most of you have to confirm it. That's why this is a RFC. I can understand your frustration with containers. The question is if you can stand that frustration to reduce the frustration of the ISAR users (assuming this patch does so). Silvano > > Henning > >> Silvano >> >>> Henning >>> >>>> Silvano >>>> >>>>> Henning >>>>> >>>>>> +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). + +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 -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/2] support generation of sdk container images 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 10:33 ` [RFC PATCH 2/2] docs: document usage of sdk container images Silvano Cirujano Cuesta @ 2021-01-14 13:56 ` Silvano Cirujano Cuesta 2021-01-14 18:32 ` Henning Schild 2021-01-15 7:09 ` Jan Kiszka 2 siblings, 2 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-14 13:56 UTC (permalink / raw) To: isar-users I wonder how to interpret the current feelings about this proposal: * There's no interest at all. * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) Thanks! Silvano On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: > This patch series adds to the SDK generation (task `populate_sdk`) the > possibility of generating container images containing the SDK in > different formats (multiple formats can be generated at once). > > Up-to-now the task `populate_sdk` generates the sdk root filesystem (in > both as a file tree and in a tarball) that can be chrooted to. The same > root filesystem can be easily distributed as a container image and > started as a container. > > It's even possible extracting the root filesystem from a container > image, using the container image format only as a sort of packaging > system for easy distribution. > > More information about its usage is documented in the file > docs/user_manual.md. > > 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. > > Silvano Cirujano Cuesta (2): > sdk: support creation of container image > docs: document usage of sdk container images > > doc/user_manual.md | 70 +++++++++++++++++ > meta/classes/image-sdk-extension.bbclass | 99 ++++++++++++++++++++++-- > 2 files changed, 162 insertions(+), 7 deletions(-) > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/2] support generation of sdk container images 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 1 sibling, 1 reply; 25+ messages in thread From: Henning Schild @ 2021-01-14 18:32 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta; +Cc: isar-users Please do not make my voice count too much, the moment i see "docker" i go "strong reject". A reflex i can not help ... maybe its valuable and i am too much blinded by stereotypes. Henning Am Thu, 14 Jan 2021 14:56:59 +0100 schrieb "[ext] Silvano Cirujano Cuesta" <silvano.cirujano-cuesta@siemens.com>: > I wonder how to interpret the current feelings about this proposal: > > * There's no interest at all. > > * I haven't succeed on raising enough interest. In that case I'd > need more input from people who see the demand for this functionality > to better understand what's missing in my proposal. > > * There's interest, but I should update the patch according the > comments up-to-now before I send a 1st patch series proposal (or a > 2nd RFC). > > I'd appreciate any feedback. The more decision power the person > giving the feedback, the more valuable it is for me :-) > > Thanks! > > Silvano > > > On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: > > This patch series adds to the SDK generation (task `populate_sdk`) > > the possibility of generating container images containing the SDK in > > different formats (multiple formats can be generated at once). > > > > Up-to-now the task `populate_sdk` generates the sdk root filesystem > > (in both as a file tree and in a tarball) that can be chrooted to. > > The same root filesystem can be easily distributed as a container > > image and started as a container. > > > > It's even possible extracting the root filesystem from a container > > image, using the container image format only as a sort of packaging > > system for easy distribution. > > > > More information about its usage is documented in the file > > docs/user_manual.md. > > > > 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. > > > > Silvano Cirujano Cuesta (2): > > sdk: support creation of container image > > docs: document usage of sdk container images > > > > doc/user_manual.md | 70 +++++++++++++++++ > > meta/classes/image-sdk-extension.bbclass | 99 > > ++++++++++++++++++++++-- 2 files changed, 162 insertions(+), 7 > > deletions(-) > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/2] support generation of sdk container images 2021-01-14 18:32 ` Henning Schild @ 2021-01-15 8:11 ` Silvano Cirujano Cuesta 0 siblings, 0 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-15 8:11 UTC (permalink / raw) To: Henning Schild; +Cc: isar-users On 14/01/2021 19:32, Henning Schild wrote: > Please do not make my voice count too much, the moment i see "docker" i > go "strong reject". A reflex i can not help ... maybe its valuable and > i am too much blinded by stereotypes. I don't make your voice count too much, only as much as it's worth, being you one of the main contributors. I'm aware of your concerns about anything related to containers. But your concern is valid, since questioning the need for integrating completely new technologies and tools is always meaningful. If you're biased in one direction, I'm biased in the other one. My previous e-mail was sort of a call for the opinion of someone less biased. Cheers, Silvano > > Henning > > Am Thu, 14 Jan 2021 14:56:59 +0100 > schrieb "[ext] Silvano Cirujano Cuesta" > <silvano.cirujano-cuesta@siemens.com>: > >> I wonder how to interpret the current feelings about this proposal: >> >> * There's no interest at all. >> >> * I haven't succeed on raising enough interest. In that case I'd >> need more input from people who see the demand for this functionality >> to better understand what's missing in my proposal. >> >> * There's interest, but I should update the patch according the >> comments up-to-now before I send a 1st patch series proposal (or a >> 2nd RFC). >> >> I'd appreciate any feedback. The more decision power the person >> giving the feedback, the more valuable it is for me :-) >> >> Thanks! >> >> Silvano >> >> >> On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: >>> This patch series adds to the SDK generation (task `populate_sdk`) >>> the possibility of generating container images containing the SDK in >>> different formats (multiple formats can be generated at once). >>> >>> Up-to-now the task `populate_sdk` generates the sdk root filesystem >>> (in both as a file tree and in a tarball) that can be chrooted to. >>> The same root filesystem can be easily distributed as a container >>> image and started as a container. >>> >>> It's even possible extracting the root filesystem from a container >>> image, using the container image format only as a sort of packaging >>> system for easy distribution. >>> >>> More information about its usage is documented in the file >>> docs/user_manual.md. >>> >>> 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. >>> >>> Silvano Cirujano Cuesta (2): >>> sdk: support creation of container image >>> docs: document usage of sdk container images >>> >>> doc/user_manual.md | 70 +++++++++++++++++ >>> meta/classes/image-sdk-extension.bbclass | 99 >>> ++++++++++++++++++++++-- 2 files changed, 162 insertions(+), 7 >>> deletions(-) -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/2] support generation of sdk container images 2021-01-14 13:56 ` [RFC PATCH 0/2] support generation " Silvano Cirujano Cuesta 2021-01-14 18:32 ` Henning Schild @ 2021-01-15 7:09 ` Jan Kiszka 2021-01-15 8:16 ` Silvano Cirujano Cuesta 1 sibling, 1 reply; 25+ messages in thread From: Jan Kiszka @ 2021-01-15 7:09 UTC (permalink / raw) To: [ext] Silvano Cirujano Cuesta, isar-users On 14.01.21 14:56, [ext] Silvano Cirujano Cuesta wrote: > I wonder how to interpret the current feelings about this proposal: > > * There's no interest at all. > > * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. > > * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). > > I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) > The level of feedback you received is already quite good for a first round :), and there is usually no early feedback from maintainers. I would say update the series, addressing that smaller issue(s) and remove the RFC. I'll also give that a try soon. Thanks a lot, Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [RFC PATCH 0/2] support generation of sdk container images 2021-01-15 7:09 ` Jan Kiszka @ 2021-01-15 8:16 ` Silvano Cirujano Cuesta 0 siblings, 0 replies; 25+ messages in thread From: Silvano Cirujano Cuesta @ 2021-01-15 8:16 UTC (permalink / raw) To: Jan Kiszka, isar-users On 15/01/2021 08:09, Jan Kiszka wrote: > On 14.01.21 14:56, [ext] Silvano Cirujano Cuesta wrote: >> I wonder how to interpret the current feelings about this proposal: >> >> * There's no interest at all. >> >> * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. >> >> * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). >> >> I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) >> > The level of feedback you received is already quite good for a first > round :), and there is usually no early feedback from maintainers. I don't meant that the feedback was bad, only mostly opposed :-) > I would say update the series, addressing that smaller issue(s) and > remove the RFC. I'll also give that a try soon. This is enough feedback to confirm me on moving forward. My next steps are then: addressing the small issues and adding in the cover letter information on how to easily test it. Silvano > > Thanks a lot, > Jan > -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2021-01-15 8:17 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox