[Linux-ha-dev] LRM Testing (take 2)
alanr at unix.sh
Fri Jun 11 10:59:32 MDT 2004
> On Jun 11, 2004, at 6:08 PM, Alan Robertson wrote:
>> Lars Marowsky-Bree wrote:
>>> On 2004-06-11T17:55:47,
>>> Andrew <lists at beekhof.homeip.net> said:
>>> (I'm supposed to be on my way to sports already but displaced my keys,
>>> so anyway)
>>>> Without checking with the boss first, I think we'll end up storing
>>>> uuid, id, and description in the CIB. description being for admin
>>>> tools. "uuid" being generated internally for the LRM and "id"
>>>> being for logs, humans and the CRM.
>>>> The reason i plan to use id in the CRM is that either way I have to
>>>> check the values are unique (evil users may have tinkered with the
>>>> CIB) and the uuid (IMHO) is all but useless in a logfile. So if I'm
>>>> logging "id" and they are both unique, then I may as well just use
>>>> "id" and ensure that the value sent to the logs is the one the CRM
>>>> is making decisions with.
>>>> Care to veto any of that lmb?
>>> It makes sense.
>>> Alan's comments all also make sense, though, and we are all getting lost
>>> and side-tracked in myriads of small replies again. At least I admit to
>>> being guilty of that ;-)
>>> The idea of the UUID was and still is to have something of fixed size
>>> internally and between the components (LRM, CRM, etc). And to uniquely
>>> identify any given element in the CIB.
>>> It's indeed not that useful for human consumption in logfiles, for which
>>> I'd designated the "description" fields in the CIB elements.
>>> However, Andrew's point is also perfectly valid. To make sense, both of
>>> them ought to be unique, and there's not much point in having two
>>> separate unique attributes, which is bound to lead to confusion.
>>> Quickly waving my hands, I seem to think for the moment that merging
>>> them into one field is a good idea. The ID field which we use and care
>>> about should be a char * - to make sure we don't run into localization
>>> issues, we mandate that the string be made up of ASCII characters
>>> ([a-zA-Z\-\_0-9] seems to be a good idea), POSIX sorting, and a length
>>> limit of 64 characters.
>>> Then the description field can be opaque to us, and whether the admin
>>> uses it to store a UTF-8 version of the US constitution in Hebrew or not
>>> is uninteresting to us.
>>> I really like all those cool properties of UUIDs, but they don't seem to
>>> fully solve the problem of identifying resources and nodes and
>> It actually makes sense to require UUIDs to be unique, and *strongly
>> suggest* that the descriptions or human identifiers be unique in the
>> interfaces. GUIs are permitted to require that.
>> Passing both around in most places seems to make sense. Then you can
>> use the UUID for uniqueness, and log things by the human descriptor /
> The problem I see is that if you dont enforce uniqueness on the
> short_name/id (as distinct from description), then you run the risk of
> confusing ourselves and users. I look in the logs and... "OMG! The
> resource is running twice!" or "<shortname> is not configured
> correctly". Only to find that it was some other resource with the same
> So now we're back to having a UID and a UUID as well as Lars' comments
> above. The restrictions he proposes seem sensible and I imagine no
> different than we already have for node and client names in ha.cf.
All I meant to day is that the UUIDs MUST be unique to EVERYONE in the
system or it won't work. This is OK since they're automatically unique.
And, the GUIs should probably be the only thing that bothers to enforce
uniqueness on the human names - since doing it there is good enough, and
the consequences are much less.
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