[Linux-ha-dev] LRM Testing (take 2)
alanr at unix.sh
Mon Jun 14 07:55:54 MDT 2004
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
> 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 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: 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: 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
> 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
> 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
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
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
More information about the Linux-HA-Dev