<div dir="ltr"><div>Hi James,</div><div><br></div><div>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.</div><div><br></div><div>So that means that we can't make too many assumptions about the hardware any of the Redfish services are running.</div><div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Richard</div></div><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 4, 2019 at 12:18 PM James Feist <<a href="mailto:james.feist@linux.intel.com" target="_blank">james.feist@linux.intel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 12/3/19 7:14 PM, Richard Hanley wrote:<br>
> Hi everyone,<br>
> <br>
> <br>
> I’ve been thinking a bit about how to separate Redfish logic from DBus <br>
> in bmcweb.<br>
> <br>
> <br>
> As a motivating example, imagine a Redfish aggregator that has some <br>
> chassis that is located outside of its local instance.Once the <br>
> aggregator finds the external chassis, it needs to add it to the chassis <br>
> collection.<br>
> <br>
> <br>
> However, looking at the current implementation of the <br>
> ChassisCollection.(located here: <br>
> <a href="https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L246" rel="noreferrer" target="_blank">https://github.com/openbmc/bmcweb/blob/master/redfish-core/lib/chassis.hpp#L246</a>) <br>
> It isn’t clear to me how to add this in.<br>
> <br>
> <br>
> The current implementation does some setup on the response payload, and <br>
> then makes a DBus call to look through the entity manager.The collection <br>
<br>
It's not entity-manager per-say, it's whatever daemon produces the <br>
correct interface on d-bus. Entity-manager is just one option.<br>
<br>
> it sends as a response is entirely defined by the result from the entity <br>
> manager. I basically see three ways that this could be solved.<br>
> <br>
> <br>
>  1. Move the aggregator logic down to the entity manager<br>
>  2. Refactor the Chassis Collection to have its own data model separate<br>
>     from the entity manager.<br>
>  3. Create some service that works on top of the bmcweb implementation<br>
>     of Redfish.<br>
> <br>
> <br>
> I think this comes up to a fundamental design decision, how <br>
> modular/flexible should the Redfish implementation be?Right now bmcweb <br>
> provides a very sane default implementation, and is tied very closely to <br>
> the current hardware it is running on.Whereas I am envisioning a Redfish <br>
> implementation that is a bit more abstracted from any particular hardware.<br>
> <br>
<br>
Can you describe a bit more where the data would come from? Are you <br>
thinking of multiple bmcs that are physically attached? Non-physically <br>
attached bmcs? BMCs not running OpenBmc? One idea I had in the past was <br>
remoting dbus from other systems in some way and creating a clone daemon <br>
that would show the interfaces from the other systems, although I never <br>
looked into it much.<br>
<br>
> <br>
> It’s taken me awhile to get up to speed with Redfish, Open BMC, and <br>
> Google’s infrastructure; but I’m starting to get a more concrete design <br>
> for an aggregator.However, I’m unsure about whether this should be <br>
> framed as a new layer on top of the existing implementation, or as a <br>
> refactor of that implementation?<br>
> <br>
> <br>
> I can see some pros and cons between the two, but I’m interested in how <br>
> everyone feels about this.<br>
> <br>
> <br>
> Regards,<br>
> <br>
> Richard<br>
> <br>
</blockquote></div>