Redfish OEM commands in OpenBMC

[Brad Bishop]

On Tue, Apr 23, 2019 at 03:12:55PM -0700, Ed Tanous wrote:
>On 4/23/19 10:52 AM, Brad Bishop wrote:
>> On Tue, Apr 23, 2019 at 09:27:36AM -0700, Ed Tanous wrote:
>>> On 4/23/19 6:51 AM, Brad Bishop wrote:
>>>> On Mon, Apr 22, 2019 at 09:19:37AM -0700, Ed Tanous wrote:

>>> 2. Use LogEntry and LogService to log your PEL entries like the other
>>> 3-4 examples of logging do today.  Given that schema is very broad it
>>> allows you to log essentially whatever you want into the message field.
>>> This would also give the easiest time for people to port, and give you a
>>> "standard Redfish" way to download your PEL logs.
>>
>> This might be feasible.  I just don't know enough about the logging
>> schema.  I'll have to do some reading.

I asked around here and this is actually what we intend to do.  Create
"Event" type instances of LogEntry, and put our PEL stuff in the OEM
property.  It sounds like this is ok with you.  Can you confirm?

>>> 3. (Really not preferred) Use one of the other open source Redfish
>>> servers that supports runtime pluggable endpoints. 
>>
>> I guess option 3 prime is we fork bmcweb, and implement pluggable OEM
>> callbacks there :wink:
>
>This was originally listed as option seven, but I realized if you wanted
>to do this, you would've already, and likely wouldn't be bringing it up
>on the mailing list.  I'm happy to be proven wrong here that pluggable
>callbacks could be done in a non-complicated easy to follow way, but
>every option I've seen makes some really unfortunate tradeoffs in
>readability, complexity, or performance.

I don't understand what is so hard here.  Vernon was able to pull this
off with IPMI...why does this have to be any different (and in the same
vein, why is the flexibility offered and required in our IPMI core but
not our Redfish core?)

>>> The point here is mostly that all the servers that defined endpoints
>>> that were "pluggable" the way it was described ended up becoming overly
>>> complicated, and IMHO lost a lot of battles because of said complexity.
>>> This is not to say bmcweb is "simple" by any means.
>>>
>>> 4. Implement it as an odata endpoint, not necessarily in the Redfish
>>> tree.  If your goal isn't industry compliance and acceptance, you might
>>> consider moving a level up, and simply define your endpoints as odata
>>> endpoints under a different URL tree.  This would depend on your end
>>> goals, that I don't fully understand at this point.
>>
>> This is the closest thing to what I had in mind.  But how is this not a
>> a pluggable OEM handler?  Are you saying pluggable OEM handlers in
>> bmcweb are OK as long as the route being handled is outside the /redfish
>> namespace?
>
>AH, I see the confusion.  When I hear "pluggable" I assume that means
>runtime-pluggable dynamic resolution of plugins and interfaces.  If I
>understand you correctly, that's not what the "plugin" discussion was.
>We can certainly enable/disable features using the existing configure
>mechanisms at compile time.  There are already a dozen or so examples of
>enabling/disabling features at compile time, including the existing
>logging implementations.
>https://github.com/openbmc/bmcweb/blob/424c4176bbbc55c0cfd08f273b7e4500c977a138/CMakeLists.txt#L11
>
>We could certainly add another custom URL handler for PEL logs if that's
>the route you want to go down, although I'd personally still prefer
>option 2, as we can at least keep it somewhat in the standard.

Agreed on option #2.  However I still think you should consider runtime
pluggable dynamic resolution.

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?  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?  Does it make sense for you
to be the maintainer of code you have zero investment in?

>>> Have you asked the same question on Redfish forum?  There are
>>> significantly more experts there, and they might have even better ideas
>>> than I do to improve your standards compliance on what you're trying to
>>> implement.
>>
>> No.  I hope it is clear now that I really am not motivated to try and
>> standardize PEL, or on the flip side, to change all of our internal
>> business processes around to make use of something else.
>
>I'm sure there's a way to work through it as a community, and I will
>fully admit that I have similar things of my own that have the same need.
>
>Any feature is going to be hard going if the position starts with the
>premise: "we have this feature on non openbmc systems, with a closed
>spec, we don't want to change it, and we want it implemented in openbmc
>master because we need backward compatibility".  With that said, I'm
>sure there's a way to get it in if it's something you need.

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.