You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Sumit Mohanty (JIRA)" <ji...@apache.org> on 2014/01/24 01:13:37 UTC

[jira] [Commented] (AMBARI-1897) Add capability to cancel/abort requests

    [ https://issues.apache.org/jira/browse/AMBARI-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13880533#comment-13880533 ] 

Sumit Mohanty commented on AMBARI-1897:
---------------------------------------

Ambari needs to support canceling of Request as well as individual Tasks. 

A PUT API support should be added to Request and Task resources to mark them as CANCEL_REQUESTED = True. A new state should be introduced to indicate the state of the Request and Task as CANCELLED (alternatively use the status ABORTED). _An audit log can also be maintained for the cancelled requests/tasks._

The DB schema should be modified to include information as to if cancel has been requested on Request/Task. This can be kept in memory but a persistent trail is needed to allow debugging.

ActionScheduler picks up all of the stages that are not completed. At this point the following possibilities exist for any Task assuming its a candidate for cancellation:
*Task is PENDING*
This task can be Cancelled immediately. This will have the necessary cascading effect such as future stages may get automatically aborted.
*Task is QUEUED*
Same as above except the agents, where the Task is queued, should be send a CANCEL_COMMAND to cancel the tasks.  See AMBARI-4324. Note that a task could be in any stage of transition to agent - 1) in the queue at the server and not yet send to the agent, ... N) in the agent queue and already picked up for execution but not reported back to the server as IN_PROGRESS. A possible race condition here is that agent gets the CANCEL_COMMAND for the task before the task itself.
*Task is IN_PROGRESS*
Same as above. The agent may not honor the CANCEL_COMMAND as it may not abort a task that is already in progress. We should still send the cancel command to the agent as in future we may add capability to abort executing tasks.

Overall, cancel support is considered best effort. The expectation is to be able to cancel all Tasks that are not yet started execution at the agent.

There are few click-stops for this feature.
* Cancel only the tasks that are PENDING at the Server side
* Cancel only tasks that are PENDING and QUEUED. It is assumed that agent will only cancel the QUEUED tasks that are not currently executing

> Add capability to cancel/abort requests
> ---------------------------------------
>
>                 Key: AMBARI-1897
>                 URL: https://issues.apache.org/jira/browse/AMBARI-1897
>             Project: Ambari
>          Issue Type: Bug
>    Affects Versions: 1.2.3
>            Reporter: Sumit Mohanty
>            Assignee: Sumit Mohanty
>
> Ambari allows queuing multiple requests/commands. Ambari should allow aborting a request if its safe to abort it.
> Aborting a request should set a flag to record the request to abort. When ActionScheduler picks up the request to execute it should check if a request to abort has been set and if so it should abort 



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)