[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: [RFC] Switching store to use domain id's for keys
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |