Redfish Aggregator

Redfish Aggregator

[Nancy Yuen]

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

Has anyone looked at the Redfish Aggregator proposal that was voted on in
DMTF recently?
We have a need for this functionality. Would anyone else find it useful?
Would anyone be interested in collaborating?

----------
Nancy

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

Re: Redfish Aggregator

[Nancy Yuen]

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

Ping?  No one is interested in this?
----------
Nancy


On Fri, Sep 27, 2019 at 12:59 PM Nancy Yuen <yuenn@google.com> wrote:

> Has anyone looked at the Redfish Aggregator proposal that was voted on in
> DMTF recently?
> We have a need for this functionality. Would anyone else find it useful?
> Would anyone be interested in collaborating?
>
> ----------
> Nancy
>

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

Re: Redfish Aggregator

[Brad Bishop]

at 3:59 PM, Nancy Yuen <yuenn@google.com> wrote:

> Has anyone looked at the Redfish Aggregator proposal that was voted on in  
> DMTF recently?
> We have a need for this functionality. Would anyone else find it useful?  
> Would anyone be interested in collaborating?

Hi Nancy

In the past IBM has made NUMA systems with multiple chassis that are  
stitched together into a single SMP fabric.  In these systems each chassis  
has one or more BMCs.

If a “Redfish Aggregator” would aggregate the Redfish stacks on each BMC in  
a system like this, then that sounds like an effort that IBM would  
potentially find useful and want to contribute to.

thx!  -brad

Re: Redfish Aggregator

[Nancy Yuen]

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

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).

Our next step is to write up the requirements for a Redfish Aggregator for
our use cases. We would love input from others in OpenBMC as well.  We can
share this with the Redfish Forum.

----------
Nancy


On Tue, Oct 8, 2019 at 11:54 AM Brad Bishop <bradleyb@fuzziesquirrel.com>
wrote:

> at 3:59 PM, Nancy Yuen <yuenn@google.com> wrote:
>
> > Has anyone looked at the Redfish Aggregator proposal that was voted on
> in
> > DMTF recently?
> > We have a need for this functionality. Would anyone else find it
> useful?
> > Would anyone be interested in collaborating?
>
> Hi Nancy
>
> In the past IBM has made NUMA systems with multiple chassis that are
> stitched together into a single SMP fabric.  In these systems each
> chassis
> has one or more BMCs.
>
> If a “Redfish Aggregator” would aggregate the Redfish stacks on each BMC
> in
> a system like this, then that sounds like an effort that IBM would
> potentially find useful and want to contribute to.
>
> thx!  -brad
>

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

Re: Redfish Aggregator

[Ed Tanous]

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.

Re: Redfish Aggregator

[Richard Hanley]

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

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

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

Re: Redfish Aggregator

[Richard Hanley]

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

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

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

Re: Redfish Aggregator

[Deepak Kodihalli]

On 18/10/19 5:14 AM, Richard Hanley wrote:
> 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.

Would the redfish aggregator talk Redfish to the endpoints? Or could 
they communicate via other (inband) protocols? Just curious if this will 
be left to the implementation or will this be specified.

Also, if this is applied to a multi-chassis system (where each chassis 
has a BMC), could any BMC take up the role of an aggregator dynamically?

Thanks,
Deepak