airavata-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danushka Menikkumbura <danushka.menikkumb...@gmail.com>
Subject Re: Implementing the cancel/terminate
Date Thu, 01 May 2014 02:49:19 GMT
Hi Lahiru,

That makes perfect sense.

Basically I see 3 main phases of job
execution.Pre-process(In-Handlers),Process(Job itself) and
Post-process(Out-Handlers).The new operation that you mentioned could be
used to revoke changes done by the In/Out-Handlers.Probably the new type of
handler that you mentioned would be able to revoke whatever done by the
jobs?

/Danushka

On Wednesday, April 30, 2014, Lahiru Gunathilake <glahiru@gmail.com> wrote:
> Hi Danushka,
> I am thinking of having another operation for a handler which will be
invoked during a cancel process. If each handler wants to reset what it did
handlers can implement that logic to the same handler  class, if there
nothing much can be done handler can leave the cancel invocation blank.
Unless we do this its going to be hard to reset the operations did in each
handler.
> We have handlers to run in daemon mode too, so for particular
implementation developers can use them to perform more higher level clean
up task which could not make sense to implement in each handler. So GFac
framework can provide handler level clean up but developers will not be
completely bound to use that for their clean up implementation.
> Regards
> Lahiru
>
>
> On Tue, Apr 29, 2014 at 4:58 PM, Marlon Pierce <marpierc@iu.edu> wrote:
>
> I assumed there would be a lot of overlap between cancel-handlers and
> out-handlers but not complete overlap.  Cleanup operations need to be
> done in either case, but "move the successfully created output files to
> a safe storage location" would not be done.
>
> Marlon
>
> On 4/29/14 4:49 PM, Danushka Menikkumbura wrote:
>> To me this sounds a little more complicated.If we take the Whirr-based
>> cloud bursting impl for instance,we have an in handler to launch a
cluster
>> and an out handler to shut it down.When a job is cancelled in a case like
>> this, the corresponding cluster should be shut down and for that the out
>> handler needs to be notified.
>>
>> /Danushka
>>
>> On Tuesday, April 29, 2014, Lahiru Gunathilake <glahiru@gmail.com> wrote:
>>> Hi Marlon,
>>>
>>> On Mon, Apr 28, 2014 at 3:59 PM, Marlon Pierce <marpierc@iu.edu> wrote:
>>>> Are any handlers called when canceling? Should they be?  Seems like you
>>>> would need to typically do some cleanup.
>>> +1 thats the plan to have pre/post handlers for terminate operation like
>> we have to submit.
>>> Lahiru
>>>> Marlon
>>>>
>>>> On 4/23/14 2:35 PM, Saminda Wijeratne wrote:
>>>>> Got it Suresh. Thanks for putting it clearly :)
>>>>>
>>>>>
>>>>> On Tue, Apr 22, 2014 at 5:48 PM, Suresh Marru <smarru@apache.org>
>> wrote:
>>>>>> 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

Mime
View raw message