|
Post by puwen on Sept 23, 2022 2:15:48 GMT
Hi,
Does anyone know why the Chassis/ComputerSystem has its own definition of PowerState? Why not just refer to PowerState of Resource.json? Thanks for your answer.
For example:
Chassis Schema
"PowerState": {
"enum": [
"On",
"Off",
"PoweringOn",
"PoweringOff"
],
"enumDescriptions": {
"Off": "The components within the chassis have no power, except some components might continue to have AUX power, such as the management controller.",
"On": "The components within the chassis have power.",
"PoweringOff": "A temporary state between on and off. The components within the chassis can take time to process the power off action.",
"PoweringOn": "A temporary state between off and on. The components within the chassis can take time to process the power on action."
},
"type": "string"
},
Circuit Schema "PowerState": {
"anyOf": [
{
"$ref": "http://redfish.dmtf.org/schemas/v1/Resource.json#/definitions/PowerState"
},
{
"type": "null"
}
],
|
|
|
Post by mraineri on Sept 23, 2022 13:31:48 GMT
Back when Redfish was first released, the usage of power state was fairly limited, so Chassis and ComputerSystem had their own enum for it. However, now that that data model has grown to support various power equipment (like rack PDUs), several new resources have been added that also needed a power state. At that time we made a common PowerState enum, but haven't seen the need to redirect Chassis and ComputerSystem to use the common enum.
|
|
|
Post by puwen on Sept 23, 2022 17:02:59 GMT
Hi Mike,
Thanks for your answer, but I found that "Pause" Reset Type was added in Resource v1.13. And description of "Pause" is: "This value shall indicate the resource will transition to a paused state. Upon successful completion, the PowerState property, if supported, shall contain the value `Paused`.",
Then I checked ComputerSystem v1.18 and "Pasued" is not listed in the enum list of PowerState. So I think the ComputerSystem/Chassis schema need to be updated for this, right?
|
|
|
Post by mraineri on Sept 23, 2022 18:40:40 GMT
Good catch; we'll need to look at this more, but I suspect you're correct.
|
|