interest in a minimal image recipe

interest in a minimal image recipe

[Brad Bishop]

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

RE: interest in a minimal image recipe

[Khetan, Sharad]

Hi Brad,

+1

I like the idea. We have a increasing number of repos and it will be good to have a model where users can pick the features/repos they want. I guess it will make OpenBMC offer a microservices model 😊. The challenge will of course be finding that right base / minimum configuration. That may change depending on device, usage, architecture.
It’s a good idea to start with the empty list and add from there.

Thanks,
-Sharad


-----Original Message-----
From: openbmc <openbmc-bounces+sharad.khetan=intel.com@lists.ozlabs.org> On Behalf Of Brad Bishop
Sent: Tuesday, September 15, 2020 1:29 PM
To: openbmc@lists.ozlabs.org
Subject: interest in a minimal image recipe

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

Re: interest in a minimal image recipe

[Sriram Ramkrishna]

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

On Tue, Sep 15, 2020 at 1:59 PM Khetan, Sharad <sharad.khetan@intel.com>
wrote:

> Hi Brad,
>
> +1
>
> I like the idea. We have a increasing number of repos and it will be good
> to have a model where users can pick the features/repos they want. I guess
> it will make OpenBMC offer a microservices model 😊. The challenge will of
> course be finding that right base / minimum configuration. That may change
> depending on device, usage, architecture.
> It’s a good idea to start with the empty list and add from there.
>
>
Actually great for debugging as well.

sri

Thanks,
> -Sharad
>
>
> -----Original Message-----
> From: openbmc <openbmc-bounces+sharad.khetan=intel.com@lists.ozlabs.org>
> On Behalf Of Brad Bishop
> Sent: Tuesday, September 15, 2020 1:29 PM
> To: openbmc@lists.ozlabs.org
> Subject: interest in a minimal image recipe
>
> 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
>

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

Re: interest in a minimal image recipe

[Brad Bishop]

On Tue, Sep 15, 2020 at 04:28:32PM -0400, Brad Bishop wrote:
>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 anyone is curious how I envisioned this would be used I am intending 
to use it on witherspoon (we are out of space):

https://gerrit.openbmc-project.xyz/36588

Re: interest in a minimal image recipe

[Ed Tanous]

On Thu, Sep 17, 2020 at 1:12 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> On Tue, Sep 15, 2020 at 04:28:32PM -0400, Brad Bishop wrote:
> >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 anyone is curious how I envisioned this would be used I am intending
> to use it on witherspoon (we are out of space):
>
> https://gerrit.openbmc-project.xyz/36588

Out of curiosity, has anyone run a space analysis on a recent
witherspoon image?  It would be interesting to know where the space is
going, so we can start hammering those subsystems back into shape.

This is the script I used a while back to come up with relative,
compressed sizes for all the components in the rootfs.
https://github.com/openbmc/openbmc-tools/blob/master/edtanous/rootfs_size.py

Re: interest in a minimal image recipe

[Andrew Geissler]

> On Sep 17, 2020, at 4:02 PM, Ed Tanous <ed@tanous.net> wrote:
> 
> On Thu, Sep 17, 2020 at 1:12 PM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>> 
>> On Tue, Sep 15, 2020 at 04:28:32PM -0400, Brad Bishop wrote:
>>> 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 anyone is curious how I envisioned this would be used I am intending
>> to use it on witherspoon (we are out of space):
>> 
>> https://gerrit.openbmc-project.xyz/36588
> 
> Out of curiosity, has anyone run a space analysis on a recent
> witherspoon image?  It would be interesting to know where the space is
> going, so we can start hammering those subsystems back into shape.
> 
> This is the script I used a while back to come up with relative,
> compressed sizes for all the components in the rootfs.
> https://github.com/openbmc/openbmc-tools/blob/master/edtanous/rootfs_size.py

I added it to our daily build job.

https://jenkins.openbmc.org/job/latest-master/label=docker-builder,target=witherspoon/lastSuccessfulBuild/artifact/openbmc/build/tmp/deploy/images/results.txt

Re: interest in a minimal image recipe

[Ed Tanous]

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.

RE: interest in a minimal image recipe

[Khetan, Sharad]

Ed, welcome back 😊.

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

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

Re: interest in a minimal image recipe

[Ed Tanous]

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

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?

Re: interest in a minimal image recipe

[Ed Tanous]

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

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?

RE: interest in a minimal image recipe

[Khetan, Sharad]

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

 

RE: interest in a minimal image recipe

[Khetan, Sharad]

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

 

Re: interest in a minimal image recipe

[Nancy Yuen]

[-- 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 --]

Re: interest in a minimal image recipe

[Brad Bishop]

On Thu, Sep 17, 2020 at 01:56:34PM -0700, Ed Tanous wrote:

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

