|
Post by michaeldu on Jul 8, 2020 12:17:39 GMT
From my understanding, the response has to be represented in JSON format. If I want to collect some data to a file (basically it is a asynchronous operation), I will start the operation and poll the task monitor, then get the response once it is finished. The response is a URI of the file path. Is it OK to get the file directly? Something like:
Header:
Content-Type :application/octet-stream
Content-Length : 867
Content-Disposition :attachment; filename=test.log
Body:
dfafasdfafafafafdafa dfafafdasafadfadsfa ......
|
|
|
Post by mraineri on Jul 8, 2020 12:29:10 GMT
Currently the only standard place we allow for a non-JSON response is the URI exposed by the BinaryDataURI property in the Assembly resource. The long description specifically calls out the usage of application/octet-stream. You can certainly follow this pattern for OEM properties if you have other use cases you need to solve, or if you think your use cases are common, propose them to the forum. Just keep in mind that these URIs are not for Redfish resources; they are linked from simple string properties that happen to contain a URI. There is also a proposal that has been made to add another similar type of URI to LogEntry for attaching additional data to entries. The proposal for that can be found here: www.dmtf.org/sites/default/files/Redfish_Diagnostic_Data_Logging_Proposal_05-2020-WIP_0.pdf
|
|
|
Post by michaeldu on Jul 9, 2020 12:46:36 GMT
Thanks, Mike. I am still a little confused. Let me elaborate on the example.
1. Call the API /redfish/v1/Systems/1/LogServices/DiagnosticLog/Actions/Oem/LogService.CollectLog, it is an asynchronous operation.
2. It return the task "/redfish/v1/TaskService/Tasks/1" in the "Location" of http header. { "@odata.id": "/redfish/v1/TaskService/Tasks/1/", "@odata.type": "#Task.v1_4_3.Task", "Id": "1", "Description": "Collect Log Task", ...... "Name": "Task", "StartTime": "2020-07-08T13:11:32Z", "TaskMonitor": "/redfish/v1/TaskService/TaskMonitors/1/", "TaskState": "Running" }
3. Poll the TaskState, once it is completed, call the TaskMonitor /redfish/v1/TaskService/TaskMonitors/1 to get the result. There are two alternatives a and b. The question is that "is option b acceptable in Redfish?"
a. { "LogPath":“/redfish/v1/Systems/1/LogServices/DiagnosticLog/Oem/abc/LogURI” }
b. return the log content directly with Http headers as described before.
dfafasdfafafafafdafa dfafafdasafadfadsfa ......
BTW, is task monitor used in the right manner?
|
|
|
Post by mraineri on Jul 9, 2020 14:22:55 GMT
In the case you're describing, you would need to follow option "a". The response to an action will always be a JSON payload. So, as part of that response you'll need to provide a URI to the non-JSON document you're trying to expose.
And for your comment about the usage of task monitor, step 2 needs a slight correction; the "Location" header in the response should contain "/redfish/v1/TaskService/TaskMonitors/1" since that's the task monitor URI.
|
|
|
Post by michaeldu on Jul 10, 2020 3:30:04 GMT
Thanks, got it. For the task monitor, if the the "Location" header contain the "/redfish/v1/TaskService/TaskMonitors/1", what is in the property "TaskMonitor" of "/redfish/v1/TaskService/TaskMonitors/1"? The same resource?
|
|
|
Post by mraineri on Jul 10, 2020 14:12:10 GMT
The "TaskMonitor" property in the Task resource is to expose the Task Monitor URI to an administrator. So, an admin can traverse the Task Collection, and in each Task resource, it can find the Task Monitor URIs. Otherwise the only way to know about the URI is from the response of the original operation from the Location header.
|
|
|
Post by michaeldu on Jul 13, 2020 6:55:41 GMT
Got it, thanks.
|
|