|
|
Post by jjsalzano on Jan 3, 2024 18:18:21 GMT
|
|
|
|
Post by mraineri on Jan 5, 2024 20:09:55 GMT
Today we cannot express BIOS attributes as arrays or objects; we only support numbers, booleans, and strings.
The Redfish Bios resource was intended to surface the most common types of things a user might want to change in their typical F2 menu and is not necessarily fully comprehensive of all UEFI HII attributes. Do you have a need to support arrays or objects? Other folks have given guidance in the past, for arrays at least, to do something along the lines of "SomeSetting0", "SomeSetting1", "SomeSetting2", and so on instead of using an array.
|
|
|
|
Post by jjsalzano on Jan 5, 2024 20:40:53 GMT
Hey Mike,
Thanks for clarifying.
So we only have 1 setting that is order based but it is probably one of the more important ones we expose, which is the Boot Order. We might have to change it next release to conform better as we are exposing it as an array currently.
The setting0,1,2 could work for us, so could multiple line strings, we just need to make sure we are not going off and doing something crazy different than what others were. Dell doesn't use order based at all I am guessing?
Joseph
|
|
|
|
Post by mraineri on Jan 6, 2024 1:30:31 GMT
We do have it exposed as a singular Bios attribute where it's a comma-separated list so that it can convey an array, but using a single string. That's another option if you really need to show something as an ordered array, but require it being a single attribute.
However, specific with the the boot order, there is a standard Redfish property in the ComputerSystem resource for controlling the boot order. Inside of the "Boot" object, there is the "BootOptions" property, which contains a link to a collection of the possible boot sources, and the "BootOrder" property, which is an array showing the configured boot order of the system. It's recommended that if a client wants to modify the boot order, they should PATCH the BootOrder property in the settings resource for the system. This might be worth considering since it's much more interoperable than requiring a client to set this in the Bios resource where every attribute is vendor-defined.
|
|
|
|
Post by AMI_Mani on Feb 15, 2024 16:55:13 GMT
We have below information for Boot order redfish.dmtf.org/schemas/v1/ComputerSystem.v1_22_0.json"BootOrder": { "description": "An array of BootOptionReference strings that represent the persistent boot order for with this computer system. Changes to the boot order 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 boot order settings by modifying the resource identified by the `@redfish.Settings` term.", "items": { "type": [ "string", "null" ] }, BootOrder attribute is patchable(readonly false).why we need to use @redfish.Settings like /redfish/v1/Systems/{Systems_Instance}/SD to change boot order?. In this case readonly can be changed to true. In redfish.dmtf.org/schemas/v1/ComputerSystem.v1_16_0.json, definition as below "BootOrder": { "description": "An array of BootOptionReference strings that represent the persistent boot order for with this computer system.", "items": { "type": [ "string", "null" ] }, Are we allowing patch in BootOrder of /redfish/v1/Systems/{Systems_Instance} due to earlier schema, please confirm Thanks, Mani |
|
|
|
Post by mraineri on Feb 15, 2024 17:41:55 GMT
Because the settings resource definition inherit from the resource in question. So, if ComputerSystem did not contain read-write for the property, then a client would not be able to modify the property in the respective settings resource. Keep in mind the settings resource construct is generic in nature and this applies to every other usage of it. It can get even more complicated where you do have a mix of capabilities in these properties where it's possible to PATCH the same property in both the active resource and the settings resource. We have a lot of these behaviors described in the "Settings resource" clause of the Redfish Specification.
However, specific to the BootOrder property, the reason there's guidance to use a settings resource in this case is because on the vast majority of system architectures that exist today, it's simply not possible to change the boot order on the fly. UEFI needs to come back up, see the settings request, process it, and either apply it or reject it. In theory there could be some behind the scenes magic to modify UEFI's persistent storage to directly apply the new boot order without the need for UEFI to come back up and process the request; however I have never seen this capability in practice.
|
|
