|
|
Post by chitkala on Nov 24, 2021 5:26:53 GMT
Hi,
In a system with multiple BMCs, where network access is available to only one BMC (say main BMC) - what is the recommended way to present access to the other BMCs (say satellite BMC)?
Rather than absorb the resource hierarchy presented by the satellite BMC into the main BMC (the one responding to client requests), if the main BMC just wants to function as a forwarding agent - is there a property available that can be used to indicate such a relationship? (This is not a disaggregated system, so Composition service/Resource blocks did not seem like an option to pick.)
Thanks & regards, Chitkala.
|
|
|
|
Post by jautor on Nov 24, 2021 19:41:58 GMT
Yes, the `ManagedBy` and `ManagerForManagers` properties in Manager is used to show that type of hierarchy. But I'm not sure I understand how the access would work without "absorbing the resource hierarchy" - and the whole point of the top-level resource collections (Systems, Chassis, Managers, etc.) is to allow for whole trees to be easily combined. Take a look at the bladed system mockup for an example of how this can be accomplished, and made transparent to the client software. But unless there's a reason for generic client software to "know" about multiple BMCs/managers within a system, we generally want to keep those infrastructure details out of the way... The "main BMC" just assigns resource collection member ID's for each top-level resource (System, Chassis, Manager) to each satellite BMC, and then all the subordinate URIs can be easily "owned" (and routed to...) the satellites. Then clients just see collections with multiple members and a flat resource tree - they don't have to know about the satellites in the infrastructure. But if they NEED to know, they can follow the `ManagedBy` / `ManagerForManagers` links to see that infrastructure. See "Bladed System" mockup: redfish.dmtf.org/redfish/mockups/v1Hope that helps, Jeff |
|
|
|
Post by chitkala on Dec 1, 2021 1:10:09 GMT
|
|
