Inserting a Redfish Aggregator

[Richard Hanley]

Hi James,

I'd expect that we'd be getting data from a mixture of bmcs and host
interfaces.  I'm also expecting that any aggregator would first be put into
production on a host machine, and later moved to OpenBMC.

So that means that we can't make too many assumptions about the
hardware any of the Redfish services are running.

I'm imagining that this project would be connecting a group of management
domains that are on the same "system."  By that definition a system would
be a bunch of physically connected components.

Thanks,
Richard


On Wed, Dec 4, 2019 at 12:18 PM James Feist <james.feist at linux.intel.com>
wrote:

> On 12/3/19 7:14 PM, Richard Hanley wrote:
> > 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's not entity-manager per-say, it's whatever daemon produces the
> correct interface on d-bus. Entity-manager is just one option.
>
> > 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.
> >
>
> Can you describe a bit more where the data would come from? Are you
> thinking of multiple bmcs that are physically attached? Non-physically
> attached bmcs? BMCs not running OpenBmc? One idea I had in the past was
> remoting dbus from other systems in some way and creating a clone daemon
> that would show the interfaces from the other systems, although I never
> looked into it much.
>
> >
> > 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/20191209/1226594d/attachment-0001.htm>