What is this an obstacle to?  Adding content (image features) to my 
proposed image recipe or even having the recipe at all?  If the latter, 
it isn't obvious to me how having that could impact anyone?

Also, can you give an example policy around mix-and-match?

>Today, most features don't mix and match well, one example of this 
>being entity-manager requiring intel-ipmi-oem.  

In what way does EM require intel-ipmi-oem?  I am using EM without 
intel-ipmi-oem without (I thought anyway) issue.

>Thus far for that simple example, nobody has stepped up to make it a 
>generic yocto feature

Can you be more specific?  There is no such thing as a yocto feature - 
there are image features, machine features, distro features, kernel 
features...

>and separate out the code, despite pretty widespread adoption.

Can you elaborate on what source code should be reorganized?  I probably 
won't understand this until I understand how EM depends on 
intel-ipmi-oem?

>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

Agreed...I don't remember saying my patch would help with feature 
separation 🙂

>and I'd really like to see the project make steps forward toward that 
>before we create a minimal image.

So I have the same question as above.  Do you want to see things happen 
before the recipe is even created or before IMAGE_FEATUREs are added to 
it?  If the former can you explain why?  In my mind it is something that 
helps people right now, and doesn't impact anyone that doesn't use it.

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

What are component options?  configure flags/meson options?  In yocto 
these correlate to machine or disto features.  machine and distro 
features aren't really relevant in the context of an image recipe are 
they?

>Entity >manager might be a good one,

I tried to propose an EM distro feature already:

https://gerrit.openbmc-project.xyz/35764

James/Patrick decided it made more sense for pid control to check at 
runtime for a running EM instance.  That made sense to me.  So we don't 
need an EM distro feature until someone adds conditional compilation for 
EM support in another application.

>phosphor-webui vs webui-vue might be another good one (I'm looking into 
>this currently),

If the world made any sense, there would just be an image feature for 
both, much like how of how upstream has an image feature for dropbear 
and an image feature for openssh.  I'm still trying to figure out how we 
got ourselves into a position where building the webserver needs to be 
aware of what javascript application is running on it...my point 
is...there are less strange examples to be building out our best 
practices w.r.t distro features on.

>or individual Redfish resources in bmcweb might be another.  

Let's stick with PACKAGECONFIGs here until patterns emerge?

>There are a bunch of examples of this you could start with.

>2. Document a policy around what it means to be a "feature" 

There is pretty good documentation in Yocto covering the different types 
of features (image/distro/machine) at a conceptual level.  What more is 
there to add in the OpenBMC documentation?  Maybe just a list of the 
current openbmc image/distro/machine features?

>including some relevant examples.  Is Redfish a feature?  Is IPMI a 
>feature?

For sure, but maybe the question we should ask is are they image 
features or distro features?  The way they are implemented today they 
are image features.  To opt out of Redfish, you don't install the bmcweb 
package.  To opt out of IPMI, you don't install the 4 or so IPMI related 
packages (host-ipmid, ipmi-kcs, ipmi-bt, ipmi-ipmb, ipmi-net...)

>or are those just interfaces to access other features?

They could be, if someone needs that level of granularity.  Does someone 
want to do this?

>Do we need a hierarchy of features?

I hope not?

>When/where should we use DBus to determine feature enablement, and when 
>should it be a compile option?  

I like this question.  My strawman answer would be always use Dbus.
That simplifies the configuration required.  But it need not be mutually 
exclusive.  If someone needs something completely compiled out for some 
reason, that can be supported too.

>We've been very inconsistent about these questions in the past, and 
>it's part of the reason that adding "features" properly is hard.

I don't really think image features need to be all that hard.  they just 
control what packages get installed in the rootfs.  It might help this 
discusssion if you refrain from using "features" unqualified without
image/distro/machine because those all have clear meaning in Yocto.

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

Ok but those are autotools/cmake/meson options which correlate to a 
distro feature or maybe a packageconfig.  Those are orthogonal to image 
features and image recipes, which is what I've proposed.  I've not 
proposed a minimal distro policy.

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

I think maybe image features and distro features are being conflated 
some.  I don't see how this can happen with a minimal set of image 
features.  If something doesn't work its because a package dependency is 
missing (RDEPENDS) and that is a simple bug that should be fixed.

I _do_ see how this can happen with a minimal set of distro features, 
but that isn't what I've proposed.

Lots of great questions here Ed, thanks.  I wonder if several different 
threads need to be spun off?

-brad

Re: interest in a minimal image recipe

[Ed Tanous]

On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>
> On Thu, Sep 17, 2020 at 01:56:34PM -0700, Ed Tanous wrote:
>
> >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,
>
> What is this an obstacle to?  Adding content (image features) to my
> proposed image recipe or even having the recipe at all?  If the latter,
> it isn't obvious to me how having that could impact anyone?

