<div dir="ltr">Hi Brad and Ed,<div><br></div><div>I wanted to check in with you and the rest of the community about the design path and requirements we're considering for a Redfish Aggregator.<br><br>When I think about an Aggregator in this context, I'm thinking about several Redfish services that are connected to each other using a star topology.  The central service would be the only service exposed to clients on the outside network. <br></div><div><br></div><div>The central service would for all intents and purposes look like a single service to clients, and on the backend it would act as a proxy to the other hidden services.</div><div><br></div><div>One of the big design questions to consider is how thick or thin the central services caching should be.  In my opinion, the central service should cache the URI for each of the top level collections (i.e. Chassis collections, System collection, and Manager collections).  This should be a decent compromise between performance when clients traverse the resource tree and overhead in synchronizing the cache in the central agent.</div><div><br></div><div>I will be talking with DMTF soon about any extensions to the spec that might be needed.  In my opinion, this could be accomplished with the spec as it currently stands, but I'd like to get some input in the following areas:</div><div>   1) DMTF may want to standardize the algorithm that merges separate resource collections into one collection with unique IDs</div><div>   2) There are some questions internally about whether there should be some metadata letting consumers know that they are working with a proxied resource.  DMTF may have some concerns about treating a proxied resource exactly as a local resource.</div><div>   3) DMTF was considering an aggregation service that would allow clients to manage some of the aggregation.  Personally, I'm not a huge fan of this approach, but we'd want to make sure that what we're doing doesn't get in the way of those plans.</div><div><br></div><div>Anyways, hopefully this huge textblock helps clarify some of Google's thinking on this issue.  I'm still working on getting up to speed on both Redfish and open-bmc, so any feedback is greatly appreciated.  Hopefully in the next couple of weeks I can incorporate feedback from the community and DMTF, and start getting together a design document for review.</div><div><br></div><div>Best Regards,</div><div>Richard</div><div><br></div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 11:32 AM Richard Hanley <<a href="mailto:rhanley@google.com">rhanley@google.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"><div dir="ltr">Thank you Ed.  I will take a look a look at that fork.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 10, 2019 at 11:09 AM Ed Tanous <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@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 10/10/19 10:09 AM, Nancy Yuen wrote:<br>
> Thanks Brad!  We are envisioning aggregating the separate Redfish stacks<br>
> to present a single unified system view.  There is another slide deck of<br>
> Redfish Aggregator requirement uploaded to DMTF a few days ago with a<br>
> slightly different idea of aggregation (it sounds more like batching,<br>
> the aggregator will send a reboot or a fw update, to a bunch of redfish<br>
> stacks on multiple systems).<br>
> <br>
<br>
You might want to look at this bmcweb fork that Inspur built for exactly<br>
this.<br>
<a href="https://github.com/inspur-bmc/rmcweb" rel="noreferrer" target="_blank">https://github.com/inspur-bmc/rmcweb</a><br>
<br>
<br>
It wasn't built the way I would've recommend it be built, and a lot of<br>
it is relying on fake data, but it's a reasonable example of wiping out<br>
all the bmcweb Redfish endpoints and replacing them with aggregator<br>
ones, without having to modify the core.<br>
</blockquote></div>
</blockquote></div>