|
|
Post by AMI_williamlu on Jan 5, 2024 11:12:04 GMT
Want to double check a detail for TaskMonitor. With following steps: 1. POST https://{{ip}}/redfish/v1/UpdateService/upload with required files as requests 2. when it finishes (a successful) update, go GET https://{{ip}}/redfish/v1/TaskService/TaskMonitors/1 We will find the response below which shows a property "error" there.  We had a discussion about it 2~3 years ago (in redfishforum.com/thread/443/response-format-informational-messages-actions?page=1&scrollTo=3432) The discussion mentioned that the reason "error" showing there is due to OData definition. Want to double check if the reason is still the same nowadays, Thanks. Sincerely, William |
|
|
|
Post by mraineri on Jan 5, 2024 13:21:35 GMT
Yes the reasoning is still the same. It's rather unfortunate we have to use "error" here. In hindsight, we should have taken the extra step to define a proper "ReturnType" in CSDL for every action, but by the time we realized this semantic, it was far too late to change this.
|
|
|
|
Post by AMI_williamlu on Jan 10, 2024 16:29:47 GMT
Got it.
Thanks for your reply!
Sincerely
William
|
|
|
|
Post by garyliu on Feb 1, 2024 4:03:03 GMT
Hi mraineri,
According to Redfish v1.15.1 Spec 12.2 Asynchronous operations
If the response 204 from synchronous Action operation completed is reasonable, a task monitor of an asynchronous action response 204 is reasonable too.
In contrast, if an operation is successful, but there is an "error" in the response, it is actually confusing!
|
|
|
|
Post by mraineri on Feb 1, 2024 14:14:04 GMT
Yes, it is confusing. No one likes it, but we're stuck here since changing it would break backwards compatibility.
|
|
|
|
Post by garyliu on Feb 5, 2024 5:57:10 GMT
I also want to make sure that task monitor response 204 is a valid/reasonable response. right?
|
|
|
|
Post by mraineri on Feb 5, 2024 13:44:00 GMT
Yes, you can use 204 in that manner. There's nothing requiring the task monitor to return 200 OK when the operation is complete; it's entirely context driven.
|
|
|
|
Post by ginugeorge on Feb 23, 2024 18:18:15 GMT
Yes, you can use 204 in that manner. There's nothing requiring the task monitor to return 200 OK when the operation is complete; it's entirely context driven. { "error": { "@message.ExtendedInfo": [ { "@odata.type": "#Message.v1_0_8.Message", "Message": "Task /redfish/v1/UpdateService/upload has completed.", "MessageArgs": [ "/redfish/v1/UpdateService/upload" ], "MessageId": "Task.1.0.Completed", "Resolution": "None", "Severity": "OK" }, { "@odata.type": "#Message.v1_0_8.Message", "Message": "Action /redfish/v1/UpdateService/upload firmware update is completed.", "MessageArgs": [ "/redfish/v1/UpdateService/upload" ], "MessageId": "UpdateService.1.0.FirmwareUpdateCompleted", "Resolution": "None", "Severity": "OK" } ], "code": "Base.1.12.Success", "message": "The request completed successfully." } } |
|
|
|
Post by mraineri on Feb 23, 2024 20:50:28 GMT
Yes, 200 OK is definitely preferred since it allows a service to show what devices were updated as a result of the firmware update operation. 204 No Content is allowed though; it just doesn't give the user any information as to what was updated. The Redfish Firmware Update White Paper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf) has examples of this along with recommendations for the standard messages to use.
One thing I noticed is your example uses "UpdateService.1.0.FirmwareUpdateCompleted", which is not part of a standard registry. If this is an OEM message, the "OEM registries" clause of the Redfish Specification has rules for how companies can craft their own message registries to avoid potential conflict with standard registries in the future.
|
|
|
|
Post by garyliu on Feb 26, 2024 7:27:47 GMT
Yes, 200 OK is definitely preferred since it allows a service to show what devices were updated as a result of the firmware update operation. 204 No Content is allowed though; it just doesn't give the user any information as to what was updated. The Redfish Firmware Update White Paper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf) has examples of this along with recommendations for the standard messages to use. One thing I noticed is your example uses "UpdateService.1.0.FirmwareUpdateCompleted", which is not part of a standard registry. If this is an OEM message, the "OEM registries" clause of the Redfish Specification has rules for how companies can craft their own message registries to avoid potential conflict with standard registries in the future. With words on Spec. Your meaning is the response of synchronous operation preferred 200 OK with the payload like ginugeorge posted? |
|
|
|
Post by mraineri on Feb 26, 2024 12:16:59 GMT
Yes, 200 OK is definitely preferred since it allows a service to show what devices were updated as a result of the firmware update operation. 204 No Content is allowed though; it just doesn't give the user any information as to what was updated. The Redfish Firmware Update White Paper (https://www.dmtf.org/sites/default/files/standards/documents/DSP2062_1.0.1.pdf) has examples of this along with recommendations for the standard messages to use. One thing I noticed is your example uses "UpdateService.1.0.FirmwareUpdateCompleted", which is not part of a standard registry. If this is an OEM message, the "OEM registries" clause of the Redfish Specification has rules for how companies can craft their own message registries to avoid potential conflict with standard registries in the future. With words on Spec. What do you mean by this? The headers and response body of the initial operation, as if it had completed synchronously. Your meaning is the response of synchronous operation preferred 200 OK with the payload like ginugeorge posted? Specifically for firmware updates, yes. There are a lot of details that a user may be expecting to be sent by the service as a result of a firmware update. Clients need to know what devices were updated as a result. In many cases, the image sent is a package, and the client doesn't necessarily know specific version or component information in them. For many other actions, 204 No Context works well. For example, if a client invokes a Reset action, there's really no additional information to convey. |
|