Setting the expectation that features are selectable by creating a
minimal build, then having feature not be selectable is ripe for
confusion.  In practice, we already have this problem without the
minimal image, but thusfar can cover ourselves with some logic of the
sort "you're not using the default build, it's going to be difficult"

>
> Also, can you give an example policy around mix-and-match?

Something like: "Any new non-trivial, user facing feature should be
selectable independently at compile time through an OpenBMC distro
feature.  Said image feature should enable or disable redfish, webui,
and IPMI command handlers for said feature.  Effort should be taken to
avoid adding binary size for features that are disabled."

>
> >Today, most features don't mix and match well, one example of this
> >being entity-manager requiring intel-ipmi-oem.
>
> In what way does EM require intel-ipmi-oem?  I am using EM without
> intel-ipmi-oem without (I thought anyway) issue.

You're running Entity Manager, without intel-ipmi-oem, and you can run
a successful "ipmitool sensor list" or "ipmitool fru print" command,
and have it return the entity manager/dbus-sensors/FruDevice results?
In my understanding, this shouldn't work, and we've had many reports
of "I enabled entity manager, and my sensors don't show up in IPMI".

>
> >Thus far for that simple example, nobody has stepped up to make it a
> >generic yocto feature
>
> Can you be more specific?  There is no such thing as a yocto feature -
> there are image features, machine features, distro features, kernel
> features...

I think it depends on the specific feature, but I think a lot of them
would end up being distro or image features.

>
> >and separate out the code, despite pretty widespread adoption.
>
> Can you elaborate on what source code should be reorganized?  I probably
> won't understand this until I understand how EM depends on
> intel-ipmi-oem?

https://github.com/openbmc/intel-ipmi-oem/blob/master/src/sensorcommands.cpp
That whole file would likely need to move to another repo/library to
make it selectable independently from the rest of the command handlers
in intel-ipmi-oem.  Separating it out has been discussed a few times.

>
> >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
>
> Agreed...I don't remember saying my patch would help with feature
> separation

Is this something you think the project should do after the image is available?

>
> >and I'd really like to see the project make steps forward toward that
> >before we create a minimal image.
>
> So I have the same question as above.  Do you want to see things happen
> before the recipe is even created or before IMAGE_FEATUREs are added to
> it?  If the former can you explain why?  In my mind it is something that
> helps people right now, and doesn't impact anyone that doesn't use it.

I had imagined an influx of the "I enabled X on the minimal image, and
Y doesn't work" type bugs.  As is, we get them a lot more than I'd
like to see, but I guess we could just have the policy that if you're
using the minimal image, you're using a "power" feature, and there's
an expectation that there's dragons?

With that said, on second look the two problems aren't quite as tied
as I thought they were.  I retract the statement that we should do it
before the minimal image, but I'd still like to see the project get
better in that regard.

>
> >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.
>
> What are component options?  configure flags/meson options?

In general, yes, they tend to be autotools/cmake/meson flags to
enable/disable features.  In the case of IPMI, it might be just
modified RDEPENDS statements.

>  In yocto
> these correlate to machine or disto features.  machine and distro
> features aren't really relevant in the context of an image recipe are
> they?

I think they become more important, because if you're starting with a
minimal image, I'd expect that there be an easy way to add independent
features without pulling in a bunch of features I didn't explicitly
enable.

>
> >Entity >manager might be a good one,
>
> I tried to propose an EM distro feature already:
>
> https://gerrit.openbmc-project.xyz/35764

I had not seen that discussion before.  Interesting.

>
> James/Patrick decided it made more sense for pid control to check at
> runtime for a running EM instance.  That made sense to me.  So we don't
> need an EM distro feature until someone adds conditional compilation for
> EM support in another application.

I was speaking to a slightly bigger issue.  Now that you have an
Entity-Manager feature, do your IPMI command handlers work?  Or are
they still using the old phosphor-inventory type commands.  It's this
kind of cross linking I'd like to see us get better at.  See above, I
suspect this is something we can work toward, and probably shouldn't
block your minimal image patch.

>
> >phosphor-webui vs webui-vue might be another good one (I'm looking into
> >this currently),
>
> If the world made any sense, there would just be an image feature for
> both, much like how of how upstream has an image feature for dropbear
> and an image feature for openssh.

Totally agree.

>  I'm still trying to figure out how we
> got ourselves into a position where building the webserver needs to be
> aware of what javascript application is running on it...my point
> is...there are less strange examples to be building out our best
> practices w.r.t distro features on.

Because webui-vue didn't develop all the login/authorization logic
that phosphor-webui had, and in the meantime, added new features to
pre-auth, so now as we try to tighten security, it's breaking.  It's a
great example of something that has cross recipe dependencies that are
mutually exclusive.

I intentionally picked these examples because they're strange.  I
think the straightforward ones (remove an old recipe, and add a new)
we tend to know how to solve as a project.

