Re: generalising oxenstored for unix nodes too

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On Fri, Feb 17, 2012 at 09:47:42AM +0000, Raphael Proust wrote:
> 
> In FRP there is a strong separation between primitive values (those that
> can be changed by the "user") and the others (those that are updated
> automatically to reflect changes of the values it depends one). There is
> a choice one should make as to how mixing FRP and a namespace: should
> non-primitive FRP values be allowed in the tree?

This is a very useful insight.  In Xen right now, pretty much all
activities are initiated by the tools writing something into Xenstore, and
then something else that is watching a path reacting on it.  Once a user
action has been kicked off, many other tools write keys into the store and
use it as an RPC/select mechanism (e.g. for front and backend devices to
connect between VMs).

The interaction between these is very ad-hoc at the moment. Augmenting
Xenstore to specifically understand that a given key is user-supplied is
very useful.

> Allowing such a use is nice as it makes it possible for one to export
> non-primitive values directly in the tree. But allowing is complicated as it
> requires the transaction mechanism to integrate FRP bits and FRP make
> assumptions of atomic re-computation of the whole graph of values. Some values
> might only be computable on the store client, which makes the sharing of the
> name-space difficult.
> 
> There are several approaches to this problem, but some break FRP invariants or
> induce blocking operations. Still need to think about that.
> 
> 
> #bind(1)
> 
> Reading plan9-related stuff, I stumbled upon the bind
> http://plan9.bell-labs.com/magic/man2html/1/bind operation on the namespace. 
> In
> plan 9 it is used to replace $PATH (and other $MANPATH, $CDPATH, etc.)
> and also to share values.
> 
> The implementation would require modification to xenstore and its API, but it 
> is
> really a nice thing to have on a namespace. It might also be a way to loosen
> the constraints induced by the FRP aspect. (Exposed FRP values could be bound 
> to
> the 'observer' sub-tree with a not-always-up-to-date semantic.)

The previous two points are tied together, I think. We need to figure out
how to meld multiple writers (different VMs, different hosts, doesnt
matter) and guarantee that we preserve the FRP equational invariants.
Given that we have transactional isolation already and a purely functional
tree that can be mutated non-destructively, this feels like it shouldn't
be too hard.

Incidentally, the original plan behind Xenstore was to make it a
cluster-wide distributed coordinator, but that was judged too complex for
various reasons. Better late than never :-)

-- 
Anil Madhavapeddy                                 http://anil.recoil.org