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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home