|
|
Post by deron1095 on Feb 23, 2023 7:25:15 GMT
Hi, here is the "FanSpeedPercent" schema in "PowerSupplyMetrics".
"FanSpeedPercent": {
"anyOf": [
{
"$ref": "http://redfish.dmtf.org/schemas/v1/Sensor.json#/definitions/SensorFanExcerpt"
},
{
"type": "null"
}
],
"description": "The fan speed (percent) for this power supply.",
"excerptCopy": "SensorFanExcerpt",
"longDescription": "This property shall contain the fan speed, in percent units, for this resource. The value of the DataSourceUri property, if present, shall reference a resource of type Sensor with the ReadingType property containing the value `Percent`."
}
The problem is that some PSUs contain more than 1 FAN. FanSpeedPercent should have an array type just like other objects that contain an array property.
e.g:
"RailCurrentAmps": {
"description": "The output currents (A) for this power supply.",
"excerptCopy": "SensorCurrentExcerpt",
"items": {
"$ref": "http://redfish.dmtf.org/schemas/v1/Sensor.json#/definitions/SensorCurrentExcerpt"
},
"longDescription": "This property shall contain the output currents, in ampere units, for this power supply. The value of the DataSourceUri property, if present, shall reference a resource of type Sensor with the ReadingType property containing the value `Current`. The sensors shall appear in the same array order as the OutputRails property in the associated PowerSupply resource.",
"type": "array"
}
|
|
|
|
Post by jautor on Feb 23, 2023 15:27:01 GMT
We knew there would be some PSU designs that had more than one fan. But our approach was to keep the schema simple for the >95% of designs that have only one fan. Our assumption is that in designs with more than one, they could be treated / reported as a "set" with a single set of values. Meaning, if there were two fans, the PSU could report the best/worst information for both fans in one set of values. We made that assumption thinking that those "details" wouldn't matter to a user, because a fan failure inside the PSU was not "user serviceable" - so regardless of Fan #1 or Fan #2 failing, the user actions for "PSU Fan Failure" are the same.
Is that a reasonable answer for your design? Do you have multiple speeds expected, or is that an error condition only?
If you need to report multiple fans - you can do that as an OEM section in that resource `AdditionalFan` (or Fans?). But I'd like to hear feedback on this, because if our assumption is not correct, we may need to provide some additoinal support in the standard schema.
Jeff
|
|
|
|
Post by deron1095 on Feb 24, 2023 3:13:36 GMT
Hi Jautor, thanks for replying
It seems we are not able to add other readings according to the Schema shown below, there are no proper properties to show values for redundancy fan value.
"SensorFanExcerpt": {
"additionalProperties": false,
"description": "The Sensor schema describes a sensor and its properties.",
"excerpt": "SensorFan",
"longDescription": "This resource shall represent a sensor for a Redfish implementation.",
"patternProperties": {},
"properties": {
"DataSourceUri": {},
"Reading": {},
"SpeedRPM": {}
},
"type": "object"
}
In my opinion, considering implementation effort and flexibility, use SensorFanArrayExcerpt within PowerSupplyMetrics might be the simplest way, it also align to other properties in PSU metrics either.
|
|
|
|
Post by jautor on Feb 27, 2023 17:19:19 GMT
Hi Jautor, thanks for replying It seems we are not able to add other readings according to the Schema shown below, there are no proper properties to show values for redundancy fan value. Ah, if you have redundancy needs for those fans as well, after discussion with the group, we'd propose two possible solutions with the existing schemas. We'd really like to avoid expansion of a 'Fan subsystem' under the individual power supply resources, as we've been able to model those for all other cases within the (physical) "Chassis" schema models. Option 1: (easier, but assumes you have some control over the parent Chassis resources) - Model each power supply Fan as a member of the Fan collection in the parent "Chassis" resource (Thermal Subsystem/Fans), with a `PhysicalContext` of "PowerSupply" to differentiate them from the other Chassis/System-level fans. - This also provides support for the `FanRedundancy` object in that "ThermalSubsystem" Option 2: (more involved) - Model an additional "Chassis" resource for each power supply, along with the "ThermalSubsystem" and "Fan" resource collection for each. For both options, we would recommend that the `FanSpeedPercent` in the "PowerSupplyMetrics" resource be populated with a composite sensor value so that mainstream applications will be able to detect and display a fan summary even if they are not aware of the extra complexity added for these multiple, redundant fans. Let us know if one of those solutions works for you. Again, we're hesitant to add complexity to the standard schema for cases we believe are a fraction of the implementations, but we do want to have a workable solution - even if that answer is "add some OEM areas". Jeff |
|
|
|
Post by deron1095 on Mar 1, 2023 7:35:20 GMT
Hi, thanks for replying, it's my fault to use the "redundancy" word. Our PSU contains two fans, a front fan, and a back fan to increase the airflow over the same area, "redundancy" should not be used to describe our needs, and that did not conform to our architecture either. Here is our current PowerSupplyMetrics URI {
"@odata.type": "#PowerSupplyMetrics.v1_0_0.PowerSupplyMetrics",
"@odata.context": "/redfish/v1/$metadata#PowerSupplyMetrics.PowerSupplyMetrics",
"@odata.id": "/redfish/v1/Chassis/1u/PowerSubsystem/PowerSupplies/0/Metrics",
"@odata.etag": "ce0e0b74e68f18eff9bc",
"Id": "Metrics",
"Name": "Metrics for Power Supply (PSU2)",
"Status": {},
"InputVoltage": {},
"InputCurrentAmps": {},
"InputPowerWatts": {},
"RailVoltage": [],
"RailVoltage@odata.count": 1,
"RailCurrentAmps": [],
"RailCurrentAmps@odata.count": 1,
"OutputPowerWatts": {},
"TemperatureCelsius": {},
"FanSpeedPercent": { <============ In the FanSpeedPercent
"DataSourceUri": "/redfish/v1/chassis/1u/Sensors/116", <==== only 116 sensor can be listed
"Reading": 5550,
"SpeedRPM": 5550
}
}Here is our current FanCollection in ThermalSubsystem{
"@odata.type": "#FanCollection.FanCollection",
"@odata.context": "/redfish/v1/$metadata#FanCollection.FanCollection",
"@odata.id": "/redfish/v1/Chassis/1u/ThermalSubsystem/Fans",
"@odata.etag": "b5a9ef98487eb2d0cb49",
"Name": "Fan Club",
"Members@odata.count": 2,
"Members": [ <============ 2 fans under thermal subsystem
{
"@odata.id": "/redfish/v1/Chassis/1u/ThermalSubsystem/Fans/0"
},
{
"@odata.id": "/redfish/v1/Chassis/1u/ThermalSubsystem/Fans/1"
}
]
}And each Fan data under FanCollection {
"@odata.type": "#Fan.v1_0_0.Fan",
"@odata.context": "/redfish/v1/$metadata#Fan.Fan",
"@odata.id": "/redfish/v1/Chassis/1u/ThermalSubsystem/Fans/0",
"@odata.etag": "beb7fec7caa587f61416",
"Id": "0",
"Name": "PSU2_FAN1-SPEED", <============ both of sensors 116 and 117 are PSU2 fan sensor
"Status": {
"State": "Enabled",
"Health": "OK"
},
"SpeedPercent": { <============ schema FanSpeedPercent
"DataSourceUri": "/redfish/v1/chassis/1u/Sensors/116",
"Reading": 5400,
"SpeedRPM": 5400
}
}{
"@odata.type": "#Fan.v1_0_0.Fan",
"@odata.context": "/redfish/v1/$metadata#Fan.Fan",
"@odata.id": "/redfish/v1/Chassis/1u/ThermalSubsystem/Fans/1",
"@odata.etag": "5976dfeefa0e0206196a",
"Id": "1",
"Name": "PSU2_FAN2-SPEED", <============ both of sensors 116 and 117 are PSU2 fan sensor
"Status": {
"State": "Enabled",
"Health": "OK"
},
"SpeedPercent": { <============ schema FanSpeedPercent
"DataSourceUri": "/redfish/v1/chassis/1u/Sensors/117",
"Reading": 6450,
"SpeedRPM": 6450
}
}Both fans are belong to the same PSU, but now we cannot provide all links to the corresponding fans in PowerSupplyMetrics URI. We need a data structure to describe this architecture in PowerSupplyMetrics, we think there should be an architecture that we could have such as {
"@odata.type": "#PowerSupplyMetrics.v1_0_0.PowerSupplyMetrics",
"@odata.context": "/redfish/v1/$metadata#PowerSupplyMetrics.PowerSupplyMetrics",
"@odata.id": "/redfish/v1/Chassis/1u/PowerSubsystem/PowerSupplies/0/Metrics",
"@odata.etag": "ce0e0b74e68f18eff9bc",
"Id": "Metrics",
"Name": "Metrics for Power Supply (PSU2)",
"Status": {},
"InputVoltage": {},
"InputCurrentAmps": {},
"InputPowerWatts": {},
"RailVoltage": [],
"RailVoltage@odata.count": 1,
"RailCurrentAmps": [],
"RailCurrentAmps@odata.count": 1,
"OutputPowerWatts": {},
"TemperatureCelsius": {},
"FanSpeedPercent": [ <============ an "array" type FanSpeedPercent should be helpful
{
"DataSourceUri": "/redfish/v1/chassis/1u/Sensors/116",
"Reading": 5550,
"SpeedRPM": 5550
},
{
"DataSourceUri": "/redfish/v1/chassis/1u/Sensors/117",
"Reading": 6450,
"SpeedRPM": 6450
}
]
}In current PowerSupplyMetrics schema redfish.dmtf.org/schemas/v1/PowerSupplyMetrics.v1_0_1.json#/definitions/PowerSupplyMetrics"FanSpeedPercent": {
"anyOf": [
{
"$ref": "http://redfish.dmtf.org/schemas/v1/Sensor.json#/definitions/SensorFanExcerpt"
},
{
"type": "null"
}
],
"description": "The fan speed (percent) for this power supply.",
"excerptCopy": "SensorFanExcerpt",
"longDescription": "This property shall contain the fan speed, in percent units, for this resource. The value of the DataSourceUri property, if present, shall reference a resource of type Sensor with the ReadingType property containing the value `Percent`."
}We don't want to make things complex, thus, we wondering if you could add an array property in the current architecture like below? "FanSpeedPercent": {
"anyOf": [
{
"$ref": "http://redfish.dmtf.org/schemas/v1/Sensor.json#/definitions/SensorFanExcerpt"
},
{
"type": "null"
}
],
"description": "The fan speed (percent) for this power supply.",
"excerptCopy": "SensorFanExcerpt",
"longDescription": "This property shall contain the fan speed, in percent units, for this resource. The value of the DataSourceUri property, if present, shall reference a resource of type Sensor with the ReadingType property containing the value `Percent`.",
"type": "array" <============ Adding an "array" property
} |
|
|
|
Post by jautor on Mar 3, 2023 3:31:56 GMT
We can't change the definition to make it an array, as that would break compatibility.
>> We don't want to make things complex, thus, we wondering if you could add an array property in the current architecture like below?
That would be the answer, to add `FanSpeedsPercent` (as an array), which would actually match the same property name in EnvironmentMetrics. And we'd likely deprecate the existing single-fan `FanSpeedPercent` to guide implementations to always use the array.
We'll discuss with the group and get back to you next week about this...
Jeff
|
|
|
|
Post by jautor on Mar 21, 2023 22:02:09 GMT
After discussion, your suggestion to add `FanSpeedsPercent` (as an array) has been approved by the DMTF Redfish Forum, and is intended to be included in the next release of the Redfish Schema bundle (DSP8010).
Thanks for the feedback,
Jeff
|
|
