|
|
Post by pgibbons on Oct 22, 2021 4:04:29 GMT
I am wondering about the intended behavior of the BIOS attribute registry resource. My first thought was that this resource would be static, not changing with system state. However, it appears to be the only place that many properties of the attributes are listed, and as such, if one wants to query the current value of one of the properties, e.g. ReadOnly, that would need to come from this registry. As the dependencies indicate, the state of the system may alter the current value of a property such as ReadOnly. This leads me to believe that my initial assumption was wrong, and that the registry properties should reflect the actual state of the system at the time the registry resource is read. Is this the intention?
|
|
|
|
Post by mraineri on Oct 22, 2021 13:31:36 GMT
The attribute registry is expected to be static. There is a separate resource to convey what the current state of the system is (the Bios resource). Essentially the AttributeRegistry resource is the static decoder ring that allows clients to understand the attributes supported by the system, their values, and other constraints for the attributes. Using this information, a client is able to apply requests to the Bios resource (found at /redfish/v1/Systems/{SystemId}/Bios) to change attributes on the system, or just check their values. There is a YouTube video about configuring BIOS settings via Redfish here: www.youtube.com/watch?v=yVEl_amDWHI |
|
|
|
Post by pgibbons on Oct 22, 2021 13:56:34 GMT
Thanks for the reply. The issue I have with that is that the BIOS resource doesn't convey the current state of all the attribute properties in the registry, it only shows the (AttributeName: CurrentValue) pair in the "Attributes" resource of BIOS. For example, if I have an attribute as such
"AttributeName": "FeatureExample",
"ReadOnly": false
That declared value of ReadOnly is really only the default value of that property, so to speak. For example, if I declare the following dependency, then FeatureExample.ReadOnly will change when OtherFeature.CurrentValue is changed from "":
{
"DependencyFor": "FeatureExample",
"Type": "Map",
"Dependency": {
"MapFrom": [
{
"MapFromAttribute": "OtherFeature",
"MapFromProperty": "CurrentValue",
"MapFromCondition": "NEQ",
"MapFromValue": ""
}
],
"MapToAttribute": "FeatureExample",
"MapToProperty": "ReadOnly",
"MapToValue": "True"
}
}
After this mapping has occurred, the information in the attribute registry listed for FeatureExample.ReadOnly is no longer correct. It is true that the client can trace the dependencies and know what happened, in theory at least. However, I don't believe that is really sufficient for actual use; at least my manageability marketing colleagues tell me that it isn't. While the admin wants to have the dependencies declared so they can predict how attributes interact, they won't want to have to play out the dependencies and try to predict what the current state of all the attribute properties are.
If I have missed some resource that conveys the information I want, please inform me of that.
|
|
|
|
Post by mraineri on Oct 22, 2021 16:28:58 GMT
It's possible for a service to return a message stating this dependency in response to a PATCH request to modify the attribute, but this might not be something simple implementations would be able to inspect ahead of time. The simple services might just cache the request, and won't be able to report these sorts of failures until BIOS reads out the requested settings on the next reboot.
However, you're right in that this does put a burden on the client to understand why they cannot change FeatureExample; they need to inspect the registry to see that FeatureExample is read-only because OtherFeature is not "", or hopefully rely on messages from the service to indicate the dependency issue.
Generally speaking, the history of the AttributeRegistry and Bios resources have been rooted in requests from UEFI folks to surface F2 menu items via Redfish. Unfortunately due to the complexities of how HII attributes are defined, you're very much going to hit dependency inspection problems like you've described. I don't have a great solution, and given the history of how OEM-defined these attributes are, I don't expect to see fantastic interoperability beyond the underlying mechanics of presenting attributes and showing the HII definitions that explain the attributes. Folks to date have generally accepted this shortcoming and rely on vendor tools or intimate knowledge of the system to manage these things.
But we do encourage those who attempt to manage attributes to bring forth their use cases so we can add well-defined properties in the model so that the Bios resource can be avoided altogether.
|
|
|
|
Post by jautor on Oct 22, 2021 16:39:54 GMT
As Mike stated, this is all absolutely due to the BIOS resource and AttributeRegistry concepts attempting to layer a REST interface on top of existing BIOS/UEFI methods that have been around for decades.
If there's something that you expect a user to interact with, especially a read-write property, creating a real Redfish property for that, either in an OEM resource, or contributing it to the standard schemas, is the "right answer".
Jeff
|
|
|
|
Post by shawnw on Mar 21, 2024 10:42:50 GMT
Hi
Just wanna to quick check about the the SettingsObject.
If the /systems/{SystemId}/Bios has a SettingsObject
```
{
"@redfish.Settings": {
"@odata.type": "#Settings.v1_3_3.Settings",
"SettingsObject":
{
"@odata.id": "/redfish/v1/Systems/1/Bios/SD"
},
},
...
}
```
1. Should /redfish/v1/Systems/1/Bios/SD contain `Attributes` object in it, which is used for chagned the value of the attributs.
2. Meanwhile, the /redfish/v1/Systems/1/Bios should not be modified. All changes in the future should be PATCHing to /redfish/v1/Systems/1/Bios/SD, right?
Many Thanks,
Shawn
|
|
|
|
Post by mraineri on Mar 21, 2024 12:56:57 GMT
1) Yes.
2) Yes. I would expect /redfish/v1/Systems/1/Bios to be updated when the system resets though and BIOS has taken the new settings.
The "Settings resource" clause should describe all of these behaviors for that to populate in the settings resource and when the active resource is updated.
|
|
|
|
Post by shawnw on Mar 22, 2024 0:40:05 GMT
Thanks for the quick reply.  |
|
|
|
Post by shawnw on Mar 28, 2024 7:16:14 GMT
1) Yes. 2) Yes. I would expect /redfish/v1/Systems/1/Bios to be updated when the system resets though and BIOS has taken the new settings. The "Settings resource" clause should describe all of these behaviors for that to populate in the settings resource and when the active resource is updated. During the implementation, still have a question and need your advice. In /redfish/v1/Systems/1/Bios, let's assume that all properties under the Attributes property are both updatable and mandatory.  My question pertains to the "Settings resource" clause, which states, "The settings resource should contain a subset of the updatable properties from the active resource." I'm uncertain about how to display the contents of Attributes in redfish/v1/Systems/1/Bios/SD. Case 1: Display all information within it, allowing users to update any property they desire. ![]()  Case 2: Only display properties that are pending updates. To achieve this, the user would need to check the attributes in redfish/v1/Systems/1/Bios and then PATCH them in redfish/v1/Systems/1/Bios/SD.  I look forward to your advice. Many Thanks, Shawn |
|
|
|
Post by mraineri on Mar 28, 2024 17:46:16 GMT
If your implementation supports PATCHing the attribute in the active resource directly (as in you can make on-the-fly BIOS attribute updates without a system reboot) and you can also support staging the attribute to be staged for the next reboot, then that falls into the "Writable, updates immediately or at a future point in time.". This means you omit the attribute from GET responses for the settings resource unless there is a pending change. So, it would map to case 2.
However, specifically for BIOS attributes, I have not seen the capability to modify attributes without a reboot in a real product; the implementations I've seen always map this to the "Writable, updates at a future point in time, but not immediately." row in that clause. So, I'd be cautious about this to ensure you really do have that support in your product.
|
|
|
|
Post by shawnw on Mar 28, 2024 20:57:56 GMT
Thanks mraineri for the detailed reply.
Yes, our product doesn’t have the capability to update bios setting on a fly. All the attributes should not be omitted from the beginning. A user can only modify it in with the setting resource only. Attributes not modified by users also represent future values.
Appreciate it!
|
|
