interest in a minimal image recipe

[Khetan, Sharad]

Ed, welcome back 😊.

-----Original Message-----
From: openbmc <openbmc-bounces+sharad.khetan=intel.com at lists.ozlabs.org> On Behalf Of Ed Tanous
Sent: Thursday, September 17, 2020 1:57 PM
To: Brad Bishop <bradleyb at fuzziesquirrel.com>
Cc: OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: interest in a minimal image recipe

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.

[Sharad] 
All the issues (and considerations to resolve), you bring up are great. It will need policies, definitions, and categorizations as you point out. I think it will take quite some time to get there and its unlikely that we will achieve perfection. So we may have to start with basic, add a bunch of things to make it a minimum BMC (I think the first step will be agree what those minimum feature set is), and then be able to add from there. It may not be very granular (as there will be interdependencies), but even if we have a few such configurations/combination of feature it will be useful for someone to start with. I realize this doesn’t solve the problem fully, but I think it's much less effort and hence easier to start with.