[Engine-devel] Task cancelation feature

Saggi Mizrahi smizrahi at redhat.com
Mon Dec 3 18:07:04 UTC 2012


I just noticed I only implied the implications to task cancellation but didn't give a concrete example.

For storage at least, there will be a difference between canceling for now (hibernating) and canceling completely.
When you will cancel a copy VDSM task, for example, what will happen is that VDSM will stop the current copy but persist some information so it can continue the operation on a later time.
This means you are actually "hibernating" the copy operation. To actually cancel the copy completely you need to stop any operation on the target image and remove it.

This means that relevant vdsm task IDs can change in the middle of the operation and that one task in the engine can be N sequential tasks in VDSM.
It also means that some operations can be "hibernated" and some can't.

----- Original Message -----
> From: "Saggi Mizrahi" <smizrahi at redhat.com>
> To: "Michael Kublin" <mkublin at redhat.com>
> Cc: "engine-devel" <engine-devel at ovirt.org>
> Sent: Monday, December 3, 2012 12:15:07 PM
> Subject: Re: [Engine-devel] Task cancelation feature
> 
> VDSM tasks are changing to something completely different.
> It's still under discussion but the general direction is that:
> - TaskIDs will be decided by the caller.
> - VDSM can start tasks on it's own
> - There will be no distinction between async tasks and sync tasks.
> Everything is always async.
> - There will be no cleanTask() when tasks are done they return result
> to the caller and disappear immediately.
> 
> Also, some stuff you consider tasks will no longer be tasks any more.
> For instance, copying and image will finish successfully once VDSM
> registers the operation for with the storage subsystem and creates
> the image handle.
> After that the status of the copy is bound to the status of the new
> image and is tracked that way.
> This means that the thing you track when you do copyImage() is
> actually the creation of the image handle and the metadata to make
> it usable.
> After that is done any host can query the state of the new image by
> using the image ID and not the task Id which was deprecated.
> This will be true for all storage operations.
> 
> 
> ----- Original Message -----
> > From: "Michael Kublin" <mkublin at redhat.com>
> > To: "engine-devel" <engine-devel at ovirt.org>
> > Sent: Monday, December 3, 2012 4:19:48 AM
> > Subject: [Engine-devel] Task cancelation feature
> > 
> > Hi, I created a wiki page with design of task cancellation feature.
> > The url is : http://www.ovirt.org/Features/TaskManagerCancelTask
> > I can not call these design, I have not any requirements , except a
> > name of the feature,
> > so my wiki doesn't contains anything except open questions.
> > Also, I think that it is impossible to make a good feature based on
> > very problematic infrastructure,
> > I think before we should fix all our infrastructure problems, and
> > after that to add any cancellation task
> > feature will be a meter of couple hours of work
> > 
> > Regards Michael
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
> 



More information about the Engine-devel mailing list