From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rusty Russell Subject: Re: [RFC] Switching store to use domain id's for keys Date: Mon, 05 Sep 2005 10:11:20 +1000 Message-ID: <1125879080.24158.27.camel@localhost.localdomain> References: <4314C26E.9020408@us.ibm.com> <20050831092846.GX24659@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20050831092846.GX24659@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christian Limpach Cc: xen-devel List-Id: xen-devel@lists.xenproject.org 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 > > /domain/ 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/-. 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 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 "//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