>
> >or individual Redfish resources in bmcweb might be another.
>
> Let's stick with PACKAGECONFIGs here until patterns emerge?

Sure.

>
> >There are a bunch of examples of this you could start with.
>
> >2. Document a policy around what it means to be a "feature"
>
> There is pretty good documentation in Yocto covering the different types
> of features (image/distro/machine) at a conceptual level.  What more is
> there to add in the OpenBMC documentation?  Maybe just a list of the
> current openbmc image/distro/machine features?
>
> >including some relevant examples.  Is Redfish a feature?  Is IPMI a
> >feature?
>
> For sure, but maybe the question we should ask is are they image
> features or distro features?  The way they are implemented today they
> are image features.  To opt out of Redfish, you don't install the bmcweb
> package.

But then you'd disable the and webui, dbus-rest, and the KVM as well.
Technically to opt out of just Redfish, but not the webui or
dbus-rest, you can add a "BMCWEB_ENABLE_REDFISH=OFF" to a bbappend.
But that's not very obvious.

>  To opt out of IPMI, you don't install the 4 or so IPMI related
> packages (host-ipmid, ipmi-kcs, ipmi-bt, ipmi-ipmb, ipmi-net...)

Right, the case of "I want to remove the protocol entirely" is pretty
easy, and falls cleanly on recipe bounds.  What if I want to opt out
of the IPMI FRU implementation, and use the intel-ipmi-oem one?

>
> >or are those just interfaces to access other features?
>
> They could be, if someone needs that level of granularity.  Does someone
> want to do this?

In the case of Entity-manager, I've seen the request many times.  I
don't know of a lot of other common examples, but I suspect they'll
pop up.

>
> >Do we need a hierarchy of features?
>
> I hope not?
>
> >When/where should we use DBus to determine feature enablement, and when
> >should it be a compile option?
>
> I like this question.  My strawman answer would be always use Dbus.
> That simplifies the configuration required.  But it need not be mutually
> exclusive.  If someone needs something completely compiled out for some
> reason, that can be supported too.

Sounds reasonable.

>
> >We've been very inconsistent about these questions in the past, and
> >it's part of the reason that adding "features" properly is hard.
>
> I don't really think image features need to be all that hard.  they just
> control what packages get installed in the rootfs.  It might help this
> discusssion if you refrain from using "features" unqualified without
> image/distro/machine because those all have clear meaning in Yocto.

That's part of it.  As a project, when do we use an image feature?
When do we use a distro feature?  When do we use a machine feature?
I will fully admit that I'm not as well versed on the yocto features
as I should be, but I suspect a lot of my project is in my same
position, and would love some clear examples of when and how to use
each, with relevant examples.

>
> >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.
>
> Ok but those are autotools/cmake/meson options which correlate to a
> distro feature or maybe a packageconfig.  Those are orthogonal to image
> features and image recipes, which is what I've proposed.  I've not
> proposed a minimal distro policy.

Maybe this has all been a wash then.  I had thought you were proposing
a minimal distro, and didn't realize you were building a minimal image
with the existing distro.  My bad.

With that said, the images description is "Basic OpenBMC image with
full support for the hardware supported by the system".  Was it
intentional to call out "full support"?  Maybe I've misinterpreted the
long term intent of this patch?

>
> >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.
>
> I think maybe image features and distro features are being conflated
> some.  I don't see how this can happen with a minimal set of image
> features.  If something doesn't work its because a package dependency is
> missing (RDEPENDS) and that is a simple bug that should be fixed.
>
> I _do_ see how this can happen with a minimal set of distro features,
> but that isn't what I've proposed.
>
> Lots of great questions here Ed, thanks.  I wonder if several different
> threads need to be spun off?

We could certainly.

To be clear, I'm in support of the above overall, and thinking about
it, I'm in support of getting it in, just because it'll force the
feature selection issue some more, which will hopefully lead to a
bunch of the above being fixed in short order.

>
> -brad

Re: interest in a minimal image recipe

[Brad Bishop]

On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
>On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>>
>> In what way does EM require intel-ipmi-oem?  I am using EM without
>> intel-ipmi-oem without (I thought anyway) issue.
>
>You're running Entity Manager, without intel-ipmi-oem, and you can run
>a successful "ipmitool sensor list" or "ipmitool fru print" command,
>and have it return the entity manager/dbus-sensors/FruDevice results?

Ah, now I understand.  No, I can't do that.  But I don't need to because 
the default IPMI handler implementations in phosphor-host-ipmid work for 
me (the YAML based ones), and those don't need entity-manager.  I'm 
using entity-manager for other reasons.

As an aside - I think a majority are using the intel-ipmi-oem handlers 
now so I'd support moving those into phosphor-host-ipmid and using them 
as the defaults.  But that must not be easy, otherwise Intel would have 
just done that rather than forking the handlers in intel-ipmi-oem in the 
first place.

