Redfish Aggregator

[Richard Hanley]

Hi Brad and Ed,

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.

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.

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.

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.

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:
   1) DMTF may want to standardize the algorithm that merges separate
resource collections into one collection with unique IDs
   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.
   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.

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.

Best Regards,
Richard


On Thu, Oct 10, 2019 at 11:32 AM Richard Hanley <rhanley at google.com> wrote:

> Thank you Ed.  I will take a look a look at that fork.
>
> On Thu, Oct 10, 2019 at 11:09 AM Ed Tanous <ed.tanous at intel.com> wrote:
>
>> On 10/10/19 10:09 AM, Nancy Yuen wrote:
>> > Thanks Brad!  We are envisioning aggregating the separate Redfish stacks
>> > to present a single unified system view.  There is another slide deck of
>> > Redfish Aggregator requirement uploaded to DMTF a few days ago with a
>> > slightly different idea of aggregation (it sounds more like batching,
>> > the aggregator will send a reboot or a fw update, to a bunch of redfish
>> > stacks on multiple systems).
>> >
>>
>> You might want to look at this bmcweb fork that Inspur built for exactly
>> this.
>> https://github.com/inspur-bmc/rmcweb
>>
>>
>> It wasn't built the way I would've recommend it be built, and a lot of
>> it is relying on fake data, but it's a reasonable example of wiping out
>> all the bmcweb Redfish endpoints and replacing them with aggregator
>> ones, without having to modify the core.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191017/d366c993/attachment.htm>