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

[Silvano Cirujano Cuesta <silvano.cirujano-cuesta@siemens.com>]

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&amp;data=04%7C01%7Csilvano.cirujano-cuesta%40siemens.com%7C6a0a8aa1fd304e41741b08d8b70a3f6c%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637460601925357755%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=p7vacUr8Zs2X3zl183OaHjCLoTT8E10qXjkhWwC4N8c%3D&amp;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