|
Post by JenHuang on Nov 19, 2021 10:28:42 GMT
Hi All, Assume there is the sensor data which represent sensor information for the specific controller. (Let's say StorageController/NIC Controller)
Should those sensor information need to be gathered into the resoruce "/redfish/v1/Chassis/{chassis-id}/Sensors"?
"uris": [
"/redfish/v1/Chassis/{ChassisId}/Sensors",
"/redfish/v1/Facilities/{FacilityId}/Sensors",
"/redfish/v1/PowerEquipment/RackPDUs/{PowerDistributionId}/Sensors",
"/redfish/v1/PowerEquipment/FloorPDUs/{PowerDistributionId}/Sensors",
"/redfish/v1/PowerEquipment/Switchgear/{PowerDistributionId}/Sensors",
"/redfish/v1/PowerEquipment/TransferSwitches/{PowerDistributionId}/Sensors",
"/redfish/v1/PowerEquipment/PowerShelves/{PowerDistributionId}/Sensors"
]
If not, what is the reason we don't put the Sensor resource under StorageController as PowerDistributionID does or any logic how to classify this.
|
|
|
Post by mraineri on Nov 19, 2021 13:58:37 GMT
The general pattern we've been encouraging is to put the "Sensor" resource in the physical container that holds the sensor, which means for a NIC or storage controller, the "Sensor" resource will be in the Chassis resource that contains the device. This gives the type of user trying to find all readings regardless of the context an easy location to find all sensor readings for a single container. Keep in mind, there are also "EnvironmentMetrics" resources subordinate to device resources if the user wants to a single location to get readings related to a particular device instance. "EnvironmentMetrics" can reference back to Sensor resources to show where the reading information is stored. Check out the "Simple Rack-mounted Server" mockup here: redfish.dmtf.org/redfish/v1Within the mockup, there is a single "Chassis" resource called "1U" with a SensorCollection that contains all of the Sensor resources. If you then go to /redfish/v1/Systems/437XR1138R2/Processors/CPU1/EnvironmentMetrics in the mockup, there are several readings shown there that are relevant to CPU1. The "DataSourceUri" property for these readings points back to members of the SensorCollection within the "1U" Chassis.
|
|
|
Post by jautor on Nov 19, 2021 15:29:51 GMT
As Mike said, the "EnvironmentMetrics" resource is available under most subsystems, and that is intended to hold the "sensor data" specific to a controller, processor, etc. That resource uses excerpts of Sensor resources - but also note that you can populate simple readings in EnvironmentMetrics without a Sensor resource backing. For items like a StorageController that may simply want to report a temperature or power reading, without setting up thresholds, etc. that becomes a low-effort implementation.
But for actual Sensor resources, it was beneficial to clients to keep those in a central collection for each physical container. Otherwise, a client attempting to gather "all sensor data" would have to traverse the entire tree looking for dozens of collections (each with probably one or two Sensors).
Jeff
|
|