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

[Steven Hand <Steven.Hand@xxxxxxxxxxxx>]

>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. 

>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. 

>I'm speechless at this logic.

Well obviously not... 

( <duck> :^)

>Your other benefits include: easier to canonically order (memcmp, of
>course, being too hard), easier to deal with (memcpy too hard as well I
>guess) and, my favorite benefit of all those you came up with: it makes
>the store *harder* to read.

Fixed sized strings are simpler to handle than variable sized ones. To 
take your example, if you use memcmp() what's n? What happens when two 
strings are different lengths (i.e. what do you explicitly or implicitly 
pad the shorted with)? 

Fixed sized strings are simpler to handle. 

W.r.t the store being harder to read - sure. I'm ok with this, although
I can see that people currently writing and debugging store stuff would 
find it nicer to have 'friendly' names (the cruft left behind in the 
store right now after you've been running for a while is pretty nasty). 

But longer term I don't envison direct or 'raw' human access to the store 
as a common operation. Instead a piece of software like 'xm' or 'vm' or a 
script or whatever will read + extract the relevant parts and format them 
for output. 

>Must be that famous dry British sense of humor 8)

Maybe, although I'm not British. 

>> 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. 
>
>Indeed, these were never in doubt.  You're arguing that we need *two*
>names, and sorry, I just can't see it.

That's a shame. 

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. 

cheers,


S.



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