On Thu, Aug 25, 2005 at 01:06:26PM +1000, Rusty Russell wrote:
> > > The daemon is going to have to remember outstanding transactions,
> > > watches and watch events, and associate them when tools reconnect.
> > > Where possible, these will be stored on disk, so even daemon crashes can
> > > be recovered (as far as possible).
> >
> > Yes, this is currently one of the major draw backs from switching over
> > to the store. If xenstored restarts, you lose all the watches and won't
> > be able to start any more domains because the backends won't notice any
> > changes anymore.
>
> Yes, it's not possible at the moment, but it must be. I'm also thinking
> hard about catastrophic failure modes: there are always "too hard" cases
> but I'd like to be able to SIGKILL the store and (usually) have no
> problems.
Maybe it's preferable to make the store users deal with most of this after
all. We already know how to re-install watches, so triggering that code
path when the store starts up again would take care of the watches.
We will have to deal with transactions failing anyway, so if the store
restarts in the middle of a transaction, we just return a non-fatal
failure code and have the user deal with that. Finally, I think we
should have watches fire when they get first installed (and re-installed),
if the node exists. The current model where we install a watch and then
run the watch code manually doesn't work too well because the context
we're in is most likely not the same context we would be in when the
watch fires regularly.
Anything else?
christian
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home