But in any case, intel-ipmi-oem requires entity-manager, not the other 
way around right?  The "feature" being selected here is the Intel IPMI 
handler forks, and that would simply depend on entity-manager.  A 
strawman:

obmc-phosphor-image.bbclass:
FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"

packagegroup-obmc-apps.bb:
RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"

intel-ipmi-oem.bb:
RDEPENDS_${PN} = "entity-manager"

One prerequisite to this is that the intel-ipmi-oem recipe would need to 
move to meta-phosphor.  Perhaps its time for the repo to be renamed into 
something else.

>In my understanding, this shouldn't work, and we've had many reports
>of "I enabled entity manager, and my sensors don't show up in IPMI".
I don't think the answer to "how do I enable IPMI sensors" was ever 
"enable entity manager" was it?  To enable IPMI, you have always needed 
to enable either the original YAML based handlers or the intel-ipmi-oem 
forks.

Re: interest in a minimal image recipe

[Ed Tanous]

On Mon, Sep 21, 2020 at 10:52 AM Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
> On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
> >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> >>
> >> In what way does EM require intel-ipmi-oem?  I am using EM without
> >> intel-ipmi-oem without (I thought anyway) issue.
> >
> >You're running Entity Manager, without intel-ipmi-oem, and you can run
> >a successful "ipmitool sensor list" or "ipmitool fru print" command,
> >and have it return the entity manager/dbus-sensors/FruDevice results?
>
> Ah, now I understand.  No, I can't do that.  But I don't need to because
> the default IPMI handler implementations in phosphor-host-ipmid work for
> me (the YAML based ones), and those don't need entity-manager.  I'm
> using entity-manager for other reasons.

That makes a lot more sense now.

>
> As an aside - I think a majority are using the intel-ipmi-oem handlers
> now so I'd support moving those into phosphor-host-ipmid and using them
> as the defaults.  But that must not be easy, otherwise Intel would have
> just done that rather than forking the handlers in intel-ipmi-oem in the
> first place.

Yep, although I think it's a solvable problem to make it an
image/distro feature.

>
> But in any case, intel-ipmi-oem requires entity-manager, not the other
> way around right?

Good point.  I never thought of it that way, but you're right.

>  The "feature" being selected here is the Intel IPMI
> handler forks, and that would simply depend on entity-manager.  A
> strawman:
>
> obmc-phosphor-image.bbclass:
> FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"
>
> packagegroup-obmc-apps.bb:
> RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"
>
> intel-ipmi-oem.bb:
> RDEPENDS_${PN} = "entity-manager"
>
> One prerequisite to this is that the intel-ipmi-oem recipe would need to
> move to meta-phosphor.  Perhaps its time for the repo to be renamed into
> something else.

Yep. That looks like what I would expect.

>
> >In my understanding, this shouldn't work, and we've had many reports
> >of "I enabled entity manager, and my sensors don't show up in IPMI".
> I don't think the answer to "how do I enable IPMI sensors" was ever
> "enable entity manager" was it?  To enable IPMI, you have always needed
> to enable either the original YAML based handlers or the intel-ipmi-oem
> forks.

That's a really good point.  We really ought to model features as
outbound interfaces that drive internal RDEPENDS.  Ideally nobody
would be appending entity-manager, they would be appending
intel-ipmi-oem (or whatever name we pick for it in the future), which
would have the correct dependencies on entity-manager.   I like it.

Re: interest in a minimal image recipe

[Brad Bishop]

On Mon, Sep 21, 2020 at 11:25:34AM -0700, Ed Tanous wrote:

>That's a really good point.  We really ought to model features as
>outbound interfaces that drive internal RDEPENDS.  Ideally nobody
>would be appending entity-manager, they would be appending
>intel-ipmi-oem (or whatever name we pick for it in the future), which
>would have the correct dependencies on entity-manager.   I like it.

Right.  And I guess this highlights an issue with a different patch of 
mine: https://gerrit.openbmc-project.xyz/36510 - I had wanted to put EM 
in my images to do some prototyping with it but there are better ways to 
do that (via dependency or maybe local.conf).

Re: interest in a minimal image recipe

[Vijay Khemka]

On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of bradleyb@fuzziesquirrel.com> wrote:

    On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
    >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
    >>
    >> In what way does EM require intel-ipmi-oem?  I am using EM without
    >> intel-ipmi-oem without (I thought anyway) issue.
    >
    >You're running Entity Manager, without intel-ipmi-oem, and you can run
    >a successful "ipmitool sensor list" or "ipmitool fru print" command,
    >and have it return the entity manager/dbus-sensors/FruDevice results?

    Ah, now I understand.  No, I can't do that.  But I don't need to because 
    the default IPMI handler implementations in phosphor-host-ipmid work for 
    me (the YAML based ones), and those don't need entity-manager.  I'm 
    using entity-manager for other reasons.

    As an aside - I think a majority are using the intel-ipmi-oem handlers 
    now so I'd support moving those into phosphor-host-ipmid and using them 
    as the defaults.  But that must not be easy, otherwise Intel would have 
    just done that rather than forking the handlers in intel-ipmi-oem in the 
    first place.
