This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


RE: [Xen-tools] Recent xenstore updates

To: "Rusty Russell" <rusty@xxxxxxxxxxxxxxx>
Subject: RE: [Xen-tools] Recent xenstore updates
From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
Date: Fri, 5 Aug 2005 03:11:07 +0100
Cc: Xen Tools <xen-tools@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 05 Aug 2005 02:09:20 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-tools-request@lists.xensource.com?subject=help>
List-id: Xen control tools developers <xen-tools.lists.xensource.com>
List-post: <mailto:xen-tools@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-tools>, <mailto:xen-tools-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-tools-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcWZXqseUz7tqcTTRcSIFDlgIMCCdgAAZIZA
Thread-topic: [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. 


Xen-tools mailing list

<Prev in Thread] Current Thread [Next in Thread>