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

[Andrew]

On Jun 11, 2004, at 10:05 PM, Alan Robertson wrote:

> Andrew wrote:
>> On Jun 11, 2004, at 6:59 PM, Alan Robertson wrote:
>>> Andrew wrote:
>>>
>>>> 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
>>>>>> constraints.
>>>>>
>>>>>
>>>>>
>>>>> 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 / identifier.
>>>>
>>>> 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 short_name/id.
>>>> 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.
>> But they're stored in the CIB on the filesystem with no guarantee 
>> that it wont (or shouldn't) be directly accessed by evil humans... so 
>> even with Dr Who generators, I cant assume they're unique.  So to me 
>> they are just binary UIDs and I already have a much friendlier 
>> [a-zA-Z0-9\-\_]+ UID to work with.
>
> OK.  I thought you were referring to a name meaningful to a human, not 
> a human-friendly dump of a binary UUID.  There is a well-known 
> canonical ASCII representation of UUIDs already.  It's not meaningful 
> to humans but at least it's ASCII...

There I go taking shortcuts and confusing things again...  what I 
should have said was:

"... and I already have a UID field of the form [a-zA-Z0-9\-\_]+ (such 
as prod_intra_apache1) and stored as a char* to work with."

Just like with the UUID for the LRM, its unique because I 
programatically complain very loudly if its used more than once but it 
also has the advantage that it is meaningful when seen in logs.

Moving along...

Personally, I feel that the use of UUIDs is overkill <insert everything 
i've said already> but if we absolutely must have them, then I propose 
we set a convention that the LRM and CRM logs must *always* use both 
values ie:

<some date> [crmd] ERROR:  Resource <human friendly dump of binary 
UUID> (<user specified short name>) could not be started on <some 
node>.

All decisions would be made based on the UUID but the short name is 
*always* added for clarity in the logs.  The log entries might be 
longer, but it would seem to be a nice compromise.

The LRM would need to be modified to accept "short name" and the CRM to 
use UUIDs.

Andrew

>
> -- 
>     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
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/