Adding a detailed physical model to bmcweb

[Richard Hanley]

One of the requirements we have for our data center management software is
that we need to be able to map resources (e.g. actions, telemetry, and
assemblies) directly to the physical component that it originated from as
well as how those components are physically connected.

Historically this mapping was done through a custom protocol on the host,
and we would like to move this to a Redfish service on the BMC. Another
engineer spoke with DMTF, and the most Redfishy way to represent this would
be by adding links in the assemblies. Some examples of possible
relationships are:

*/Systems/1/Memory/1/Assembly ------> /Chassis/Mobo/Sensors/MemSensor*
*/Chassis/Mobo/PCIeDevices/Storage/Assembly ---------->
/Systems/1/Storage/BootVolume*
*/Chassis/Mobo/PCIeDevices/ExpansionTray/Assembly --------->
/Chassis/ExpansionTray/Assemby*

That last example is actually represented in the current Redfish spec, but
it helps explain the idea I'm getting at.  The hope is that by starting at
the service entry point we can get a physical model of the component tree
by traversing hyperlinks. From that a client could relate any Redfish
resource to its physical component.

Let's just say for the moment that we get a service that collects this
information, I've been trying to figure out a way to sustainably add it
into bmcweb.  Presumably this would be a large amount of OEM material that
OpenBMC wouldn't want to support upstream.

I don't think making patches in bitbake or subclassing the individual nodes
will be sustainable in the long run.  At a minimum a way to chain
co-routines would allow for other code to "attach" to the response handlers.

So I guess there are a couple of questions here.  Does the community have
any plans/desire to support an extension mechanism in bmcweb? If so, should
we be thinking of in-process code extensions or inter-process dynamic
extensions?

For the record, this requirement does not have an imminent deadline, so I
am happy to design around the best long term solution as opposed to a short
term hack.  I just wanted to get a plan here before things become imminent.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20200225/79e2017d/attachment.htm>