[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