|
Post by AMI_Mani on Aug 3, 2022 17:46:38 GMT
Hi, As per 2020.4 schema, power schema depcrecated with below information
Three schemas have been replaced by new definitions, with the
existing schemas deprecated in this release
• Power – replaced by PowerSubsystem, PowerSupply,
PowerSupplyMetrics, and EnvironmentMetrics
• Thermal – replaced by ThermalSubsystem, Fan, and EnvironmentMetrics
Powercontrol object has below attributes
"@odata.type": "#Power.v1_7_1.Power",
"Id": "Power",
"Name": "Power",
"PowerControl": [
{
"@odata.id": "/redfish/v1/Chassis/1U/Power#/PowerControl/0",
"MemberId": "0",
"Name": "Server Power Control",
"PowerConsumedWatts": 344,
"PowerRequestedWatts": 800,
"PowerAvailableWatts": 0,
"PowerCapacityWatts": 800,
"PowerAllocatedWatts": 800,
"PowerMetrics": {
"IntervalInMin": 30,
"MinConsumedWatts": 271,
"MaxConsumedWatts": 489,
"AverageConsumedWatts": 319
},
"PowerLimit": {
"LimitInWatts": 500,
"LimitException": "LogEventOnly",
"CorrectionInMs": 50
},
"RelatedItem": [
{
"@odata.id": "/redfish/v1/Systems/437XR1138R2"
},
{
"@odata.id": "/redfish/v1/Chassis/1U"
}
]
Unable to map all above attributes in PowerSupply,PowerSupplyMetrics. Checked DSP2046_2022.1.pdf, DSP0268_2022.1.pdf, DSP2053_2022.1.pdf and there is no details of deprecating above properties with new properties. We have clear information for ConsumedPowerWatt (deprecated v1.2) and mentioned This property
has been deprecated in favor of the properties in EnvironmentMetrics in DSP0268_2022.1.pdf. Do we have similar information or mapping to new attribute for Power control, Power limit, Power metrics inside power resource(/redfish/v1/Chassis/1U/Power#/PowerControl/0)
Thanks, Mani
|
|
|
Post by jautor on Aug 3, 2022 18:36:01 GMT
From the Redfish Release 2020.4 overview presentation (https://www.dmtf.org/sites/default/files/Redfish_Release_2020.4_Overview.pdf), there's a summary slide that shows the migration at the object level - I've attached that slide. Hopefully that will answer most of the questions... The contents of the "PowerControl" object do get split up a bit, with the details going to the Sensor resource that provides the power Reading you would show in an EnvironmentMetrics resource for whatever that power measurement is actually measuring (Chassis, Processor, Memory, etc.). The last portion of the migration was completed in 2021.2, with the addition of the "Control" schema that surfaces the "PowerLimitWatts" properties, again in the EnvironmentMetrics for whatever that limit applies to. The "Rack Mount Server" mockup on the Redfish Developer Hub shows the "before and after" of this migration as well, including PowerLimitWatts. That may help explain things... redfish.dmtf.org/redfish/mockups/v1/1146Hope that helps, Jeff Attachments:
|
|
|
Post by AMI_Mani on Aug 5, 2022 14:30:54 GMT
Thanks Jeff. I'm able to map with attributes from PowerControl with attributes in /redfish/v1/Chassis/{ChassisId}/PowerSubsystem, /redfish/v1/Chassis/{ChassisId}/Sensors/{SensorId}, /redfish/v1/Chassis/{ChassisId}, /redfish/v1/Chassis/{ChassisId}/Controls/{ControlId} I'm unable to find equivalent attribute for LimitException, CorrectionInMs in new schema. I feel LimitException needs to be supported and unable to find any other equivalent attribute in 2022.1 schema
"PowerLimit": {
"LimitException": "LogEventOnly",
"CorrectionInMs": 50
}, Also PowerConsumedWatts is not directly available, do we need to use Apparent energy (kVAh) from /redfish/v1/Chassis/{ChassisId}/EnvironmentMetrics? Please add your input about these 3 attributes
Thanks, Mani
|
|
|
Post by mraineri on Aug 5, 2022 19:18:14 GMT
In EnvironmentMetrics, you use "PowerWatts" to show the power consumption of the chassis (or device when EnvironmentMetrics is beneath a resource like Drive or Processor).
The reason "LimitException" and "CorrectionInMs" specifically were not migrated was because we have not seen end-user use cases to support the need anymore. There is a WIP publication for a "Policy" proposal to control behavior for what actions are taken when different conditions are met, but to date we have not received much feedback to bring it forward as a standard. This may be the replacement path in the future, but we haven't seen a strong need from users for it.
|
|