[Ovirt-devel] Thoughts about taskomatic redesign

Jason Guiditta jguiditt at redhat.com
Mon Jun 23 18:08:45 UTC 2008


Throwing in my thoughts/concerns (though I don't know taskomatic well, 
so shoot it down if they are invalid)

Chris Lalancette wrote:
> <snip>
>
> 3)  Transaction support in taskomatic (hi slinaberry!).  I'm not sure about this
> one; we are modifying state external to the database, so I'm not sure
> "rolling-back" a transaction means a whole hill of beans to us.  In fact, I
> might argue that rolling back is worse in this case; if you modified external
> state, and then crashed, when you come back you might "roll-back" your VM state
> to something that's totally invalid, and you'll need to be corrected by
> host-status anyway.  Does anyone have further thoughts here?
>
>   
I actually thought I had more problems with this when I first read it, 
but mostly this all seems very reasonable to me on second pass.  I think 
if the external state has been modified, but failed or did not complete 
as expected, instead of rolling back, it would make more sense to 
_change_ whatever fields are associated with the changed state, so when 
the user sees the wui, they do not think nothing has happened, but can 
instead see a message showing what the real state is.  Maybe as an 
example, this could be something like 'VM restart failed, trying again', 
or some such.
> THOUGHTS:
> Interestingly, I think we can evolve the current taskomatic to do this, rather
> than re-writing the thing from scratch.  Since we cleaned up error reporting
> handling and reporting, I actually feel a lot better about the state of
> taskomatic.  It really just needs corner/error cases better handled, and then
> introducing some of the above concepts one at a time.  Is there anything in
> taskomatic right now that people are particularly unhappy about that might
> warrant a re-write?
>   
I mentioned this in irc, but for those who didn't see it - what if 
instead of reading/writing directly to the database, taskomatic _and_ 
the wui communicate using an amqp queue?  Let me attempt an example of 
how this might work, and how it could be useful.  I am creating a new vm 
in the wui.  I type in new information to start the process, and the 
info is saved to the database.  Now I need to wait for taskomatic to do 
x,y and z tasks before I can go on to do whatever else I want to do 
(let's say I want to reboot the vm for some post-install config).  If we 
use queues/messaging, I as the user could immediately say I want to 
reboot.  This request is added to the list after x,y and z (this list 
could even be shown in the wui, if appropriate).  Taskomatic listens for 
new events to be published on whatever channel it is subscribed to, and 
starts do the work as it receives notice.  As it completes a task, it 
fires off a message and any database changes are saved (I guess this 
could either still be by taskomatic, or something else that listens for 
completion messages and takes care of these updates).  It then grabs the 
next task, and so on.  Meanwhile, the wui gets notified as each task is 
completed, so the user can see where they are in the queue while 
continuing to do whatever else they might need to do.  A side benefit of 
this approach is that we may not have a locking issue at all, since the 
apps work strictly from a queue instead of directly again the db.  A 
last thought is that this might also obviate the need for two different 
modes (multi-machine or single), though I am not positive on that point.

-j
> Chris Lalancette
>
> _______________________________________________
> Ovirt-devel mailing list
> Ovirt-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/ovirt-devel
>   




More information about the ovirt-devel mailing list