<div dir="ltr">HI all,<div><br></div><div>Apologies for being radio silent on a BMC aggregator for the last few weeks.  This email is a bit long, but I wanted to give everyone a quick snapshot of what I've been thinking about in this space.</div><div><br></div><div>(As a quick aside, I mentioned in the last meeting that I will be giving a talk at the <a href="https://www.opencompute.org/summit/global-summit/schedule" target="_blank">OCP Summit in March</a>.  The talk should be summarizing the discussions we've had here in Open BMC, and will be trying to raise interest in the problem.  Hopefully I'll get to meet some of you at the summit).</div><div><br></div><div>Anyways, the last few discussions about the aggregator have made it clear that there is some conceptual work to be done on defining what exactly the aggregator is, and what services need to be created.</div><div><br></div><div>To that end, I think the most concise definition of the aggregator is that it is a way for services to register an API, and consistent semantics for frontends to be built on top of the registered APIs.</div><div><br></div><div>So from the aggregator's point of view, there is no difference between a local resource or a remote resource.  This implies that any frontend built on top of the aggregator wouldn't have to worry about "where" the request gets handled, since that concept has been abstracted away.</div><div><br></div><div>Originally, I was thinking that this aggregation service would be done using Redfish.  This has some problems for systems that want to use another protocol, or want to use some mixture of protocols (i.e. a out of band Redfish service alongside an in band IMPI host interface).</div><div><br></div><div>However, as a jumping off point I asked myself three questions:</div><div>  1) What is the minimum amount of information I would need to construct a Redfish service?</div><div>  2) How reusable is that minimal data model for other protocols and use cases?</div><div>  3) How well does it support our existing DBus usage and ecosystem?</div><div><br></div><div>From that I think we can get a lot of traction by combining two core data types: Resource Nodes and Edges.</div><div><br></div><div>A resource node would contain the following:</div><div>  Profile - This would be metadata about the resource, including schema, cache policy, names, and ACLs</div><div> </div><div>  Supported Methods - Resources could implement any of the HTTP methods (GET, PUT, POST, PATCH, DELETE).</div><div><br></div><div>  Supported Actions - Redfish makes a distinction between calls that manipulate data and calls that manipulate the physical world.  I think that separation makes a lot of sense in a general protocol.</div><div>   </div><div>   Event Dispatch - This would be the async method for resources to send events up to any frontend that was listening</div><div><br></div><div>   Task Monitor - Each resource may have tasks that are being run as part of another request.  By giving each resource a task monitor they can own their tasks without needing to integrate into some global monitor.</div><div><br></div><div>Meanwhile the edges would connect resources together, and contain a list of tags that describe the relationship (e.g. collection membership, contained by, managed by, etc.)</div><div><br></div><div>One thing I like about this data model is that it let's us do some meaningful work at the aggregation layer without having to know anything about the data/methods that the resources are providing.  </div><div><br></div><div>When it comes to sociability with other protocols, I think it is relatively lightweight.  The data model is a bit richer than what IPMI offers, but I don't think it is so rich that it would be extra hard to write wrappers.  It would also be a very useful component if the community wanted to support RDE over PLDM.</div><div><br></div><div>So, to close this email, I want to lay out how I would imagine this aggregator would be used in practice.</div><div><br></div><div>Once the aggregator starts up it would have a root resource.  This would give any important process metadata, a default entry point to look at registered resources, and a place for clients to listen for events.</div><div><br></div><div>Daemons could then register resources.  When they register a resource, they would give the resource definition and the edges used to connect it into the aggregator's resource graph.  The aggregator would send event messages to any listeners whenever a resource is created or destroyed.</div><div><br></div><div>When it comes to presenting these resources to the outside world, a frontend could contain an in memory copy of the resource definition and edges (since those would be relatively stable), and query the aggregator for a snapshot of resources at a given time.  The hope is that frontends could be as stateless as possible.</div><div><br></div><div>There are some other topics I could add. In particular I think caching becomes a very important subject once you start managing distributed BMCs.  However, this email has gotten long enough, so I think I will save that for another day.</div><div><br></div><div>Thanks,</div><div>Richard</div><div></div></div>