I support moving many standard commands from intel-ipmi-oem to
phosphor-host-ipmid.  Entity manager is required only for fru and
sensor SDR ipmi command but there are many other commands
which are useful and can be moved.

    But in any case, intel-ipmi-oem requires entity-manager, not the other 
    way around right?  The "feature" being selected here is the Intel IPMI 
    handler forks, and that would simply depend on entity-manager.  A 
    strawman:

    obmc-phosphor-image.bbclass:
    FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"

    packagegroup-obmc-apps.bb:
    RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"

    intel-ipmi-oem.bb:
    RDEPENDS_${PN} = "entity-manager"

    One prerequisite to this is that the intel-ipmi-oem recipe would need to 
    move to meta-phosphor.  Perhaps its time for the repo to be renamed into 
    something else.
We may have to split and look for what we need from intel-ipmi-oem. There
are lots of intel oem specific command in this which are not useful for
many other platforms and are overridden by their own xx-ipmi-oem.

We should simply port standard ipmi command from intel-ipmi-oem to
Phosphor-host-ipmid.

    >In my understanding, this shouldn't work, and we've had many reports
    >of "I enabled entity manager, and my sensors don't show up in IPMI".
    I don't think the answer to "how do I enable IPMI sensors" was ever 
    "enable entity manager" was it?  To enable IPMI, you have always needed 
    to enable either the original YAML based handlers or the intel-ipmi-oem 
    forks.

We should fix this in host-ipmid, as all sensors are added to standard dbus
Interface and if it is not discoverable by mapper or object manager then we
should fix it so that an SDR can be built independent of sensor implementation.

Re: interest in a minimal image recipe

[Ed Tanous]

On Tue, Sep 22, 2020 at 1:40 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
>
>
>
> On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of bradleyb@fuzziesquirrel.com> wrote:
>
>     On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
>     >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>     >>
>     >> In what way does EM require intel-ipmi-oem?  I am using EM without
>     >> intel-ipmi-oem without (I thought anyway) issue.
>     >
>     >You're running Entity Manager, without intel-ipmi-oem, and you can run
>     >a successful "ipmitool sensor list" or "ipmitool fru print" command,
>     >and have it return the entity manager/dbus-sensors/FruDevice results?
>
>     Ah, now I understand.  No, I can't do that.  But I don't need to because
>     the default IPMI handler implementations in phosphor-host-ipmid work for
>     me (the YAML based ones), and those don't need entity-manager.  I'm
>     using entity-manager for other reasons.
>
>     As an aside - I think a majority are using the intel-ipmi-oem handlers
>     now so I'd support moving those into phosphor-host-ipmid and using them
>     as the defaults.  But that must not be easy, otherwise Intel would have
>     just done that rather than forking the handlers in intel-ipmi-oem in the
>     first place.
> I support moving many standard commands from intel-ipmi-oem to
> phosphor-host-ipmid.  Entity manager is required only for fru and
> sensor SDR ipmi command but there are many other commands
> which are useful and can be moved.
>
>     But in any case, intel-ipmi-oem requires entity-manager, not the other
>     way around right?  The "feature" being selected here is the Intel IPMI
>     handler forks, and that would simply depend on entity-manager.  A
>     strawman:
>
>     obmc-phosphor-image.bbclass:
>     FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"
>
>     packagegroup-obmc-apps.bb:
>     RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"
>
>     intel-ipmi-oem.bb:
>     RDEPENDS_${PN} = "entity-manager"
>
>     One prerequisite to this is that the intel-ipmi-oem recipe would need to
>     move to meta-phosphor.  Perhaps its time for the repo to be renamed into
>     something else.
> We may have to split and look for what we need from intel-ipmi-oem. There
> are lots of intel oem specific command in this which are not useful for
> many other platforms and are overridden by their own xx-ipmi-oem.
>
> We should simply port standard ipmi command from intel-ipmi-oem to
> Phosphor-host-ipmid.

+1

>
>     >In my understanding, this shouldn't work, and we've had many reports
>     >of "I enabled entity manager, and my sensors don't show up in IPMI".
>     I don't think the answer to "how do I enable IPMI sensors" was ever
>     "enable entity manager" was it?  To enable IPMI, you have always needed
>     to enable either the original YAML based handlers or the intel-ipmi-oem
>     forks.
>
> We should fix this in host-ipmid, as all sensors are added to standard dbus
> Interface and if it is not discoverable by mapper or object manager then we
> should fix it so that an SDR can be built independent of sensor implementation.
>

I agree with all the above.  Do you think you could get the patches
pushed to start this discussion in gerrit?

