Redfish OEM commands in OpenBMC

Andrew Jeffery andrew at aj.id.au
Thu Apr 18 15:26:00 AEST 2019



On Wed, 17 Apr 2019, at 04:33, Andrew Geissler wrote:
> Greetings,
> 
> As more and more of us are implementing Redfish within OpenBMC we are starting
> to run into situations where the function we need to implement is not available
> in the current Redfish schemas.
> 
> We've been joining DMTF workgroups and starting to get familiar with the process
> but, if OpenBMC upstreaming is considered slow, it's looking like upstreaming
> to the DMTF could be even slower.
> 
> So my question is, are we taking a no OEM policy within OpenBMC? Or are we going
> to take a more flexible approach. Similar to openbmc/linux, as long as you're
> working upstream with the DMTF on your changes, OEM would be acceptable?

I'd be more cautious here - breaking the OpenBMC kernel ABI due to carrying
patches that are not yet upstreamed isn't great, but we can adapt userspace
without breaking the external interface to OpenBMC. Breaking the external
interface to OpenBMC is much worse from a user perspective. Essentially, you
need to be prepared to support the OEM extensions well beyond standardisation
of the non-OEM equivalent.

RFC6648[1] seems informative here:

Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

At least, that's my $0.02.

Andrew

[1] https://tools.ietf.org/html/rfc6648

> 
> From what I've seen so far, it looks like a lot of companies have gone the OEM
> route initially. They then use that experience to guide the discussion with the
> DMTF workgroups.
> 
> There could be some gray areas. For example, I want to add a Priority
> property to the UpdateService [1]. Maybe this would be ok to carry as an OEM
> for a bit? Adriana wants to propose a whole new backup and restore design [2].
> Maybe that needs a bit more traction upstream to ensure it's going in the right
> direction for something DMTF would approve first? If we start limiting ourselves
> as a community on what DMTF has approved, I think we're going to struggle to
> deliver certain new functions.
> 
> Andrew
> 
> [1] https://github.com/DMTF/Redfish/issues/3357 (can only see with DMTF access)
> [2] https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/18163
>


More information about the openbmc mailing list