|
|
Post by AMI_Mani on May 31, 2020 17:29:35 GMT
Hi ,
As per Bios.v1_1_0.json, we have below details
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.",
"SettingsObject": {
"@odata.id": "/redfish/v1/Systems/1/Bios/SD"
Based on SettingsObject, use can Patch to SD URI's and Initially there will be no etag for first time and how user can use etag in this scenario
If a client calls PUT or PATCH to update a resource, it should include an ETag from a previous GET in the
HTTP If-Match or If-None-Match header.
Do user needs to mention If-Match as "*" to patch for firs time or implementation needs to skip HTTP 428 status code for this URI for first time?
Please explain for first time and subsequent patch operation after user patching some attributes to SettingsObject w.r.t etag
Once applied to BIOS, etag will get updated and subsequent patch operation need to use this etag or not?
I hope Post is not allowed as per Bios schema(Bios_v1.xml) and no details about post/patch operations in Settings_v1.xml, please confirm whether implementation can allow post which doesn't require etag for first time, second time onward patch can be used, but user will be confused of using both Post, Patch
Thanks,
Mani
|
|
|
|
Post by mraineri on Jun 1, 2020 14:17:50 GMT
I'm not sure I quite understand why there wouldn't be an ETag initially. Even if the settings resource for BIOS has not been touched by the user, the service will still expose the current settings data when a client performs a GET on the settings resource. Based on the data of the settings resource, the service should be providing some sort of ETag for it.
POST is certainly not allowed on this type of resource.
For the first time a client sets data on the resource, I would expect it to treat it like any other resource: perform a GET on the resource to determine the current state, then PATCH the resource for any changes required.
|
|
|
|
Post by AMI_Mani on Jun 1, 2020 18:42:44 GMT
Hi,
Thanks for the details. My assumption is /redfish/v1/Systems/1/Bios/SD will show only the attribute changes requested by user and not all the attributes.
So Initially if user is not requesting any change in attribute means, redfish/v1/Systems/1/Bios, /redfish/v1/Systems/1/Bios/SD will show same attributes.
If both redfish/v1/Systems/Self/Bios, /redfish/v1/Systems/1/Bios/SD has same attributes, then same etag of redfish/v1/Systems/1/Bios can be used for /redfish/v1/Systems/1/Bios/SD, Please confirm
If user patches some attribute /redfish/v1/Systems/1/Bios/SD URI, then we need to show only attributes in get response of /redfish/v1/Systems/1/Bios/SD URI whichever n patched earlier (Not all the attributes), please confirm
Thanks,
Mani
|
|
|
|
Post by mraineri on Jun 1, 2020 19:00:27 GMT
I would expect all attributes to be in there, otherwise the client wouldn't know what they can PATCH when examining the settings resource. It's like any other resource; it would be very confusing to the client to be able to PATCH properties that do not exist in the resource. This becomes even more crucial on settings resources that are used in other places; if properties are not pre-populated in the settings resource, the client has no way of knowing what properties in the resource are controlled by the settings resource.
If no attributes are being modified, then I would expect the "Attributes" property in both the BIOS resource and the BIOS settings resource to be identical.
|
|
|
|
Post by AMI_Mani on Jun 2, 2020 12:22:16 GMT
Thanks for details. Assume 500 attributes available and before user requesting patch
Get request to /redfish/v1/Systems/1/Bios/SD will show all 500 attributes
Then User send patch request to change one attribute, then Get request to /redfish/v1/Systems/1/Bios/SD will show 1 attribute(remaining 499 attributes will not be available in response)
In this case User needs to get attributes supported using /redfish/v1/Systems/1/Bios get response(which will show 500 attributes)
Please confirm whether above use case is correct
Thanks,
Mani
|
|
|
|
Post by mraineri on Jun 2, 2020 15:16:18 GMT
No, you'll still get all 500 attributes on the subsequent GET. Again, if there are properties in the resource that can be PATCHed, they need to be in the response from GET requests. Not showing all of them is not deterministic for the client and is against the general model for all resources.
For your example flow...
1. Client performs GET on the settings resource; 500 attributes are returned.
2. Client performs PATCH on settings resource; 1 attribute is changed.
3. Client performs GET on settings resource; 500 attributes are returned (only one has changed since the first step).
|
|
|
|
Post by AMI_shirleyh on Jun 3, 2020 14:03:12 GMT
Hi Jeff,
Do we have this information on Settings resource anywhere that only GET & PATCH allowed ?
|
|
|
|
Post by mraineri on Jun 3, 2020 15:05:07 GMT
|
|
|
|
Post by AMI_shirleyh on Jun 4, 2020 19:48:52 GMT
Jeff,
I also have a concern here. If there is no future settings set by the user, why do we need to return current settings in the GET method of Bios/SD URI?
So I think User can POST data for first time to Bios/SD to let all other people know that some settings are available to apply.
If any other user or the same user wants to modify he can with the help of PATCH.
If no data is set by the user then GET Bios/SD should return 404 so that it is easier for identification for all users as well as BIOS to know that no new settings need to be applied.
Let me know your views on this.
|
|
|
|
Post by mraineri on Jun 8, 2020 12:40:45 GMT
It's largely because the client otherwise has no indication of what they're allowed to set. Bios is fairly unique in that it's likely going to be everything in "Attributes", but for other resources, different systems have different architectures where different properties are going to be governed by the settings resource. I don't see how returning an error is helpful for the client when nothing is set. From a client's perspective, all that it would care about is what the properties will change to when the settings are applied. The general workflow for the settings resource is no different than any other resource:
1) The client performs a GET on a resource.
2) The client makes decisions based on the state of the resource.
3) If needed, the client performs a PATCH on the resource to set the resource to the desired state.
|
|
|
|
Post by AMI_shirleyh on Oct 18, 2022 7:24:51 GMT
Hi, According to the Redfish Specification : www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.15.1.pdf , Can you please help us to clarify how the behavior should change from what you mentioned in the above comment : "The settings resource should contain a subset of updatable properties from the active resource. Additionally, it shall contain required properties, which are always mandatory." According to the "Table 23 — Active resource and settings resource property behavior" under Settings Resource Section 9.10. It seems, "Future value returned in the settings resource response to a GET request if a future value is pending, otherwise not returned. Modification requests change the future value." Conclusion Case 1: "GET to Settings resource should return only the writable properties that has been patched by the User along with readonly mandatory properties." Case 2: "GET to Settings resource should return all the writable properties that can be applied in future (patched by the User + not patched values) along with readonly mandatory properties." Please tell me which Case correctly implies what has been given in the SPEC. Correct me if I'm wrong. |
|
|
|
Post by mraineri on Oct 20, 2022 20:18:07 GMT
It really depends if the resource has a mix of properties that can only be PATCHed in the settings resource and properties that can be both PATCHed on the active resource and in the settings resource.
Specifically for the Bios resource, I'm not aware of any implementations that support PATCH to properties in the active resource. Thus, everything in Bios that can be modified and applied at a future point in time would appear in the settings resource, which would map to case 2 fairly easily.
However, other resources could have a mix of behavior. The common case I've seen is on EthernetInterface where the MAC address can only be modified in the settings resource, but other properties can be modified in both resources (like static IP address settings). So, in these cases, I would expect the MAC address to always be shown in the settings resource, but IP address settings would only appear in the settings resource if a user had previously PATCHed the resource with a request to apply new IP addresses on the next reboot.
|
|
|
|
Post by AMI_Mani on Oct 21, 2022 17:16:08 GMT
Thanks for the reply
If we are allowed to patch only setting resource, then we have to show all attributes(patched by user , unchanged attributes from active resource) as case 2, exaple below
1. Client performs GET on the settings resource; 500 attributes are returned.
2. Client performs PATCH on settings resource; 1 attribute is changed.
3. Client performs GET on settings resource; 500 attributes are returned (only one has changed since the first step).
As per section 9.10 Settings resource, it is suggested not to return read only not required properties in Settings resource behavior
Assume already we are returning AttributeRegistry, Description, @odata.context, @odata.etag in get response of Settings resource, can we keep that as it and hope it will not break compliance as per Table 23 — Active resource and settings resource property behavior in Redfish specification. This will be useful for user to see AttributeRegistry in Settings resource itself, else user needs to request get Active resource and then go to AttributeRegistry
Even mockup data(https://redfish.dmtf.org/redfish/mockups/v1/1206) also returning read only not required properties in Settings resource, please confirm of keeping read only not required properties in Settings resource get response
Thanks,
Mani
|
|
|
|
Post by jautor on Oct 21, 2022 18:49:57 GMT
Correct. The suggestion to not return read-only properties is to avoid confusion between properties that can be modified using the Settings resource, and those that are modified using PATCH in the parent resource. But this is really targeted at read-write properties that become read-only in the Settings resource (or that are always read-only in the implementation, but defined as read-write in schema). Properties that are defined as read-only in schema shouldn't cause that confusion - and yes, especially for the BIOS resource, represent just a few structural "overhead" properties anyway.
Jeff
|
|
|
|
Post by AMI_Mani on Oct 22, 2022 2:54:08 GMT
Hi Jeff,
Thanks for your reply and i'm clear now
If a property is read-write in active resource(not supported to patch from settings resource) and user can patch to change value in active resource itself, so we should not return these attributs. Since we are mentioning read only attribute in general in section 9.10 Settings resource T(able 23 — Active resource and settings resource property behavior in Redfish specification), it's confusing between actual read-only attribute in schema. If possible please add some more details in section 9.10 Settings resource to avoid this confusion
Thanks,
Mani
|
|
