Re: [PATCH V2 0/2] Add support for containerized root filesystems

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

On 09.02.21 18:37, Silvano Cirujano Cuesta wrote:
> 
> On 09/02/2021 17:50, Jan Kiszka wrote:
>> On 09.02.21 15:10, [ext] Silvano Cirujano Cuesta wrote:
>>> This patch series provides support for containerized root filesystems,
>>> for both target images and SDKs.
>>>
>>> For containerized target images the new image type `container-img` has
>>> been added.
>>>
>>> For containerized SDKs the task `populate_sdk` has been extended.
>>>
>>> Containerized root filesystems are easy to distribute and run, enabling
>>> this way following scenarios:
>>>  - Use ISAR to build container images meant to be run only in containers.
>>>  - Use the same ISAR configuration to build images for containers, VMs
>>>    and bare-metal.
>>>  - Easy SDK distribution and "installation".
>>>  - Quickly testing certain applications in the workstation using the
>>>    target root filesystem.
>>>
>>> In order to build containerized rootfilesystems `IMAGE_TYPE` as to be
>>> `container-img`, additionally the container image format can be selected
>>> with the variable `CONTAINER_FORMAT`. The default format is
>>> `docker-archive`.
>>>
>> But you dropped control over building the SDK (and only the SDK) as
>> container, didn't you? Where did that SDK_FORMATS go?
>>
>> Jan
> 
> Yes, if we want to have so much control, them we'll need at least 3 variables instead of 2. But I can introduce them, if desired.
> 
> Two of them to select the container format(s) to generate. For these I'd propose CONTAINER_FORMAT and SDK_FORMAT.
> 
> Another one to select the build of a container image for target, IMAGE_TYPE="container-img" would be my proposal.
> 
> The selection of containerized SDK would be implicit with the presence of a valid SDK_FORMAT. If that selection should be explicit, then a 4th variable would be needed.
> 
> I don't have a strong opinion on this, so simply make a wish.

There are two use cases (target image format = container, SDK =
container), and those should be independently configurable.

I was fine with your previous way of configuring the SDK_FORMATS. Here,
we should add container-img as another IMAGE_TYPE, further configurable
regarding its output formats (CONTAINER_FORMATS). And both use cases
should share container-img.bbclass for their common bits.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux