Re: interest in a minimal image recipe

[Nancy Yuen <yuenn@google.com>]

[-- Attachment #1: Type: text/plain, Size: 6951 bytes --]

We've also found something like a minimal image useful in the early stages
of bringing up OpenBMC on a new system.

On Mon, Sep 21, 2020 at 7:04 PM Khetan, Sharad <sharad.khetan@intel.com>
wrote:

>
>
> -----Original Message-----
> From: Ed Tanous <ed@tanous.net>
> Sent: Monday, September 21, 2020 8:06 AM
> To: Khetan, Sharad <sharad.khetan@intel.com>
> Cc: Brad Bishop <bradleyb@fuzziesquirrel.com>; OpenBMC Maillist <
> openbmc@lists.ozlabs.org>
> Subject: Re: interest in a minimal image recipe
>
> On Thu, Sep 17, 2020 at 3:22 PM Khetan, Sharad <sharad.khetan@intel.com>
> wrote:
> >
> > Ed, welcome back .
>
>
> Thanks!  Glad to be here.
>
> >
> >
> > -----Original Message-----
> > From: openbmc
> > <openbmc-bounces+sharad.khetan=intel.com@lists.ozlabs.org> On Behalf
> > Of Ed Tanous
> > Sent: Thursday, September 17, 2020 1:57 PM
> > To: Brad Bishop <bradleyb@fuzziesquirrel.com>
> > Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
> > Subject: Re: interest in a minimal image recipe
> >
> > On Tue, Sep 15, 2020 at 1:31 PM Brad Bishop <bradleyb@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).
>
>
>

-- 

Nancy Yuen

•

Google Platforms

•

yuenn@google.com

•

Google LLC

[-- Attachment #2: Type: text/html, Size: 11298 bytes --]