fish
Guppy
Posts: 65
|
Post by fish on Nov 24, 2017 16:06:24 GMT
Hi,
The Redfish API specification (DSP0266 v1.3.0, section 8.2 “Asynchronous operations”) states: “The client may cancel the operation by performing a DELETE on the Task Monitor URL. …The client may also cancel the operation by performing a DELETE on the Task resource.”
This section says nothing about if the server “shall” support cancelling of asynchronous operations via DELETE of task resource or task monitor. Therefore my current assumption is that this is an optional server feature, and not mandatory for severs to support. Would you agree?
May other questions would be about the bullet list in the end of this section. This section seems to repeat some of the previous descriptions, in more formal summary form. Is this bullet-list a summary of all mandatory (“shall”) and optionally (“should/may”) requirements? Is this then also evidence of that this type of cancelling of ongoing asynchronous operation is not mandatory for servers? (As cancel of ongoing asynchronous operation is missing in the bullet list.) Or what is the scope of this list?
|
|
|
|
Post by mraineri on Nov 29, 2017 13:12:23 GMT
Thanks for finding this. We'll take this back into the group to discuss and see if we can update the spec to clarify the behavior. Our initial impression is there should be a shall statement for cancelling a task via DELETE, but there is no guarantee that it can be done. I also agree there is some duplicate text and the section can be cleaned.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Nov 29, 2017 15:48:12 GMT
OK, sounds good that you will look into this more.
My personal opinion is that making this into a new “shall” requirement at this point could put a quite heavy implementation burden on existing server implementations that do not currently support such cancel operation. I would propose to make it into an optional/”should”/”may” requirement for this reason. Other reason is that we should not have more “shall” requirements than necessary, and I would consider this feature to be perhaps not the most important.?
I think also you should consider possible alternative solution for cancel of task via e.g. new action “cancel” on the task resource. Such solution would have the advantage that you can still track the tasks that were stopped via “cancel” in the task collection, and you can also see their state in the same way as for tasks that were Completed. (May need some new task state such as “Canceled”.) If you delete the task when you try to cancel it you also lose track of it. (Unless you get a new task for asynchronous delete of original task…) But also such solution should be optional in my opinion.
|
|
|
|
Post by mraineri on Nov 29, 2017 18:00:18 GMT
Thanks for the input! We'll take it into consideration when discussing this in the group.
|
|
|
|
Post by j2hilland on Nov 30, 2017 22:03:29 GMT
I don't think you can make cancelling a "shall" at this point. It might be a should as users will want to cancel tasks but there are some tasks that when started simply cannot be "undone". So you can support cancel but return an error on the cancel.
The spec already calls out the usage of the ALLOW header so when the async operation is returned, the ALLOW header having DELETE as a value would indicate to the client that the client could attempt to cancel this async operation (though again, an error may be returned). We probably ought to clarify the spec here to indicate that the ALLOW header shall be returned if the async operation can be cancelled and shall apply to either the Task Monitor or Task Resource.
Note that the document indicates that you can cancel either the Task Monitor or Task Resource. Cancelling the Task Monitor via DELETE will preserve the Task Resource so that someone can check on it later so would be the preferred semantic to support and this eliminates the need for an action. So we could clarify that paragraph.
We may have a hole w.r.t. the Task Monitor - if the client program terminates then the URI of the Task Monitor is lost. By adding a Task Monitor property to the Task Resource itself, this would allow another client to monitor the task and get the completion payload across errors. This implies sufficient permissions but shouldn't be a permissions/security concern otherwise.
Hope this helps.
|
|
fish
Guppy
Posts: 65
|
Post by fish on Dec 1, 2017 8:08:00 GMT
I agree that cancel via delete of task mointor is better option than delete of task resource.
An additional potential problem with cancel via delete of task resource is that it may be a little unpredictable.
If the client´s intention is to cancel the original operation this will be the result as long as the task is still in state Running,
Response would be 200/OK, task resource is deleted and side-effect is that original asynch operation is also canceled.
But if clients request is received by the server one second later and the task has already entered state Completed the response will still
be 200/OK, task resource is gone and no side-effect of canceled asynch operation. So in this case the clint will not know if the
operation was actually canceled or completed.? (Cancel of Completed task will be normal procedure for cleaning up old tasks from the task collection.)
I guess above problem can maybe be resolved also via some E-tag handling, but this is not mandatory I think?
I still vote for cancel via action as long-term solution. Having this type of side-effect on delete of task monitor would not be the preferred semantics in my opinion.
|
|
