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-devel] Re: [RFC] Switching store to use domain id's for keys

To: Steven Hand <Steven.Hand@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [RFC] Switching store to use domain id's for keys
From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Date: Tue, 06 Sep 2005 10:07:49 +1000
Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Tue, 06 Sep 2005 00:05:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <E1ECCRk-0000ZH-00@xxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <E1ECCRk-0000ZH-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Mon, 2005-09-05 at 09:35 +0100, Steven Hand wrote:
> >On Mon, 2005-09-05 at 02:43 +0100, Steven Hand wrote:
> >> Well I certainly wouldn't want to confuse you by requiring you to master 
> >> more concepts... :-) 
> >
> >You have a unique identifier which is already used by the tools and is
> >simple to understand.  
> Well actually I currently have two; user-defined 'names' and UUIDs. I'm 
> arguing that we retain these two (along with the third sort of 'name' 
> in the form of domain ids) but use them more appropriately. 

If we end up always mapping name => UUID => nodeid + domid then UUID is
not buying us anything but extra code, confusion and pain.  The
alternative is exposing the UUID to the admins, in addition to the name,
and that's a poor bad user-interface decision IMHO for a case which
shouldn't happen.

> >You want to add another one, related in some way to the first one, because 
> >it's *easy to generate*.
> Amongst other things, yes. Generating / managing unique names across a 
> cluster or federated system is tricky. Expecting a user's chosen name 
> to happen to be unique on its own doesn't work;  prefixing with e.g. 
> a node id or whatever is ambiguous in our world of live migration; 
> prefixing with a user name or role name or whatever is clunky. 

(1) We already need to handle duplicate UUID detection on restore and
fork, so we already have this problem 8(
(2) An admin who creates two domains of the same name will have trouble
controlling them, but I think that's OK, and implied.

> Anyway let's work on the above right now since that requires a restructure
> of the store which is common whether or not we assume the unique cluster
> wide things are UUIDs or random user strings.

So in all the arguing, did we decide on /domain/<domid>/ which
becomes /<nodeid>/domain/<domid> in a cluster environment, and a "name"
or "uuid" entry within it identifying the particular domain?

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

Xen-devel mailing list