Architecture doc should indicate goal of sunfish_server_reference code is to be capable of being cascaded hierarchically for scaling purposes.

[rherrell]

The Sunfish Service is architected to be an aggregator of Redfish resources from multiple sources we call Agents. Since the Sunfish Service uses the Redfish API to communicate with both Clients (users of the Sunfish Service) and Agents (source of Redfish objects and their control surfaces), the core library and its plug-ins theoretically can be hierarchically cascaded. The top-level Sunfish Service feeds multiple clients the aggregated Redfish models from multiple Agents. Each such Agent can be aggregating Redfish models from multiple hardware managers OR lower-level Agents. This tactic of higher level Agents aggregating the inventory and management scope of lower-level Agents can be extended to many levels to support scaling the overall Sunfish Service scope to cover extensive installations.

We have architected and implemented the sunfish_library_reference code and the sunfish_server_reference code to be used as the basis for either a Sunfish Service instance or a Sunfish Agent instance. We have mockup-based examples of a Sunfish Service / Sunfish Agent emulator for both an NVMeoF fabric and a CXL fabric. Both of these emulators demonstrate the use of multiple instances of the sunfish_server_reference code API application in all roles of Sunfish server and Sunfish agent.

We need to point out this design goal and how our implementation methodology satisfies it in the Sunfish Docs architecture document.