Re: interest in a minimal image recipe

[Vijay Khemka]

On 9/23/20, 12:46 PM, "Ed Tanous" <ed@tanous.net> wrote:

    On Tue, Sep 22, 2020 at 1:40 PM Vijay Khemka <vijaykhemka@fb.com> wrote:
    >
    >
    >
    > On 9/21/20, 10:57 AM, "openbmc on behalf of Brad Bishop" <openbmc-bounces+vijaykhemka=fb.com@lists.ozlabs.org on behalf of bradleyb@fuzziesquirrel.com> wrote:
    >
    >     On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
    >     >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
    >     >>
    >     >> In what way does EM require intel-ipmi-oem?  I am using EM without
    >     >> intel-ipmi-oem without (I thought anyway) issue.
    >     >
    >     >You're running Entity Manager, without intel-ipmi-oem, and you can run
    >     >a successful "ipmitool sensor list" or "ipmitool fru print" command,
    >     >and have it return the entity manager/dbus-sensors/FruDevice results?
    >
    >     Ah, now I understand.  No, I can't do that.  But I don't need to because
    >     the default IPMI handler implementations in phosphor-host-ipmid work for
    >     me (the YAML based ones), and those don't need entity-manager.  I'm
    >     using entity-manager for other reasons.
    >
    >     As an aside - I think a majority are using the intel-ipmi-oem handlers
    >     now so I'd support moving those into phosphor-host-ipmid and using them
    >     as the defaults.  But that must not be easy, otherwise Intel would have
    >     just done that rather than forking the handlers in intel-ipmi-oem in the
    >     first place.
    > I support moving many standard commands from intel-ipmi-oem to
    > phosphor-host-ipmid.  Entity manager is required only for fru and
    > sensor SDR ipmi command but there are many other commands
    > which are useful and can be moved.
    >
    >     But in any case, intel-ipmi-oem requires entity-manager, not the other
    >     way around right?  The "feature" being selected here is the Intel IPMI
    >     handler forks, and that would simply depend on entity-manager.  A
    >     strawman:
    >
    >     obmc-phosphor-image.bbclass:
    >     FEATURE_PACKAGES_intel-ipmi-handler-forks = "packagegroup-intel-ipmi-handler-forks"
    >
    >     packagegroup-obmc-apps.bb:
    >     RDEPENDS_packagegroup-obmc-apps-intel-ipmi-handler-forks = "intel-ipmi-oem"
    >
    >     intel-ipmi-oem.bb:
    >     RDEPENDS_${PN} = "entity-manager"
    >
    >     One prerequisite to this is that the intel-ipmi-oem recipe would need to
    >     move to meta-phosphor.  Perhaps its time for the repo to be renamed into
    >     something else.
    > We may have to split and look for what we need from intel-ipmi-oem. There
    > are lots of intel oem specific command in this which are not useful for
    > many other platforms and are overridden by their own xx-ipmi-oem.
    >
    > We should simply port standard ipmi command from intel-ipmi-oem to
    > Phosphor-host-ipmid.

    +1

    >
    >     >In my understanding, this shouldn't work, and we've had many reports
    >     >of "I enabled entity manager, and my sensors don't show up in IPMI".
    >     I don't think the answer to "how do I enable IPMI sensors" was ever
    >     "enable entity manager" was it?  To enable IPMI, you have always needed
    >     to enable either the original YAML based handlers or the intel-ipmi-oem
    >     forks.
    >
    > We should fix this in host-ipmid, as all sensors are added to standard dbus
    > Interface and if it is not discoverable by mapper or object manager then we
    > should fix it so that an SDR can be built independent of sensor implementation.
    >

    I agree with all the above.  Do you think you could get the patches
    pushed to start this discussion in gerrit?

Yes sure. once I finish my current tasks, I will schedule this.

Re: interest in a minimal image recipe

[Brad Bishop]

On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
>On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
>>
>> Ok but those are autotools/cmake/meson options which correlate to a
>> distro feature or maybe a packageconfig.  Those are orthogonal to image
>> features and image recipes, which is what I've proposed.  I've not
>> proposed a minimal distro policy.
>
>Maybe this has all been a wash then.  I had thought you were proposing
>a minimal distro, and didn't realize you were building a minimal image
>with the existing distro.  My bad.

No worries.  To have a minimal distro, we first need a set of default 
distro features from which to subtract some to have a minimal set.  We 
don't really have any real distro features defined yet - the ones we do 
are non-sensical IMO - they are artifacts of my lack of bitbake-fu from 
5 years ago.  I would like to hear about areas where you think it might 
make sense to define distro features.

>With that said, the images description is "Basic OpenBMC image with
>full support for the hardware supported by the system".  Was it
>intentional to call out "full support"?  Maybe I've misinterpreted the
>long term intent of this patch?

