On Tue, Apr 22, 2014 at 6:26 PM, Saminda Wijeratne <samin...@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 <sma...@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 <samin...@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 >> >> >> >> >
