OpenBMC and Redfish - intro

OpenBMC and Redfish - intro

[Chris Austen]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]



Well that is a loaded subject line!

We have talked for a while about wanting to support the DMTF Redfish REST
interface.  Support would allow operators to adhere to a growing industry
standard and allow communities such as OCP (Open Compute Project) a
platform to put in to practice their profiles.  I think Operators and API
developers would also appreciate the interface.

At the Developer Congress in May 2017 we started working with
https://github.com/DMTF/Redfish-Profile-Simulator/tree/upgrade-0.9.5.  It
looks like it could be a great fit for implementation in the OpenBMC
Project.  The profile simulator code base seems to contain a front and back
end.  The front handling errors, REST, Parameter validation, Paths, etc
while the back end captures the data from the physical hardware.  The back
end; at discovery time, also informs the front end what is supported.
Seems like a great division of labor and very testable since validation
tools could be coded against both sides.

There are a few architectural discussion that need to occur around Redfish
and the mailing list is currently the best forum for that.  Let's start
with a really basic design point...  Translating to Odata: Compile vs
Runtime.

OpenBMC today at compile time knows what is supported (properties and
paths) via YAML files.  You could then in theory build the complete JSON
Schema for fixed values at compile time by probing in to different projects
such as https://github.com/openbmc/phosphor-dbus-interfaces (great for
static validation testing).  You could create static values inside the
meta-openbmc-machines layers (i.e. model#, Redfish version, etc) or support
various standard profiles in a layer such as meta-openbmc-redfish/meta-ocp.
Down side is you have to probe repositories and parse lots of YAML.

Runtime discovery puts some more effort on to the dbus objects but forces a
cleaner translation (who tells you that the host power only supports on/off
not reboot).  That may not actually be a benefit since we were pretty
active about not creating IPMI properties in our dbus objects.  Runtime
would run through all the dbus interfaces and translate them to Redfish.
In a single Redfish repository you could create the translation rules which
would simplify the code layout.  It would likely also mean that you avoid
YAML translations.  I don't think I am giving Runtime enough justice
really.  That or I've answered my own question.

I'm leaning towards compile time myself.  Thoughts?  Any volunteers that
would like to participate in helping to develop the architecture and coding
out a schema?


Chris Austen
The OpenBMC Project community evangelist

[-- Attachment #2: Type: text/html, Size: 3163 bytes --]

Re: OpenBMC and Redfish - intro

[Stewart Smith]

Chris Austen <austenc@us.ibm.com> writes:
> Well that is a loaded subject line!
>
> We have talked for a while about wanting to support the DMTF Redfish REST
> interface.  Support would allow operators to adhere to a growing industry
> standard and allow communities such as OCP (Open Compute Project) a
> platform to put in to practice their profiles.  I think Operators and API
> developers would also appreciate the interface.

AS someone who's likely to consume it (via our test infrastructure for
OpenPOWER firmware), I'm really keen to see it.

I know at least one other BMC implementation we interact with is doing
RedFish, and it'd be good to have only one set of code to talk to BMCs,
rather than the current situation.

-- 
Stewart Smith
OPAL Architect, IBM.