Re: [RFC PATCH 2/2] docs: document usage of sdk container images

[Jan Kiszka <jan.kiszka@siemens.com>]

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