Hi Claudius,

[Re: [RFC] Image templates] On 20.12.02 (Wed 14:00) Claudius Heine wrote:

> Hi Cedric,
> 
> On 2020-12-01 08:59, Cedric Hombourger wrote:
> > Image Templates for ISAR
> > ========================
> > 
> > Introduction
> > ------------
> > 
> > Embedded System projects may have multiple teams working at different
> > levels. It is not uncommon to have groups creating a "base platform"
> > which is handed over to product teams to customize further.
> > Thanks to ISAR leveraging bitbake, image recipes from a base layer may
> > be easily extended by product layers but also with its ability to
> > produce and use a `base-apt` instead of upstream package feeds.
> > This workflow functions well in many cases, it may not be optimal for
> > application teams. Such teams are typically receiving a base platform
> > release that is likely to be left untouched for weeks.
> > Creating a product image for those teams is sometimes as easy as adding
> > a few packages.
> > 
> > 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_.
> 
> In principle I understand your requirement, however I don't think Isar (and
> possible Debian) is the right base for this.
> 
> What you probably require is some sort of functional and non-destructive
> root-fs build approach to root file system, that lets you arbitrarily cache
> and distribute each stage of the root fs build. Generating and reusing the
> 'base-apt' repository is much easier than it would be for root file systems.
> 
> Also stuff like docker solves only a small part of that solution.
> 
> You will probably have to build a new system inspired by stuff like the
> bazel build system[1], and nixox[2] or guixos[3] and maybe even stuff like
> ostree [4].

Thank you for the suggestions.  I had looked at bazel a while back for
something unrelated but my impression of it is really that it's aimed
squarely at application development teams, so never really investigated
how they do their builds.  We had a proof-of-concept working about a year
ago with ostree on top of Isar but ultimately that didn't seem to be a
good fit either since it placed significant restrictions on the
filesystem.  In the intervening time the project has also moved in a more
container-focused direction, so it also doesn't seem to address this space
any longer.

NixOS and Guix both warrant further investigation, I think, though I've
done a bit of preliminary work with NixOS and I think the differences
between it and Debian in package format and maintenance tools are too
great to make it practical.

In short, I definitely agree this is potentially a significant adjustment
and a large undertaking, but Isar does also seem almost uniquely
positioned to make this work, and why whe're making this proposal and
looking for feedback.

> The rest of what you describe sounds like they would try to shoehorn this
> into the existing isar build process and then trying to explicitly fix just
> some of the many future issues you will run into, instead of actually
> designing something that is actually able to deal with all those issues in a
> generic way.

Are you thinking of something specific in the design that you see being
long-term problematic, or is this more of a general concern like "this is
plainly out of scope for Isar"?  Our objective is to produce something
that compliments and extends existing workflows, not to bolt on something
that doesn't make sense, so we're open to all feedback and views of what
could be danger areas or sources for future pain.

> Personally, I would be interested in such a new system, but that will take
> serious dedication to design and implement it properly.
> 
> Changing that now in Isar will probably break a lot of assumptions and
> therefore limit its usefulness.

That's definitley not our goal and the approach we are proposing, done as
a new class, intends to ensure it doesn't spider out and touch things that
will impact unrelated Isar workflows.  If you can point to areas where
we're potentially breaking assumptions in Isar, most likely around image
assembly, but maybe other oareas, we'd be very happy to refine our view
and goals.

Thanks for the feedback,
-Joe.

> This suggestions reminds me a bit as the eSDK of OE, where I still couldn't
> really find a use for and from my experience creates more issues than it
> actually solves.
> 
> regards,
> Claudius
> 
> [1] https://www.bazel.build/
> [2] https://nixos.org/
> [3] https://guix.gnu.org/
> [4] https://ostreedev.github.io/ostree/introduction/

-- 
-Joe MacDonald.
Linux Architect | Mentor® A Siemens Business
:wq