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

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

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