Post by malbolge on May 22, 2020 7:45:42 GMT
Suppose we have a Redfish device that allows configuration of properties with varying apply times. Some properties can take effect immediately, some require a device reset.
In the event that a Redfish property write cannot take effect immediately, a @redfish.Settings () object must be used to proxy these settings. This object represents the pending configuration status of the Redfish device. The use of Settings objects is not very well defined. From the DMTF website, BIOS schema description, one of the few places explaining Settings Object usage:
To achieve pending setting support, two elements are required.
First, a Redfish Resource is appended with a @redfish.Settings object. This is how it looks like in the DMTF Mockup for BIOS:
redfish.dmtf.org/redfish/mockups/v1/949#Systems--437XR1138R2--Bios
Secondly, a separate Redfish Resource is created. This Resource is derived from the base schema and represents the state of the Redfish device as it will appear after the appropriate application time trigger occurs - a reset or such. This Resource omits RO and volatile properties.
redfish.dmtf.org/redfish/mockups/v1/949#Systems--437XR1138R2--Bios--Settings
My understanding is that:
1) If a Redfish Resource contains at least one writeable property which requires delayed application, this (base) Redfish Resource must contain a @redfish.Settings object.
2) This @redfish.Settings object links to a new Redfish Resource, representing the pending state of the base Redfish Object.
3) All writes to the base Redfish Resource are disallowed, all writes must target the Redfish Setting Resource
4) The optional parameter ApplicationTime, residing in @redfish.Settings of the base Resource, defines the time at which the pending settings will be applied
The problem is that the @redfish.Settings object defines a singular shared application time for all pending properties. The consequence of all of the above is that:
1) If a single property within a Resource requires a reset to apply, then ALL property writes must be delayed to that moment, because they must conform to the Settings mechanism of shared application time.
2) Even if the Redfish device applied all Settings Resource viable properties immediately, that would apparently violate the ApplyTime specified in the @redfish.Settings Object.
My question is, having said all that, how should the trio of the Base Redfish Resource, the @redfish.Settings Object it contains and the Base-derived Settings Resource interact to sensibly permit mixed application time configuration changes?
In the event that a Redfish property write cannot take effect immediately, a @redfish.Settings () object must be used to proxy these settings. This object represents the pending configuration status of the Redfish device. The use of Settings objects is not very well defined. From the DMTF website, BIOS schema description, one of the few places explaining Settings Object usage:
The Bios schema contains properties related to the BIOS Attribute Registry. The Attribute Registry describes the system-specific BIOS attributes and actions for changing to BIOS settings. Changes to the BIOS typically require a system reset before they take effect. It is likely that a client finds the `@redfish.Settings` term in this Resource, and if it is found, the client makes requests to change BIOS settings by modifying the Resource identified by the `@redfish.Settings` term.
To achieve pending setting support, two elements are required.
First, a Redfish Resource is appended with a @redfish.Settings object. This is how it looks like in the DMTF Mockup for BIOS:
"@Redfish.Settings":view details {
"@odata.type":view details "#Settings.v1_3_0.Settings",
"ETag":view details "9234ac83b9700123cc32",
collapse"Messages":view details [
{
"MessageId":view details "Base.1.0.SettingsFailed",
collapse"RelatedProperties":view details [
"#/Attributes/ProcTurboMode"
]
}
],
"SettingsObject":view details {
"@odata.id":view details "/redfish/v1/Systems/437XR1138R2/Bios/Settings"go to this resource} ,
"Time":view details "2016-03-07T14:44.30-05:00"} ,redfish.dmtf.org/redfish/mockups/v1/949#Systems--437XR1138R2--Bios
Secondly, a separate Redfish Resource is created. This Resource is derived from the base schema and represents the state of the Redfish device as it will appear after the appropriate application time trigger occurs - a reset or such. This Resource omits RO and volatile properties.
redfish.dmtf.org/redfish/mockups/v1/949#Systems--437XR1138R2--Bios--Settings
My understanding is that:
1) If a Redfish Resource contains at least one writeable property which requires delayed application, this (base) Redfish Resource must contain a @redfish.Settings object.
2) This @redfish.Settings object links to a new Redfish Resource, representing the pending state of the base Redfish Object.
3) All writes to the base Redfish Resource are disallowed, all writes must target the Redfish Setting Resource
4) The optional parameter ApplicationTime, residing in @redfish.Settings of the base Resource, defines the time at which the pending settings will be applied
The problem is that the @redfish.Settings object defines a singular shared application time for all pending properties. The consequence of all of the above is that:
1) If a single property within a Resource requires a reset to apply, then ALL property writes must be delayed to that moment, because they must conform to the Settings mechanism of shared application time.
2) Even if the Redfish device applied all Settings Resource viable properties immediately, that would apparently violate the ApplyTime specified in the @redfish.Settings Object.
My question is, having said all that, how should the trio of the Base Redfish Resource, the @redfish.Settings Object it contains and the Base-derived Settings Resource interact to sensibly permit mixed application time configuration changes?
