Inserting a Redfish Aggregator

Inserting a Redfish Aggregator

[Richard Hanley]

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

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

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

Re: Inserting a Redfish Aggregator

[James Feist]

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
> 

Re: Inserting a Redfish Aggregator

[Richard Hanley]

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

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@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
> >
>

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