| |
|
 |
|
 |
|
|
|
| |
|
|
xen-tools
RE: [Xen-tools] Recent xenstore updates
> This was the original intention, but it's been problematic in
> practice.
> There's no simple way to implement timeouts, since eg. a core
> dump daemon would be expected to take minutes.
Well, we could have a 'keep alive' protocol, and/or a timeout specified
upon registration of the handler.
> > What's the story for doing the above without support for priorites?
> > Are we going to have to create some other convention that
> enables the
> > various dameons to serialize themselves into the right
> (partial)order?
> Consider this alternate strategy which is more robust
> (although it's quite possible that xend execing known paths
> is a better model in practice, and this generality is way overkill):
>
> postmortemd registers interest by creating directory:
> mkdir .../notification/death/postmortemd
>
> xend writes uuid to each dir under notification/death/
> write .../notification/death/postmortemd/<uuid>
>
> postmortemd does work, then deletes node.
> rm .../notification/death/postmortemd/<uuid>
>
> xend notices deletion, notifies next daemon/cleans up etc.
>
> In this case, the data contains the information, and it's
> fairly easy to ensure that any of the daemons can be
> restarted at any time and see what work there is to do.
>
> It's also fairly easy for xend to implement a priority
> scheme, filtering or whatever turns out to make sense. A
> variant is that the event ("death" in this example) actually
> written into the <uuid> node, rather than being implied by
> the directory.
Sure, it's possible to do it by convention using a daemon to implement
the 'work flow'.
I see this as rather a shame though. Once we move to the phase 3 tools
it would be nice to have all the 'sensors and actuators' that are
'below' xenstore being co-ordinated entirely from the store, without
need for some separate daemon that they have to register with for the
sole purpose of sequencing.
I think we should re-evaluate the need for sequencing support in
xenstore when we get to this stage.
Ian
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
|
|
| |
|
Home