<html><body><p><font size="2">Well that is a loaded subject line!</font><br><br><font size="2">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. </font><br><br><font size="2">At the Developer Congress in May 2017 we started working with </font><a href="https://github.com/DMTF/Redfish-Profile-Simulator/tree/upgrade-0.9.5"><font size="2">https://github.com/DMTF/Redfish-Profile-Simulator/tree/upgrade-0.9.5</font></a><font size="2">. 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. </font><br><br><font size="2">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. </font><br><br><font size="2">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 </font><a href="https://github.com/openbmc/phosphor-dbus-interfaces"><font size="2">https://github.com/openbmc/phosphor-dbus-interfaces</font></a><font size="2"> (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. </font><br><br><font size="2">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. </font><br><br><font size="2">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?</font><br><br><font size="2"><br>Chris Austen<br>The OpenBMC Project community evangelist </font><BR>
</body></html>