|
|
Post by adamlin on Aug 22, 2024 7:02:01 GMT
Hello Everyone,
The CDU records some information about the cooling loop and cooling connect, but these parameters are read-only.
How can users modify this information to be correct?
(Or is this information unchangeable, requiring changes to be made through programming?)
If I need to understand this information, which documents should I refer to? Thank you.
Thank you for your inquiry.
|
|
|
|
Post by mraineri on Aug 22, 2024 12:44:38 GMT
Inside "CoolantConnector", the "Links/ConnectedCoolingLoop" property is marked as writable.
<NavigationProperty Name="ConnectedCoolingLoop" Type="CoolingLoop.CoolingLoop">
<Annotation Term="OData.Permissions" EnumMember="OData.Permission/ReadWrite"/> <----- Read/Write
<Annotation Term="OData.Description" String="A link to the cooling loop at the other end of the connection."/>
<Annotation Term="OData.LongDescription" String="This property shall contain a link to a resource of type `CoolingLoop` that represents the cooling loop at the other end of the connection."/>
<Annotation Term="OData.AutoExpandReferences"/>
</NavigationProperty>
So, if there is a CoolingLoop resource to connect to a particular connector, a client is allowed to perform PATCH operations on that property; note that it's entirely possible the resource resides outside of the CDU's Redfish service, so an absolute URI may be necessary. That type of request would look something like this:
PATCH /redfish/v1/ThermalEquipment/CDUs/1/PrimaryCoolantConnectors/1
{
"Links": {
"ConnectedCoolingLoop": {
"@odata.id": "https://facility-redfish.contoso.org/redfish/v1/ThermalEquipment/CoolingLoops/FacilityWater"
}
}
}
In the event there is no CoolingLoop to reference, but you'd like to leave an indicator on the CoolantConnector resource that identifies the cooling loop, there's a writable opaque string for this.
<Property Name="CoolingLoopName" Type="Edm.String">
<Annotation Term="OData.Permissions" EnumMember="OData.Permission/ReadWrite"/>
<Annotation Term="OData.Description" String="The name of the cooling loop attached to this interface."/>
<Annotation Term="OData.LongDescription" String="This property shall contain the name of the cooling loop attached to this interface. If the `CoolingLoop` link property is present, this property shall contain the value of the `Id` property in the resource referenced by that link."/>
</Property>
|
|
|
|
Post by adamlin on Aug 27, 2024 7:55:47 GMT
thank you for your response. 1. Account permissions are divided into administrator permissions and regular user permissions. Do these devices' fixed information require higher permissions to be written? Can regular user permissions only allow read access? 2. I have found two paths for controlling the CDU Pump: "/redfish/v1/ThermalEquipment/CDUs/1/Pumps" & "/redfish/v1/Chassis/CDU/Controls/PumpSpeed" Which one is more appropriate? 3. Currently, I am referring to: redfish.dmtf.org/redfish/mockups/wipcdu/1291. It seems that UpdateService and Chassis are not included in the mockup. Can they be added manually? |
|
|
|
Post by mraineri on Aug 27, 2024 15:18:07 GMT
1) The sample privilege registry published by DMTF has "ConfigureComponents" as the required privilege to perform this operation; this maps to the "Operator" standard role. However, you're certainly free to modify this registry. 2) "/redfish/v1/ThermalEquipment/CDUs/1/Pumps" is the starting point for interoperable discovery of pumps. Like how Sensor is used as the source of data for hardened excerpts in the model, Control has the same philosophy. General users would never start with a Control resource since the naming and contents are all vendor-defined. 3) There is an up-to-date public mockup of a CDU here: redfish.dmtf.org/redfish/mockups/v1/1469. It does contain Chassis if you click on the navigation pane, but apparently we missed adding the link in ServiceRoot; I'll notify the group about this issue. UpdateService was omitted for the sake of brevity to emphasize the new modeling specific to CDUs, but in a real product I would expect to see the UpdateService resource supported given that it's the only Redfish method to perform firmware updates. |
|
|
|
Post by adamlin on Aug 28, 2024 9:37:40 GMT
Thank you for your response, much appreciated.
I am still unclear about the differences in application between the administrator and user accounts. What specific differences exist in their usage?
There are some control paths that I still cannot determine: (for CDU)
a. System data reset to factory values
b. Manual mode vs. automatic mode
c. Control target temperature
d. Target flow rate
e. Control parameter unit selection
Are all these defined under /redfish/v1/ThermalEquipment/CDUs/1/Controls?
|
|
|
|
Post by mraineri on Aug 28, 2024 14:42:10 GMT
The differences are dictated by the Redfish privilege registry. The latest publication of this can be found here: github.com/DMTF/Redfish-Publications/blob/main/registries/Redfish_1.5.0_PrivilegeRegistry.jsonThe way to read the registry is it's a list of all resource types defined by the standard, and it maps a required privilege to each HTTP operation. Again, keep in mind you are free to have your own registry definition to meet your product requirements; the registry published by DMTF is just a base reference. Specifically for your use cases (and mapping them to DMTF's copy of the privilege registry)... a. System data reset to factory values: This would map to the Manager resources "ResetToDefaults" action; Manager requires "ConfigureManager", which would equate to an a user with the Administrator role. b. Manual mode vs. automatic mode: There is no standard definition for this today. This would need to be an OEM property in some resource (perhaps CoolingUnit, but it's going to be dependent on what this mode is really toggling). c. Control target temperature: There is no hardened location for this (I assume we'd like to have this in CoolantConnector eventually). Today this would need to be done in a Control resource, which requires "ConfigureManager" for PATCH operations. d. Target flow rate: Same as "c"; would like to see this on something like CoolantConnector eventually, but today you can only achieve this on a Control resource defined by the vendor. e. Control parameter unit selection: I'm not even sure what this means. Do you mean changing the "units" on readings? If so, that is not something we support in Redfish. Redfish is trying to align folks on a single, consistent reading type to ensure interoperability (such as keeping all temperature reporting in "Celsius"). |
|
