[Linux-ha-dev] LRM Testing (take 2)

[Alan Robertson]

Lars Marowsky-Bree wrote:
> On 2004-06-11T16:45:31,
>    Alan Robertson <alanr at unix.sh> said:
> 
> 
>>Let's say we're naming a resource group for example.
>>
>>The user might want to name it something like "database group" or something 
>>like that.  This is a name *he* (the human) chose (not a system name), and 
>>really just has to make him happy.  He likes the description.  It's just a 
>>string in some character set.  Probably in his native language.  In most 
>>cases it should probably be unique.  Maybe even in all cases.
> 
> 
> Right. That's what I'll call the "long description" from here on, and I
> think we all agree on this one. It's opaque to us. 
> 
> But because it's opaque, it's not something we can use in the logfiles -
> first, it may not even been syslog clean (logging utf-8 to syslog would
> be evil), and it's also not something which the user can feed to one of
> the CRM/LRM/whatever tools on the command line to query or manage it.
> 
> 
>>But, the system, not wanting to deal with things like what language the 
>>administrator was speaking when he added this resource group, needs some 
>>kind of permanent, non-pointer name to stick into a file or send over the 
>>wire.
> 
> 
> Right. Again, this is what I'll call the "system identifier" here.
> 
> The first point of contention seems to be where this system identifier
> comes from. A UUID is _really_ nice if it's all automatically generated.
> 
> However, it's not in this case. Though we will have a nice GUI one day,
> the configuration obviously still MUST be creatable by hand with a text
> editor. Requiring the admin to assign UUIDs in that case is asking for
> it, and will make the configuration beyond unwieldly.
> 
> (This is different in the case of a filesystem, which creates a UUID and
> assigns it all on it's own, and the user is not supposed to ever access
> the filesystem "directly"; the only time he'll use that UUID is r/o when
> he may enter it into fstab.)
> 
> And because the configuration comes in from the user (GUI or text
> editor, we can't know), we need to verify that all ids are indeed
> unique in the first pass at least.
> 
> The next point of contention is where the UUIDs are used. On the wire,
> we don't care much about anything anyway - whether its a char[16] or a
> char * doesn't matter much, we can use either - we need to map them into
> our own data structures and look them up anyway.
> 
> So, where else is that system identifier used? Right. User interaction
> through logfiles and command line tools.
> 
> Jun 14 13:50:03 chip crmd[3934]: Resource a550e4c8-ea8b-4610-a4bd-f5239127cda3 failed start on node 0e4813ad-f71a-4b56-9da9-9a96257cb2f5
> 
> # crm_query resource list a550e4c8-ea8b-4610-a4bd-f5239127cda3
> 
> Ho-hum. No. I don't _quite_ think so, this seems a bit ... elaborate.
> But can we use the long description? No, this may be way too long and
> not fit into syslog at all etc, see above.
> 
> So we still need a shorter identifier, which we can use for logging, and
> which _still_ is "unique" in so far that the user/admin can use it when
> querying us:
> 
> Jun 14 13:50:03 chip crmd[3934]: Resource Filesystem-chip-1 failed start on node chip
> 
> Ah. Better. So, clearly, we need that short identifier. Agreed so far?
> 
> So, then the question remains whether we need both the UUID as the
> globally unique object identifier _and_ the short identifier.
> 
> Here's where Andrew and I differ from you; I'll argue that because the
> short identifier _also_ needs to be unique (or else it's useless for
> interacting with the system), the UUID does not provide any additional
> benefit.
> 
> Your ideas about preserving the UUID are fine, but I'd rather do away
> with the UUID at this point in time.
> 
> 
>>I don't yet understand the need for an ASCII string which wasn't made up by 
>>a human being, or can't be derived from a human input in a mechanical way. 
>> Can you help me see what I'm missing in this piece?
> 
> 
> _Exactly!_ ;-) The point here is that this ASCII string _is_ made up by
> a human being, is required to be unique and thus there's no need any
> longer for having a separate, machine-generated and unwieldly UUID.
> 
> 
>>But, if your data is non-hierarchical (like a DAG or even a cyclic graph), 
>>then you need to name your nodes in some unique way.  Then a UUID makes 
>>lots of sense if you have to store this non-hierarchicial data on disk or 
>>send it between processes.
> 
> 
> Lets distinguish the needs here. We need a unique identifier. Whether
> that is a UUID or a unique ASCII string is a different topic; because we
> _also_ need the unique ASCII string to be useful in logfiles etc, I
> argue we don't need it to be a UUID.
> 
> 
>>I think that documented external interfaces ought to be consistent in the 
>>way they name unique 'things'.  And, those unique 'things' can easily be 
>>represented by uuids.
> 
> 
> See above. Yes, obviously anything "unique" can be easily represented by
> UUIDs, which is what they are really good at, but I think it's not
> appropriate here.
> 
> 
>>Of course, this doesn't say that things which already have natural human 
>>names which are already unique should be forced to have UUIDs in every 
>>case.  But, it might make interfaces somewhat more consistent when it makes 
>>sense.
> 
> 
> Ah, here we agree. That's exactly my argument; though I arrive at the
> conclusion that for identifying resources, nodes, constraints in the
> CIB, this does not make the interface more consistent, but more
> complex.

Nodes in particular need to be identified by uuid for other reasons - like 
the membership API requires it, the eventual ability to merge clusters, etc.

You mean log files always have to be in English?  I know Linux puts them 
out in German and French including their "funny" characters if someone asks 
them to...  This is not possible with Andrew's rule on char sets.  I think 
you're mistaken on not sysloging in the native language.  [but I'll look 
into it to get an authoritative answer].

That's the whole point of internationalization.  Providing *all* interfaces 
in the native language.

It seems to me that this is a point around which much revolves.  If you can 
log in the native language - you *should* log in the native language.  If 
one cannot, then your argument makes sense - even though by implication it 
dooms Linux to being perpetually incompatible with non-English-speakers.

Because your system is to have two identifiers both generated by hand - one 
in the native language, on in pseudo-English.  But, with native language 
logging, either the second one is unnecessary, or it can be generated 
automatically via a uuid.

There is no way that anyone other than the developers on this project will 
every be able to generate correct XML for configurations.  Without a 
configuration tool, no one will ever use release 2 for anything but the 
most basic of testing...

Therefore, arguments about the difficulty of generating uuids by hand are 
irrelevant.

-- 
     Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me claim 
from you at all times your undisguised opinions." - William Wilberforce