AdiF
Minnow
Posts: 15
|
Post by AdiF on Apr 11, 2024 13:13:14 GMT
We're considering implementing an aggregation system where multiple satellite BMCs operate under the main BMC. While structuring the chassis and managers collection types, we envision organizing the satellite information in a tree-like format such as:
chassis/BMC1/
...
chassis/BMC#/
However, when it comes to services like firmware updates, the schema doesn't include a collection part. So how can I handle cases like:
fw update - for this case there is a solution to use -F 'UpdateParameters={"Targets":["URL"]}. Is there other possibilities? it there a way to present it as a collection like:
/v1/UpdateService/update-multipart/BMC0
/v1/UpdateService/update-multipart/BMC#
fw inventory - also under the updateService, can it be presented in the same way? maybe the collection can be in higher level:
/v1/UpdateService/BMC0
...
/v1/UpdateService/BMC#
Tasks - for example in case of fw update of satellite BMC, we would like to be able access the task from the aggregator, what are the way it can be done? can it be also presented as a collection of satellites BMC?
|
|
|
|
Post by mraineri on Apr 11, 2024 14:16:10 GMT
For FW Update: "Targets" is the right thing to use here. That gives the user the control to specify an exact device to update if they do not want the service to automatically pick the "right" devices. This would be the URI of the resource representing the device (like /redfish/v1/Managers/BMC5). We have the following in the long description for Targets to call out some expected behaviors:
> These targets should correspond to software inventory instances or their related items. If this parameter is not present or contains no targets, the service shall apply the software image to all applicable targets, as determined by the service. If the target specifies a device resource, the software image file shall be applied to the specified device. If the target specifies a resource collection, the software image shall be applied to each applicable member of the specified collection. If the target resource specifies an Aggregate resource, the software image file shall be applied to each applicable element of the specified aggregate. If the target resource specifies a ComputerSystem resource, the software image file shall be applied to the applicable components within the specified computer system.
For FW Inventory: You'd need to grow the members of the FW inventory collection. It's a flat list of everything known to the service. So, I would expect URIs like "/redfish/v1/UpdateService/FirmwareInventory/BMC5".
For Tasks: It would be the responsibility of the aggregator to instantiate a task for itself and internally track the task of the satellite BMC. From the external user's perspective. This would be rolled up under /redfish/v1/TaskService/Tasks like every other task for the aggregator.
|
|
AdiF
Minnow
Posts: 15
|
Post by AdiF on Apr 14, 2024 8:54:32 GMT
Thank-you.
Regarding the chassis URL: DMTF only defined:/redfish/v1/Chassis/{ChassisId}/
In our case, if we have 10 satellites BMCs and each has 3 chassisID we will have a list with more than 30 items:
/redfish/v1/Chassis/01_BMC
/redfish/v1/Chassis/01_BMC_Erot
/redfish/v1/Chassis/01_card1
.
.
.
/redfish/v1/Chassis/10_BMC
/redfish/v1/Chassis/10_BMC_Erot
/redfish/v1/Chassis/10_card1
Issues that may be:
• Latency – In this method, the aggregator has to query each of the satellites BMCs, get the chassis list and add the prefix. This can cause latency issues.
• Log list – the list can hold up to 30 chassis ID which is less friendly to the user.
Can it also represented as:
/redfish/v1/Chassis/Satellite_BMC#/{ChassisId}/
|
|
|
|
Post by mraineri on Apr 15, 2024 11:11:06 GMT
Why is your BMC a Chassis and not a Manager? BMCs are traditionally modeled as Manager resources.
I assume "Erot" is some "root of trust"; why is this it's own Chassis and not something like the "TrustedComponent" resource?
Regardless of the answer to the modeling questions, what you're highlighting is an issue that every aggregator needs to solve. Some aggregators cache resource trees and response bodies locally so they do not have to query downstream devices as often. The method you use is ultimately going to depend upon your aggregator's design and accounting for any limitations with the devices you're aggregating (such as if you can rely on event notifications for resource changes).
|
|
