From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6916819860201668608 X-Received: by 2002:a5d:6a05:: with SMTP id m5mr4779547wru.96.1610464466941; Tue, 12 Jan 2021 07:14:26 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:2094:: with SMTP id g142ls1480593wmg.2.gmail; Tue, 12 Jan 2021 07:14:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJxM/H5RvnycfkVrzKhtg15xNqkbbGeQLzcs3D5yRCNvPr7Yg92hvHf5ozDvBof3163Ibt3o X-Received: by 2002:a7b:c0c8:: with SMTP id s8mr4078457wmh.123.1610464465903; Tue, 12 Jan 2021 07:14:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610464465; cv=none; d=google.com; s=arc-20160816; b=ymFOltMK3X5MNcR7wJ8iV1idk8BjS667qP+EFsvcirgQ2WshyuErwGdsjTzEhPbRx9 n1KjwiSjwZHYp0CiXC1Kf3PiTnojNyaB0SxWZNB+Q8fbaMcTdPdsfOz7QRC2+NJWPawf aaplTv0IaiMRny4+rGl+C2cNRlb6iMRTl4g6cMyQghB2d2BX8GwoUiBEO3MDoT41ljIi nVvsuATYFPx5gyCAgCdhqS+H4e6Nr/laAI6YKBqbv4PYR1XrvuNpZ20+kn7NqspM4QL0 Kq2LN5+wt1lQP/utTiSrLk+wkYXHIg82RgSpwXL/w5rc35wXeN1wzMt85SVk2ARW1fi0 cuoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:cc:to:subject; bh=fV2Y5QplGzOpNkElVqfUFHyQbw81n4wcswF3H/1sCQ4=; b=imEeNGMV9MPfdtLZpCV9PrhEod8NiEaNyepYeG4B0ulNn+mDev7Kj6pmpuHQmbxegP lspH6f0+vjEiPJSS/QwseGRbheWZ8tcZ6jFMvAD6x3IUO8eyJR58LXmd/MnEnt6cwhWC YRBFBrmiDBwNxJhgjFxHGHZgdOOLecdd8dxCzs3CNi82fPN82t8db66Cer4pq92DzRrh rdJYd5CabvNTThdUB6Tnj3L/lSfB/gyQO/+2fjb+u3NGLAmv5eG4+drq8sREsr30BtmU FwBatpQ9izZxLxOJkXEJWj6TMOrjIQOxQ/8vtuy4Y0j0VnMi77fI1FfDHuVABc+m3FDk uQBw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id n8si203268wrr.0.2021.01.12.07.14.25 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 07:14:25 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 10CFEP2L012106 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 12 Jan 2021 16:14:25 +0100 Received: from [167.87.43.185] ([167.87.43.185]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 10CFEN0l002343; Tue, 12 Jan 2021 16:14:25 +0100 Subject: Re: [RFC PATCH 2/2] docs: document usage of sdk container images To: Silvano Cirujano Cuesta , Henning Schild Cc: isar-users@googlegroups.com References: <20210112103338.14712-1-silvano.cirujano-cuesta@siemens.com> <20210112103338.14712-3-silvano.cirujano-cuesta@siemens.com> <20210112124021.5a9f44ce@md1za8fc.ad001.siemens.net> <20210112131814.5a3cf85a@md1za8fc.ad001.siemens.net> <134bd608-0319-7649-52a4-a5e647740d50@siemens.com> <9deb7074-1a0b-d43b-6d21-06473a79d3db@siemens.com> <125a68d1-367d-8591-a29d-9430e060ad86@siemens.com> From: Jan Kiszka Message-ID: <7e2bf403-38ca-dc0a-ce97-7ff48cede2ff@siemens.com> Date: Tue, 12 Jan 2021 16:14:22 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <125a68d1-367d-8591-a29d-9430e060ad86@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TUID: FJkV0jtSHDVj 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 : >>>> >>>>> On 12/01/2021 12:40, Henning Schild wrote: >>>>>> Am Tue, 12 Jan 2021 11:33:38 +0100 >>>>>> schrieb "[ext] Silvano Cirujano Cuesta" >>>>>> : >>>>>> >>>>>>> Signed-off-by: Silvano Cirujano Cuesta >>>>>>> --- >>>>>>> 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