Clarifications related to Task Monitor

A "task monitor" is closely tied to a single task instance. It's the handle a client gets when it invokes a long running operation, and is also the handle the client uses to get the final status of the operation.


task_monitor_uri = response.headers.location
while(response.http_status == 202) {
response = http_get(task_monitor_uri)
}

// Process final response
...

Hi Mike,

I want to determine if this code is intended to represent what the spec says:



So if I use another expression it should be something like Step 3, right?

Yes, the Location header contains the URI of the task monitor. However, in your example, the URI is identical to the Task resource. The Task resource URI and task monitor URI are two different URIs with different behavioral semantics.

Hi Mike,
Can we add more details about Task monitor in specification or in schema?

We have below details in Schema and no further details of TaskMonitor resource in Specification(like URI, attributes etc)

"TaskMonitor": {
"description": "The URI of the Task Monitor for this task.",
"format": "uri-reference",
"longDescription": "This property shall contain a URI to Task Monitor as defined in the Redfish Specification.",
"readonly": true,
"type": "string",
"versionAdded": "v1_2_0"
},

Please make sure Task Monitor as mandatory attribute in Taskresource schema(http://redfish.dmtf.org/schemas/v1/Task.v1_5_1.json) so that there won't be any conflict
Basically Task monitor is used to represent the response of resource after long-running operation completes and there is no standard schema for task monitor as of now

I have already replied related to schema in redfishforum.com/thread/340/redfish-service-validator-related-instance?page=1&scrollTo=2310

Can we think possibility of using Task resource itself instead of bringing task monitor?  Initially we used Task instance only and later Task monitor was introduced but we need more details like schema, clean up(policy) etc. to use properly if we need to use mandatory. Copied earlier specification details for reference

202

Accepted


The request has been accepted for processing, but the processing has not been

completed. The Location header shall be set to the URI of a Task resource that

can later be queried to determine the status of the operation. A representation of

the Task resource may be included in the response body.

Thanks,
Mani
 

Thanks for details. I got your point related to TaskMonitor" property is not mandatory in the Task resource; think of cases where a task is complete, but the monitor is no longer available

Can we make taskmonitor value as null once task is complete, so that task monitor always comes in response?

Thanks,
Mani

Hi Mike,
We have below details in specification

If an implementation supports a property, it shall always provide a value for that property. If a value is unknown

at the time of the operation due to an internal error, or inaccessibility of the data, the value of null is an

acceptable value if supported by the schema definition.

Based on above details,  can we expect Taskmonitor always comes in response or we have to follow 9.11 Special resource situations , omit the Taskmonitor once task completed

Another clarification

    1. Do we need to provide Taskmonitor Instance response(Once task is completed and return actual response) always for user irrespective of current state? Assume current state has different values and when they check Taskmonitor Instance response(Assume task complete long back). Another option is to show response only once after completed and then delete that Taskmonitor Instance response
    2. Do we need to provide options like Delete method for Taskmonitor Instance so that user can clean up completed task or needs to apply policy to delete old ones automatically?

Thanks,
Mani