interest in a minimal image recipe

[Ed Tanous]

On Tue, Sep 15, 2020 at 1:31 PM Brad Bishop <bradleyb at fuzziesquirrel.com> wrote:
>
> I've heard a handful of times that meta-phosphor users often have to
> remove the latest feature added by default to obmc-phosphor-image.
>
> I have an RFC for an empty image that these users could bbappend and
> opt-in to specific image features instead of having to repeatedly
> opt-out.
>
> If you like the opt-in approach, please drop a +1 and/or review my patch:
>
> https://gerrit.openbmc-project.xyz/c/openbmc/meta-phosphor/+/36516
>
> I bring this up now because I, and others have been adding new image
> features to obmc-phosphor-image (e.g. turned on by default), and I would
> like to start a discussion about what it means for an application to be
> in the OpenBMC github organization.  I would propose that it means it is
> enabled and turned on by default in obmc-phosphor-image.
>
> Looking forward to your thoughts.
>
> -brad

As a general description, this sounds great, but as always the devil
is in the details.  The biggest obstacle to this I see is that we'd
need a policy and design around supporting mix-and-match on features,
which I don't think we really have today. Today, most features don't
mix and match well, one example of this being entity-manager requiring
intel-ipmi-oem.  Thus far for that simple example, nobody has stepped
up to make it a generic yocto feature and separate out the code,
despite pretty widespread adoption.  I think the idea that we're
suddenly going to just start doing a better job of feature separation
because of a single patch is a little naive, and I'd really like to
see the project make steps forward toward that before we create a
minimal image.

If we want to do this going forward, my personal opinion is that:
1. Someone needs to go figure out an example for one non-trival, cross
application feature with multiple options, and get yocto sorted such
that said "feature" enables the right component options.  Entity
manager might be a good one, phosphor-webui vs webui-vue might be
another good one (I'm looking into this currently), or individual
Redfish resources in bmcweb might be another.  There are a bunch of
examples of this you could start with.
2. Document a policy around what it means to be a "feature" including
some relevant examples.  Is Redfish a feature?  Is IPMI a feature?  or
are those just interfaces to access other features?  Do we need a
hierarchy of features?  When/where should we use DBus to determine
feature enablement, and when should it be a compile option?  We've
been very inconsistent about these questions in the past, and it's
part of the reason that adding "features" properly is hard.
3. Someone needs to go through the user-facing clients (phosphor-ipmi,
bmcweb, ect) as well as the recipes, and make sure command handlers
are organized in such a way that they're enabled or disabled by
feature, and we can successfully enable one feature at a time.  This
will likely expose some interesting dependencies (like how IPMI
commands have to be enabled/disabled by library) that we'll likely
need to tackle.

If the above tasks just fall onto the subsystem maintainers, who now
have to field the "I enabled X on my minimal build and it doesn't
work" type bugs, that seems like a non-starter, and likely to cause
more confusion than the current status quo.  If someone or group of
someones is willing to go do the work, I think it'd be a great benefit
to the project, and something that would help a lot of people.  I'm
happy to pitch in as well where I'm able.