|
|
Post by AMI_Mani on Feb 6, 2023 14:28:03 GMT
Hi, Based on redfish.dmtf.org/schemas/v1/ComputerSystem.v1_20_0.json, BootSourceOverrideMode supports two values "BootSourceOverrideMode": { "enum": [ "Legacy", "UEFI" ], "enumDescriptions": { "Legacy": "The system boots in non-UEFI boot mode to the boot source override target.", "UEFI": "The system boots in UEFI boot mode to the boot source override target." }, "type": "string" In some servers Legacy is not supported, so we can remove Legacy and keep UEFI enum value alone in BootSourceOverrideMode attriute or remove BootSourceOverrideMode attribute from Patch request(not to validate) and use UEFI value internally. Get response of Systems Instance will show as "BootSourceOverrideMode": "UEFI" Some old servers may support Legacy and I hope we need to keep Legacy enum value in schema and implementation can remove Legacy based on server support internally Thanks, Mani |
|
|
|
Post by mraineri on Feb 6, 2023 17:50:57 GMT
Removing support for the "Legacy" value would be preferred for the sake of transparency with the client. Silently removing the property from the PATCH request doesn't really meet the requirements of the specification. Two ways to approach this:
1) Make the property read-only where it's always UEFI; a user PATCHing this property would get an error saying it's read-only.
2) Keep the property writable, but don't support the "Legacy" value; a user PATCHing this property with a value other than UEFI would get an error saying the value is unsupported.
I think option 2 would be the least problematic for clients since it's reasonable to expect users to set this to UEFI in their PATCH requests.
|
|
|
|
Post by shawn on Feb 7, 2023 1:22:52 GMT
1) Make the property read-only where it's always UEFI; a user PATCHing this property would get an error saying it's read-only. , I'm curious about option 1. According to the defintion of BootSourceOverrideMode in ComputerSystem.v1_20_0.json, it should be readwrite property since "readonly" is false.
"BootSourceOverrideMode": {
"anyOf": [
{
"$ref": "#/definitions/BootSourceOverrideMode"
},
{
"type": "null"
}
],
"description": "The BIOS boot mode to use when the system boots from the BootSourceOverrideTarget boot source.",
"longDescription": "This property shall contain the BIOS boot mode to use when the system boots from the BootSourceOverrideTarget boot source.",
"readonly": false,
"versionAdded": "v1_1_0"
}
Is it ok for a implementation to change a readwrite property to be an readonly property? For option 2, i think it's fine since the implementation does support to patch the property but not all of values in a list, isn't it? Just wonder which option is acceptable so that we can follow the same rules.  Many Thanks, Shawn |
|
|
|
Post by mraineri on Feb 7, 2023 2:11:19 GMT
For option 1... Yes, implementations are allowed to make writable properties read-only. Like the majority of the Redfish model, you don't need to implement everything (including write support for a property marked as writable in the standard). We have this statement in the "Properties" clause of the specification: "A service may implement a writable property as read-only." If allowing a user to PATCH a property marked as writable doesn't make sense for your product, then make it read-only; however, keep in mind some clients may always choose to PATCH a particular property, so you may want to keep this in mind when making a property read-only. For option 2... Yes, like with option 1, implementations have no obligation to support the full list of values in a property. The standard is a super-set of everything possible, and if a particular value doesn't make sense for your product, then do not support the value. This is why the "<Property>@redfish.AllowableValues" term is used; it's so a service can convey what values a client is allowed to use in PATCH requests for the property. |
|
|
|
Post by shawn on Feb 7, 2023 2:34:40 GMT
Got it! Thanks for the detail explanation. |
|
|
|
Post by AMI_Mani on Feb 7, 2023 10:22:39 GMT
For option 1... Yes, implementations are allowed to make writable properties read-only. Like the majority of the Redfish model, you don't need to implement everything (including write support for a property marked as writable in the standard). We have this statement in the "Properties" clause of the specification: "A service may implement a writable property as read-only." If allowing a user to PATCH a property marked as writable doesn't make sense for your product, then make it read-only; however, keep in mind some clients may always choose to PATCH a particular property, so you may want to keep this in mind when making a property read-only. For option 2... Yes, like with option 1, implementations have no obligation to support the full list of values in a property. The standard is a super-set of everything possible, and if a particular value doesn't make sense for your product, then do not support the value. This is why the "<Property>@redfish.AllowableValues" term is used; it's so a service can convey what values a client is allowed to use in PATCH requests for the property. Thanks for details. For option 1 standard schema will mention as read write, in implementation we will change to readonly. Once the client gives patch request for that attribute, it will see the error message as read only. Is it allowed to modify standard schema and keep under service implementation for client reference or client will know read only after patch response or any other way for the client to know it's readonly(deviated from standard schema) Thanks, Mani |
|
|
|
Post by mraineri on Feb 7, 2023 13:31:59 GMT
Yes, under the "Schema modification rules" clause of the specification, you are allowed to edit local copies of schema to change the permissions of a property from read-write to read-only (but it is NOT allowed to change a read-only property to make it read-write).
|
|
