Redfish OEM commands in OpenBMC

[Brad Bishop]

On Thu, May 02, 2019 at 09:09:08AM -0700, Ed Tanous wrote:
>On 5/1/19 11:05 AM, 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.
>
>I think the above statement would be a lot more productive if you had a
>patchset that removed some of the existing ifdefs, so we can see what
>you're thinking.  
Haha now you are asking me to do real work, so its time for me to drop
the point.

>> 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.
>
>I do recall, and I recall his attempted solution to it with go-redfish
>was difficult to understand and modify, and had some CPU usage penalties
>due to its caching and plugin requirements.  If plugins met the exact
>intent of what the framework intended them to do, then it functioned
>just fine, but the minute it reached past what the interface was able to
>define, things got very complicated very quickly IMHO.
>With respect to that, the primary goal of that plugin interface was an
>issue that I don't think OpenBMC cares about: the ability to take
>OpenBMC components (in this case redfish) and integrate them into
>private, non-OpenBMC codebases.  If you're integrating with a private
>codebase, you're forking either way.
I don't understand "non-OpenBMC codebase."  How many lines of code does
one have to change before a fork is no longer an OpenBMC codebase?

I also don't understand how "OpenBMC" can care about something.  OpenBMC
is me, you, IBM, Intel, and whole host of others that all care about
lots of different, conflicting even, things.

If we structure the code in such a way that it enables product teams
with "non-OpenBMC codebases" to make use of and therefore have a
motivation to contribute back to and share in the development and
maintanence burden of the shared pieces of code then that is something
that I very much care about.

>> 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?
>>
>Agreed, would love to hear more opinions on this.