[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Re: [RFC] Switching store to use domain id's for keys



>On Mon, 2005-09-05 at 01:26 +0100, Steven Hand wrote:
>> Rusty wrote:
>> >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).
>> 
>> Well one issue is that cluster-wide unique human readable names are 
>> tricky to enforce.
>
>A system with duplicate names is not really sane.  All user tools are
>going to use names, so differentiation by uuids doesn't help.  Whether
>name uniqueness is enforced or not I don't really mind: people are
>creative, they can generate unique names all kinds off ways (even uuids
>if that's what floats your boat).
>
>> Right now what we need is something which refers
>> to the same "virtual machine" regardless of which domain it currently
>> inhabits. I.e. across save/restore, across migrate, etc. If this is 
>> unique to a "virtual machine", then a 'fork' (when we get it) is going 
>> to cause a new one of these to be created.
>
>Sure, and the name fits these as well as UUID.  

Well UUIDs can be regular making code simpler; they can be transparently
to the tools treated as structured allowing independent allocation and 
verification; they provide a simple unambiguous ordering; they sidestep
issues of internationalization; and they firmly place xenstore out of 
the view of the end-user which I think is quite a good thing. 

>You cannot, in general, meet your requirements, UUID or no, because you 
>can fork and destroy the original, etc.

I don't understand this - can you explain? 

(or is this just some kind of general impossibility statement regarding 
asynchronous messages and byazantine failures??) 


>> I guess we could try to use
>> human readable stuff for this, but I think having the extra level of 
>> indirection makes it easier. 
>
>I disagree; more indirection, more concepts to master, more room for
>confusion, more code, worse store layout, with no more features.
>
>Seems all bad from where I'm sitting 8(

Well I certainly wouldn't want to confuse you by requiring you to master 
more concepts... :-) 

However: I think we both /agree/ on the fact that domain ids should be 
used to name things which are about domains (e.g. event channel ids 
and backend domain ids, etc, etc). 

And i think we both /agree/ that within a domain's piece of xenstore, 
that there's at least one 'name' which is a cluster-wide unique string
and which persists across save/restore/migrate. 

Yes? 


cheers,

S.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.