interest in a minimal image recipe

[Khetan, Sharad]

-----Original Message-----
From: Ed Tanous <ed at tanous.net> 
Sent: Monday, September 21, 2020 8:06 AM
To: Khetan, Sharad <sharad.khetan at intel.com>
Cc: Brad Bishop <bradleyb at fuzziesquirrel.com>; OpenBMC Maillist <openbmc at lists.ozlabs.org>
Subject: Re: interest in a minimal image recipe

On Thu, Sep 17, 2020 at 3:22 PM Khetan, Sharad <sharad.khetan at intel.com> wrote:
>
> Ed, welcome back .


Thanks!  Glad to be here.

>
>
> -----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.
>

>> 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.
>
>

>I like to think that's what I proposed, starting small, with 1 example of how to do it "right", then building on it.  I'm not looking for perfection, but I'm looking for commitment that we'll continue to push this forward in places where we haven't been that successful in the past.  If not, I think it has the potential to confuse what is already a complex and bifurcated build environment even further.

>One minor thing to clarify:  I had imagined Brads proposal of a "minimum" BMC would have essentially nothing added, and would just be a kernel that boots, with no interfaces, services, or handling.  Is that what you were thinking?  I had not imagined that we would never "add a bunch of things".  If so, maybe I misunderstood what Brad proposed?

It's already hashed out between Brad and you. Yes I was thinking about the "basic BMC with no features added" (actually Brad's idea) to start with. I also hope to get a minimum featured BMC (instead of no features) at some point of time will be useful. Defining such a configuration will involve some subjectivity, but will be useful for newcomers to get something useful without a lot of effort (and bulk).