From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6916819860201668608 X-Received: by 2002:ac2:52b8:: with SMTP id r24mr2438585lfm.219.1610463392416; Tue, 12 Jan 2021 06:56:32 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:810b:: with SMTP id d11ls605913ljg.11.gmail; Tue, 12 Jan 2021 06:56:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJxWso6fYkR13SPTNQp73RtGbS5tNG9bMZfn9jc1hZMV+q0t/SU4u0eUzZ3f/rAHwiIsyjoW X-Received: by 2002:a05:651c:1047:: with SMTP id x7mr2281743ljm.114.1610463391148; Tue, 12 Jan 2021 06:56:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610463391; cv=none; d=google.com; s=arc-20160816; b=JbCG3otOW3me0Avq/f3B5x9O2kNrQGjBlVLPQAoifWX0OOyqt55ex8xvCiTezs8HHe ck3bic7B9hCktthWRtzFcD/+QmJq3+FEjgWeGOJNFhE1d2DYMri57YN13ho4JkT2aiPz 1IzQemwigG0Q2Pkk+WwjEOKRkpkfDjApRDNnytdGz+8RhWCNq96A3pWOTuOI99IfNlKh /wyDIrFV95zEcPkTgdqONohtbBhflveBUqIXRXawyaX8FlLuztrnQKgyuFUpvt8DOf2x W+sP3WvdCd9VG7IJQ6UFItEBo0kCRbqZXXHgFJjAANAAL3uoBmnEKqMKBw+tXAlfKJKW o9ng== 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=tNXmH7Sij9tszj9uPjlAFaCxe4gYG+0QKsMrAFo5bYU=; b=IXbFTnes7a8WbyvuaduCZCcl8tNtVrE39rN+iEQFKNa+Fk5NsYnZHoNw9UnDGWQrkY kAu96l9AiifE9TO3MvVLhsGUR+5IKozphFzL/AWw8RP9pPdffObZuYqA4wlsnBBmKMjk sIav6/O68L5Qj2tNBCpMSTAmmP7KHNawFr7U8eeli4g9ZvbK6vsRwWoQmPUZMNX0D+03 FeCy5X03Hj/20Ona/haIdKOWBLXdhpbQS+MBgkDz6xDh0IHk8o7z49CHGSo+YQy12jkK sysyKgSDHUw1PEz30ZXeiypi9HfMcHMjepRfmTXRSSl2Kku5/22ROOBkrpfufXVhRwuI /6ig== 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 j15si168188lfk.12.2021.01.12.06.56.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 06:56:31 -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 10CEuUm6027459 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 12 Jan 2021 15:56:30 +0100 Received: from [167.87.43.185] ([167.87.43.185]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 10CEuTZd013327; Tue, 12 Jan 2021 15:56:30 +0100 Subject: Re: [RFC PATCH 2/2] docs: document usage of sdk container images To: "[ext] 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> From: Jan Kiszka Message-ID: <9deb7074-1a0b-d43b-6d21-06473a79d3db@siemens.com> Date: Tue, 12 Jan 2021 15:56:29 +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: <134bd608-0319-7649-52a4-a5e647740d50@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: 3VIkZ/Frbc94 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. Jan -- Siemens AG, T RDA IOT Corporate Competence Center Embedded Linux