Redfish Service Validator Issue related to Task Instance

ginugeorge
Minnow

Posts: 29

Redfish Service Validator Issue related to Task Instance Jun 22, 2020 12:54:53 GMT

Quote

Post by ginugeorge on Jun 22, 2020 12:54:53 GMT

I am using github.com/DMTF/Redfish-Service-Validator to validate redfish service if it is in adherence with the schema.

But I am facing an error as mentioned below:

For the Task Collection URI /redfish/v1/TaskService/Tasks , there are four instances or members under it and for one particular instance, when a GET request is issued by the validator, the validator throws the below error -

ERROR - Members[2]: GET of resource at URI /redfish/v1/TaskService/Tasks/2 returned HTTP 202. Check URI.

But as per the DMTF Specification in the link below :

www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.8.0.pdf

• The Task Monitor is used by the Client to get the Response Body of the actual operation.

• If the operation has been accepted for processing, a 202 can be returned. This mean a Task has been started to complete the request.
• The “Location” header is set to the URI of a Task Monitor.
• There may also be a “Retry-After” header to specify the amount of time the client should wait before querying the Task Monitor

• When the operation is finished, the Response Body will be returned with the content the same as if the Request had been synchronous.

So , is this a Redfish Service Validator issue ? Please clarify.

Last Edit: Jun 22, 2020 13:02:25 GMT by ginugeorge

mraineri
Administrator

Posts: 1,132

Redfish Service Validator Issue related to Task Instance Jun 22, 2020 17:19:17 GMT

Quote

Post by mraineri on Jun 22, 2020 17:19:17 GMT

There is a distinction to be made between the "Task resource" and the "Task Monitor".

The members of the TaskCollection found in the TaskService will all reference Task resources. In this case, when you perform a GET on the Task resource, you should get back a 200 OK along with the Task representation.

The Task Monitor is a special URI for the requestor of the original operation. You can find the Task Monitor URI within the Task resource itself, but the semantics about responding with a 202 Accepted until the operation is complete is purely unique to the Task Monitor URI.

In addition to the HTTP status differences, there is another key difference in behavior between the Task resource and Task Monitor.

Performing GET operations on a Task resource that represents a completed task will still return the Task resource itself.
Performing GET operations on a Task Monitor for a completed task will return the response for the original operation that generated the task.

It looks like the service validator is correctly identifying an error.

AMI_Mani
Tuna

AMI

Posts: 178

Redfish Service Validator Issue related to Task Instance May 7, 2022 7:34:56 GMT

Quote

Post by AMI_Mani on May 7, 2022 7:34:56 GMT

Hi Mike,
What will be the schema for task monitor? We have below information only

When a client issues a request for a long-running operation, the service returns the HTTP 202

Accepted status code and a Location header that contains the URI of the task monitor and, optionally,

the Retry-After header that defines the amount of time that the client should wait before querying the

status of the operation.

how we can provide URI in location header? If we give /redfish/v1/TaskService/TaskMonitors/1, where we can find details TaskMonitor resource since there is no standard schema

We can check status of task in task resource like Running, completed and client can query this attribute and this is another option. Why don't we use same Task instance to return 202 instead of adding new entity Task Monitor or we can provide the final representation of resource in task instance itself instead of showing in task monitor

Thanks,
Mani

mraineri
Administrator

Posts: 1,132

Redfish Service Validator Issue related to Task Instance May 12, 2022 13:19:03 GMT

Quote

Post by mraineri on May 12, 2022 13:19:03 GMT

The task monitor is not a resource in the model, much like other special URIs like action URIs, binary data referenced by Assembly, and the multipart update URI. The details are defined in the specification since the task monitor doesn't follow typical CRUD semantics that map to all other resources. The GET response on the task monitor is going to be dependent on the state of the requested operation, as well as the type of operation itself.

If the operation is still in progress, the response body will contain the associated Task resource.

If the operation is complete, the response body will contain the result of the operation. So, if the original operation was a PATCH on a ComputerSystem resource, the response would contain the updated ComputerSystem resource. Another example is if the original operation was the GenerateCSR action in the CertificateService, the response in this case would contain the action response body for GenerateCSR.