I can see how my summary would cause confusion.  FWIW I used the summary 
in core-image-base as a template.  Is there a better summary?

Maybe this helps - I was trying to replicate oe-core:

  core-image-sato -> obmc-phosphor-image (all/most of the image features 
                                          are enabled by default)
  core-image-base -> obmc-phosphor-image-base (a minimal set of packages)

What is the minimal set of packages?  I don't think we know yet.  I 
expect many to bbappend obmc-phosphor-image-base, and select specific 
image features (IMAGE_FEATURES) or directly install packages 
(IMAGE_INSTALL).  After enough time has passed, we can use those as an 
input for identifying what makes sense to use in the base image recipe 
as the default.

Re: interest in a minimal image recipe

[Ed Tanous]

On Mon, Sep 21, 2020 at 11:20 AM Brad Bishop
<bradleyb@fuzziesquirrel.com> wrote:
>
> On Mon, Sep 21, 2020 at 08:53:26AM -0700, Ed Tanous wrote:
> >On Mon, Sep 21, 2020 at 5:55 AM Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> >>
> >> Ok but those are autotools/cmake/meson options which correlate to a
> >> distro feature or maybe a packageconfig.  Those are orthogonal to image
> >> features and image recipes, which is what I've proposed.  I've not
> >> proposed a minimal distro policy.
> >
> >Maybe this has all been a wash then.  I had thought you were proposing
> >a minimal distro, and didn't realize you were building a minimal image
> >with the existing distro.  My bad.
>
> No worries.  To have a minimal distro, we first need a set of default
> distro features from which to subtract some to have a minimal set.  We
> don't really have any real distro features defined yet - the ones we do
> are non-sensical IMO - they are artifacts of my lack of bitbake-fu from
> 5 years ago.  I would like to hear about areas where you think it might
> make sense to define distro features.

To be clear, I'm not blaming you here.  I think we're all learning our
way through yoctos eccentricities :)

>
> >With that said, the images description is "Basic OpenBMC image with
> >full support for the hardware supported by the system".  Was it
> >intentional to call out "full support"?  Maybe I've misinterpreted the
> >long term intent of this patch?
>
> I can see how my summary would cause confusion.  FWIW I used the summary
> in core-image-base as a template.  Is there a better summary?

Something like: "A basic OpenBMC image with no features enabled".

>
> Maybe this helps - I was trying to replicate oe-core:
>
>   core-image-sato -> obmc-phosphor-image (all/most of the image features
>                                           are enabled by default)
>   core-image-base -> obmc-phosphor-image-base (a minimal set of packages)

Ahhhh, that makes a lot more sense if that was your model.  For some
reason I thought you were trying to build the equivalent of
core-image-minimal, whose description is:
"This is the most basic image allowing a device to boot to a Linux
command-line login".  I got mixed up in my yocto terminology.

>
> What is the minimal set of packages?  I don't think we know yet.  I
> expect many to bbappend obmc-phosphor-image-base, and select specific
> image features (IMAGE_FEATURES) or directly install packages
> (IMAGE_INSTALL).  After enough time has passed, we can use those as an
> input for identifying what makes sense to use in the base image recipe
> as the default.

So your thinking is that this would eventually become the new
"defaults" image?  Possibly the "well supported" image?  I can get
behind that.

Re: interest in a minimal image recipe

[Brad Bishop]

On Mon, Sep 21, 2020 at 11:49:36AM -0700, Ed Tanous wrote:
>On Mon, Sep 21, 2020 at 11:20 AM Brad Bishop
><bradleyb@fuzziesquirrel.com> wrote:

>> I can see how my summary would cause confusion.  FWIW I used the summary
>> in core-image-base as a template.  Is there a better summary?

>Something like: "A basic OpenBMC image with no features enabled".

Nice!  thx.  I'll update the patch.

>So your thinking is that this would eventually become the new
>"defaults" image?  Possibly the "well supported" image?  I can get
>behind that.

Yes, exactly.

Re: interest in a minimal image recipe

[Vijay Khemka]

I really like this idea of having minimum feature image, we have to make
sure whatever minimal image it builds it should boot to linux login 
prompt.

In my opinion, we should go with minimal image patch which will have
uboot, kernel and basic minimum distro feature (which are must). Then
we can define other features in hierarchy with multiple available
options including dependencies. We should also add a documentation providing
details about each features and its dependencies. Every features should
have compile time dependency flag which needs to be defined if multiple
options available for dependencies or it should select its dependent
feature with only one options available. This way we can rule out of someone
complaining that I added this feature and it is not working.

All features selection has to be provided with brief documentation for
allowing users to choose required feature for their platform.

Re: interest in a minimal image recipe

[Brad Bishop]

On Tue, 2020-09-15 at 16:28 -0400, Brad Bishop wrote:
> 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.

Thanks for the feedback everyone.  It seems mostly positive so I went
ahead and merged this.

-brad