All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Steven Hand <Steven.Hand@cl.cam.ac.uk>
Cc: xen-devel <xen-devel@lists.xensource.com>,
	Christian Limpach <Christian.Limpach@cl.cam.ac.uk>
Subject: Re: Re: [RFC] Switching store to use domain id's for keys
Date: Tue, 06 Sep 2005 10:07:49 +1000	[thread overview]
Message-ID: <1125965269.7643.31.camel@localhost.localdomain> (raw)
In-Reply-To: <E1ECCRk-0000ZH-00@mta1.cl.cam.ac.uk>

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?

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

      parent reply	other threads:[~2005-09-06  0:07 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-30 20:32 [RFC] Switching store to use domain id's for keys Anthony Liguori
2005-08-31  9:28 ` Christian Limpach
2005-08-31 20:40   ` Anthony Liguori
2005-09-05  0:11   ` Rusty Russell
2005-09-05  0:26     ` Steven Hand
2005-09-05  1:05       ` Rusty Russell
2005-09-05  1:43         ` Steven Hand
2005-09-05  2:53           ` Rusty Russell
2005-09-05  8:35             ` Steven Hand
2005-09-05  8:52               ` Keir Fraser
2005-09-06  0:07               ` Rusty Russell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1125965269.7643.31.camel@localhost.localdomain \
    --to=rusty@rustcorp.com.au \
    --cc=Christian.Limpach@cl.cam.ac.uk \
    --cc=Steven.Hand@cl.cam.ac.uk \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.