airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <sma...@apache.org>
Subject Re: Implementing the cancel/terminate
Date Tue, 22 Apr 2014 22:48:50 GMT
On Tue, Apr 22, 2014 at 6:26 PM, Saminda Wijeratne <samindaw@gmail.com>wrote:

> You mean like a monitoring client at client end triggering a listener?
>

Thats ideal, but different story altogether. I mean triggering a listener
for all major status changes including canceling.

In this context I mean once the client gets Canceling at experiment level,
once all lower level statues gets updated, we should ensure subsequent
client query to experiment returned Cancelled. I see your plan already
accounts for it, was just restating its simpler for gateways to wait on
experiment status instead of expecting to navigate through Task->Job to
verify the success.

Suresh


>
>
> On Tue, Apr 22, 2014 at 5:22 PM, Suresh Marru <smarru@apache.org> wrote:
>
>> Hi Saminda,
>>
>> This like a good plan, I think we should make sure the API server
>> properly reports these statuses back to the clients.
>>
>> Suresh
>>
>> On Apr 21, 2014, at 9:06 AM, Saminda Wijeratne <samindaw@gmail.com>
>> wrote:
>>
>>  Hi All,
>>
>> After looking at the current design and doing some trial and error I
>> thought of implementing the cancellation as follows.
>>
>>
>>    - Cancellation of an experiment requested by a gateway requires
>>    cancellation request to go through several layers. (Orchestrator > GFac >
>>    GFac Provider)
>>    - Each layer is responsible for handling cancellation relevant for
>>    that layer (Orchestration cancels experiment, GFac cancels Task, GFac
>>    Provider cancels Job)
>>    - What I thought is, each layer will listen to cancellation request
>>    made to the layer above and perform its cancellation actions accordingly.
>>    (GFac will see the experiment is having the status "canceling" for an
>>    experiment id and it will perform cancellation of the tasks relevant for
>>    that experiment)
>>       - Effectively the Orchestrator will be
>>       - updating the status of the experiment in registry with the
>>          status "canceling"
>>          - publish a message which will be caught by GFac instance which
>>          handles its Tasks.
>>          - GFac will perform the same and the correct GFac Provider
>>       instance will catch the message and perform the actual job cancellation.
>>    - Once the job cancellation is done the statuses at each layer will
>>    be updated (to "canceled") in  similar fashion.
>>    - We allow the API call of cancellation to be asynchronous
>>    - I'm hoping to use the MonitorPublisher implemented by Lahiru to
>>    publish the messages.
>>
>> wdyt?
>>
>>
>> Thanks,
>>
>> Saminda
>>
>>
>>
>>
>

Mime
View raw message