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