Redfish OEM commands in OpenBMC

[Andrew Jeffery]

On Mon, 6 May 2019, at 18:21, Deepak Kodihalli wrote:
> On 01/05/19 11:35 PM, Brad Bishop wrote:
> > On Mon, Apr 29, 2019 at 10:32:36AM -0700, Ed Tanous wrote:
> > 
> >> On the nose, it sounds ok, but it would be good to see a proposal
> >> that's a little more detailed. 
> > I put a proposal here:
> > https://lists.ozlabs.org/pipermail/openbmc/2019-April/016126.html
> > 
> >>> Agreed on option #2.  However I still think you should consider
> >>> runtime pluggable dynamic resolution.
> >>
> >> None of the features I've heard so far necessitates the use of runtime
> >> discovery, or even fall outside what configurability is available in
> >> bmcweb today.  "runtime pluggable" on an embedded system is a strange
> >> concept, given that all uses I know of today are really just an
> >> extension of compile time plugability, using the rootfs as the medium
> >> for "discovery".  With that said, I'm imagining you're thinking
> >> something like what IPMI has today, which I might be misinterpreting
> >> based on our discussion this morning?
> > Yes, this is what I was thinking.  I agree with you that we don't have
> > features that require the use of runtime discovery.  My reasoning is
> > rooted in concerns around code maintanence and adoption.
> > 
> > maintanence:  I don't think code with a bunch of #ifdefs is desired or
> > readable.  It might not be too bad starting out.
> > 
> > adoption:  Do you recall how one of Michael Brown's issues with bmcweb
> > was that there wasn't "any way to extend or replace functions without
> > forking the codebase?"  I believe this is exactly what he was talking
> > about.  I suspect he didn't even consider compile time plugins because
> > in my experience maintaining codebases structured that way is painful.
> > 
> >> It should be noted, we also have DBus "plugin" capability with the dbus
> >> interface already: anyone can host logs on dbus, and redfish will
> >> populate them.  That option doesn't really get to the core of the OEM
> >> issue though, but is certainly an option in the PEL log case that I
> >> didn't think of right away.
> > This is an interesting thought.  We could put OEM things on DBus and
> > maybe bmcweb looks at those to fill out OEM properties?
> > 
> >>> It sounds like you want everyone to put their implementations of OEM
> >>> properties right next to each other in bmcweb and surround them with
> >>> ifdefs.  Do I have that right
> >> Yes, I believe you have that right.
> > 
> >>> Shouldn't we allow the OEM to maintain their own implementation?
> >>> Also, when you (the bmcweb maintainer) look at the core bmcweb/redfish
> >>> code, do you want to be distracted by the twenty implementations of an
> >>> OEM property?
> >>
> >> If my goal is to make my changes without breaking any of the other
> >> twenty implementations at the same time, absolutely, I want to be
> >> "distracted" by them. 
> > Right.  This is the fallout of choosing to not have a framework/have an
> > unstable API.  This is also what makes this approach not scale very well
> > from a maintanence POV, IMO.
> > 
> >>> Does it make sense for you to be the maintainer of code you have
> >>> zero investment in?
> >> We can definitely both agree that me personally maintaining all Redfish
> >> code is unmaintainable in the long term.  I don't want to be the
> >> maintainer of code that I have no investment in, but I'm not sure how
> >> you came to the "Ed is the only maintainer of bmcweb for all time"
> >> conclusion.  The current maintainer files have provisions for layering
> >> just like the Kernel does.  Long-term, we can split maintainership on
> >> whatever lines are appropriate.
> > Sounds good!
> > 
> >>> This is just the reality of the world we live in...  It is precisely
> >>> why we need robust (yes, sometimes complicated, sometimes performance
> >>> impacting, sometimes harder to read) frameworks and abstractions that
> >>> allow us to share and collaborate where it makes sense and to move
> >>> quickly where it does not.
> >> I would argue that the kernel driver interface is a great example of
> >> how this should be done, and handles scales that we could only hope to
> >> get to get to.  The kernel doesn't publish a "stable" driver interface
> >> internally, but does publish a concrete user-facing API. 
> > It may not be a stable interface but there _is_ an interface to which
> > out of tree modules for instance can plug into.  And those modules could
> > implement a custom, OEM ABI via sysfs or ioctls.
> > 
> >> somewhat what bmcweb has attempted to model in its design;  User facing
> >> code should be able to be concrete, while keeping the internals
> >> flexible enough to make changes as better patterns emerge.
> > 
> > This thread raises an important design point or "community norm" being
> > established for OpenBMC.  IMO it has the potential to impact
> > participation rates and cost of maintanence in the future.  It would be
> > nice to get some opinions from more than just two people.  Anyone care
> > to chime in?
> 
> We have a similar problem to solve with PLDM OEM commands. I was 
> initially considering dynamically loaded libraries implementing OEM, but 
> I am interested to know the pitfalls of the same from Vernon or others, 
> as opposed to compile-time plugging-in of these libraries (not sure if 
> this was already discussed in the last community call, which I couldn't 
> attend).
> 
> Do we want to disallow someone who uses OpenBMC from writing proprietary 
> PLDM OEM implementations - libraries which can be dynamically loaded at 
> runtime as opposed to compile time linking in of those implementations 
> to the main PLDM code base, thereby requiring the OEM implementations to 
> exist in the main PLDM code base?

If people are determined to write proprietary OEM implementations they can
fork the codebase. It's Apache 2.0, not GPL, so there's no requirement they
redistribute the associated source. I'd be surprised if we as system designers
backed ourselves into a corner where we were forced to load some third-party
proprietary PLDM plugin, given that we're working on OpenBMC.

Not that I'm advocating anyone forks, but it's not like they don't have any
options. That's my $0.02.

Andrew

> 
> Thanks,
> Deepak
> 
> 
> 
>