Re: [RFC] Switching store to use domain id's for keys

[Rusty Russell <rusty@rustcorp.com.au>]

On Wed, 2005-08-31 at 10:28 +0100, Christian Limpach wrote:
> On Tue, Aug 30, 2005 at 03:32:46PM -0500, Anthony Liguori wrote:
> > Perhaps now is a good time to reconsider just using domain ids instead 
> > of UUIDs for the paths?  In a cluster we could just use 
> > <nodeid>/domain/<domid> for unique identification.
> 
> We'd like the identifier for a domain to remain the same after
> relocating the domain to a different physical machine.[1]

You're never going to have the property that a uuid always maps to the
same domain, or a domain always has the same uuid, if we ever introduce
forking of domains by any method.  So, I think this is a losing battle,
but it's causing a mess of the store as a side effect.

As far as I can tell, UUIDs are a third identifier of domains, which buy
nothing over the existing two: names (cluster-wide unique, human
readable, slow), and domids (locally unique, fast).

> If we consider changing this, I'd go for /domain/<nodeid>-<domid>.  It
> would make it easy to find the path for a domain on its home node but
> it wouldn't work anymore once you move the domain to a new host.

That only makes sense if a single store is shared across the entire
cluster.  Otherwise the <node-id> is completely redundant, since it will
be the same for all visible domains.

A better solution might be to federate at the top level, so it would be
"/<nodeid>/domain..." in a cluster environment.  Then such a federated
store does not need to effect today's plans.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman