Re: [RFC] Image templates

[Baurzhan Ismagulov <ibr@radix50.net>]

Hello Cedric,

thanks for the early RFC and the constructive discussion.

On Tue, Dec 01, 2020 at 08:59:20AM +0100, Cedric Hombourger wrote:
> In such cases, it may be desirable to have a mechanism for ISAR to construct product images starting from the base platform root file-system instead of ISAR's bootstrap root file-system. We will refer
> to these base platform root file-systems as _Template Images_.

Do I understand correctly, one way might look like this:

* Use case: Speed up component developer workflow.

* Approach:

  * Reuse build artifacts (rootfs, buildchroot, etc.).

  * Split builds (artifact preparation and consumption).

Artifact reuse and developer efficiency are among Isar's goals. We've been
(lazily) looking at this from the developer and CI PoVs. One step was isar-apt,
although it has to be finished in this regard (with pristine sources, the
packages are built even if present in isar-apt). I think especially for
application developers, template images (for some reason, I always write "image
templates" first :) ) would be a major time saver. We wanted to have some
benchmarking first (e.g., download, bootstrap, package building, imaging) -- if
you have any (even rough) figures, please share.

>From the practical perspective, I'm for any small, quick, least-invasive and
conceptually complete approach that we could gather experience with and discuss
the next steps. One way could be e.g.:

* Deploy a template image and implement consuming it.

* Package recipes depend on the template image. The image can be provided by
  building, or as a binary. The former is the default. One can switch to the
  latter in the configuration.

* There is a way to check whether the image is up-to-date regardless of the
  current mode (e.g., a task).

* Document the whole cycle -- where the image is stored, how it is copied to
  the working copy, etc.

With this experience, we could add the template e.g. to isar-bootstrap, as
originally implemented by Claudius.


Regarding source package quality and license compliance, I think it's in the
best interest of the product owners to provide that and isn't related to the
proposal.


Regarding alternative tooling, I see it rather in somewhat other areas which
are also not related to the topic:

* Standalone base-apt tooling would be very handy for certain use cases. As the
  current base-apt works, there is currently not much pressure behind this.

* Returning to multistrapping would allow efficient essential package
  replacement. We had a discussion with debian-embedded people regarding a
  Python implementation.

* apt introspection -- IIRC, ELBE colleagues use python-apt.

* Moving to pseudo instead of sudo -- Yocto is an example that this works. In
  general, we could clean up e.g. lazy umounts, replace bind mounts with cp
  -al, etc.

* From the very beginning, we were aware that bitbake provides only 80% of the
  functionality necessary for Debian (e.g., Build-Depends, building the
  pipeline after fetching). Meanwhile, we see ways how it could be improved, so
  we still haven't reached the bitbake vs. new tool discussion.


With kind regards,
Baurzhan.