Inserting a Redfish Aggregator

[Richard Hanley]

Hi everyone,


I’ve been thinking a bit about how to separate Redfish logic from DBus in
bmcweb.


As a motivating example, imagine a Redfish aggregator that has some chassis
that is located outside of its local instance.  Once the aggregator finds
the external chassis, it needs to add it to the chassis collection.


However, looking at the current implementation of the
ChassisCollection.(located here:
https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L246)
It isn’t clear to me how to add this in.


The current implementation does some setup on the response payload, and
then makes a DBus call to look through the entity manager.  The collection
it sends as a response is entirely defined by the result from the entity
manager. I basically see three ways that this could be solved.



   1. Move the aggregator logic down to the entity manager
   2. Refactor the Chassis Collection to have its own data model separate
   from the entity manager.
   3. Create some service that works on top of the bmcweb implementation of
   Redfish.


I think this comes up to a fundamental design decision, how
modular/flexible should the Redfish implementation be?  Right now bmcweb
provides a very sane default implementation, and is tied very closely to
the current hardware it is running on.  Whereas I am envisioning a Redfish
implementation that is a bit more abstracted from any particular hardware.


It’s taken me awhile to get up to speed with Redfish, Open BMC, and
Google’s infrastructure; but I’m starting to get a more concrete design for
an aggregator.  However, I’m unsure about whether this should be framed as
a new layer on top of the existing implementation, or as a refactor of that
implementation?


I can see some pros and cons between the two, but I’m interested in how
everyone feels about this.


Regards,

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191203/c5febaf1/attachment.htm>