When building OpenBMC . . . ?

[Ed Tanous]

On Tue, Sep 1, 2020 at 9:20 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Tue, Sep 01, 2020 at 09:09:33AM -0700, Ed Tanous wrote:
> > On Tue, Sep 1, 2020 at 5:26 AM Patrick Williams <patrick at stwcx.xyz> wrote:
> > > On Sun, Aug 30, 2020 at 10:02:41PM +0000, Bruce Mitchell wrote:
> > >
> > > #2 should go into either meta-facebook (or the underlying code
> > > repository where the fix is needed).  These will be common for any
> >
> > +1
> >
> > Could we also make the statement that as a project, we will enable
> > every platform feature we are able to for every platform by default,
> > and if a company wants to specifically disable some features for their
> > use because they haven't vetted them, they should do that in a
> > specific distro?  Said another way, the "default" for every machine
> > should be every feature enabled, as that's what helps users and
> > developers the most.
>
> I think this is where we get some conflict between, for lack of better
> words, commercial and hyperscale philosphies.  We may make a decision
> that we don't want net-ipmi in our datacenter, for security reasons, so
> we have it disabled in our meta-facebook layer.  Yes, we could disable
> it dynamically like a customer of a commercial vendor might do, but it
> is simpler to not even have the code in the image.
>
> Today we've combined machine definition and image definition into a
> single meta-layer across the board.  This is probably reasonable for
> a single vendor who designs their own machine in-house

Single vendors have the same problem.  Customers of said vendor want a
build that "just works the way they want", and don't want to mess
around with changing configurations per-machine, uploading public
certificates, uploading webui customization, or having the possibility
that an insecure protocol accidentally gets enabled in prod.

>, but is less
> reasonable for cases like Facebook where we do our work within OCP and
> others can order the servers we've designed from various ODMs.

There are companies using hyperscaler platforms that have net-ipmi
enabled.  There are companies that have transition plans to replace
one protocol with another, and at some point, will "flip the switch"
moving from one protocol to another.  I think explicitly separating an
OpenBMC featureset (for lack of a better word) from an OpenBMC
supported machine will lead to a better result overall.  I also think
it has some nice scaling properties as hyperscalers ratchet up the
number of system types they support, they can have more reuse of
featuresets between machines.  Also, when debugging said machines,
it's really nice to have a folder (meta layer) of "what's different
between machines" that's separate from "what's different between our
build".  I've used that many....many times to do A-B compares to find
elusive bugs.

Anywho, I think we're mostly agreeing.


>
> --
> Patrick Williams