Mailing List Archive: Linux-HA: Dev

LRM Testing (take 2)

1 2

View All

Index | Next | Previous | View Threaded

lists at beekhof

Jun 7, 2004, 4:05 AM

Post #1 of 42 (3849 views)
Permalink

LRM Testing (take 2)

Attached is a log indicating a problem with added RAs

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: lrm.test
Type: application/octet-stream
Size: 2560 bytes
Desc: not available
Url : http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20040607/e690cb41/lrm.obj

lmb at suse

Jun 7, 2004, 4:13 AM

Post #2 of 42 (3800 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-07T12:05:11,
Andrew <lists [at] beekhof> said:

> Attached is a log indicating a problem with added RAs

Not so good...

Could the LRM team please provide some insights into how the LRM is
tested, and which testcases are known to work?

Sincerely,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

sunjd at cn

Jun 7, 2004, 4:17 AM

Post #3 of 42 (3765 views)
Permalink

LRM Testing (take 2) [In reply to]

The rscid must be a uuid. "rsc1" is a invalid rscid.

>Attached is a log indicating a problem with added RAs
>
>Andrew

Thanks & Best Regards,

Sun Jiangdong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20040607/defab126/attachment.htm

lists at beekhof

Jun 7, 2004, 4:27 AM

Post #4 of 42 (3762 views)
Permalink

LRM Testing (take 2) [In reply to]

and lrmadmin -L ?

On Jun 7, 2004, at 12:13 PM, Jiang Dong Sun wrote:

> The rscid must be a uuid. "rsc1" is a invalid rscid.

dont we the user supply the uuid? because "rsc1" is what i specified
in the add, and it accepted it fine.

can you also define what a valid uuid is pls?

>
>
> >Attached is a log indicating a problem with added RAs
> >
> >Andrew
>
>
>
> Thanks & Best Regards,
>
> Sun Jiangdong
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

sunjd at cn

Jun 7, 2004, 8:40 AM

Post #5 of 42 (3796 views)
Permalink

LRM Testing (take 2) [In reply to]

>and lrmadmin -L ?
Sure. This will list the resource's id (uuid).

>
>On Jun 7, 2004, at 12:13 PM, Jiang Dong Sun wrote:
>
>> The rscid must be a uuid. "rsc1" is a invalid rscid.
>
>dont we the user supply the uuid? because "rsc1" is what i specified
>in the add, and it accepted it fine.

I remember it's the result of former discussiones to use a unique uuid to
tag a resource.
Of course we can change/extend it if reasonable.

>
>can you also define what a valid uuid is pls?

Normally we produce it using then "uuidgen" command ( belong to
e2fsprogs-1.32-15 ).

>
>>
>>
>> >Attached is a log indicating a problem with added RAs
>> >
>> >Andrew
>>
>>
>>
>> Thanks & Best Regards,
>>
>> Sun Jiangdong
>>
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev [at] lists
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>
>_______________________________________________________
>Linux-HA-Dev: Linux-HA-Dev [at] lists
>http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>Home Page: http://linux-ha.org/Thanks & Best Regards,

Thanks & Best Regards,
Sun Jiang Dong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20040607/35a34ecc/attachment.htm

lmb at suse

Jun 7, 2004, 8:54 AM

Post #6 of 42 (3760 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-07T22:37:06,
Jiang Dong Sun <sunjd [at] cn> said:

> Normally we produce it using then "uuidgen" command ( belong to
> e2fsprogs-1.32-15 ).

If the uuid is indeed internally treated as a char[16], it shouldn't
matter at all whether it happens to be "rsc1\0\0\0\0\0\0\0\0" at all, so
rsc1 seems to be a valid UUID to me.

Just needs to make sure the remaining fields are all properly
initialized.

Maybe it'd even be better to just use a char * as the ID and let us care
about whether it's a UUID, a single byte or some kilobyte-long name.
Would be the most flexible approach for the LRM, I think...

Mit freundlichen Gr??en,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

lists at beekhof

Jun 7, 2004, 9:21 AM

Post #7 of 42 (3763 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 7, 2004, at 4:37 PM, Jiang Dong Sun wrote:

> >and lrmadmin -L ?
> Sure. This will list the resource's id (uuid).

yes but if you look at the log you can see its corrupted

>
> >
> >On Jun 7, 2004, at 12:13 PM, Jiang Dong Sun wrote:
> >
> >> The rscid must be a uuid. "rsc1" is a invalid rscid.
> >
> >dont we the user supply the uuid? because "rsc1" is what i specified
> >in the add, and it accepted it fine.
>
> I remember it's the result of former discussiones to use a unique uuid
> to tag a resource.
> Of course we can change/extend it if reasonable.
>
> >
> >can you also define what a valid uuid is pls?
>
> Normally we produce it using then "uuidgen" command ( belong to
> e2fsprogs-1.32-15 ).
>
> >
> >>
> >>
> >> >Attached is a log indicating a problem with added RAs
> >> >
> >> >Andrew
> >>
> >>
> >>
> >> Thanks & Best Regards,
> >>
> >> Sun Jiangdong
> >>
> >> _______________________________________________________
> >> Linux-HA-Dev: Linux-HA-Dev [at] lists
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >> Home Page: http://linux-ha.org/
> >
> >_______________________________________________________
> >Linux-HA-Dev: Linux-HA-Dev [at] lists
> >http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> >Home Page: http://linux-ha.org/Thanks & Best Regards,
>
> Thanks & Best Regards,
> Sun Jiang Dong
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

lists at beekhof

Jun 7, 2004, 9:22 AM

Post #8 of 42 (3796 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 7, 2004, at 4:53 PM, Lars Marowsky-Bree wrote:

> On 2004-06-07T22:37:06,
> Jiang Dong Sun <sunjd [at] cn> said:
>
>> Normally we produce it using then "uuidgen" command ( belong to
>> e2fsprogs-1.32-15 ).
>
> If the uuid is indeed internally treated as a char[16], it shouldn't
> matter at all whether it happens to be "rsc1\0\0\0\0\0\0\0\0" at all,
> so
> rsc1 seems to be a valid UUID to me.
>
> Just needs to make sure the remaining fields are all properly
> initialized.
>
> Maybe it'd even be better to just use a char * as the ID and let us
> care
> about whether it's a UUID, a single byte or some kilobyte-long name.
> Would be the most flexible approach for the LRM, I think...

I would agree with this approach

>
>
> Mit freundlichen Gr??en,
> Lars Marowsky-Br?e <lmb [at] suse>
>
> --
> High Availability & Clustering \ ever tried. ever failed. no
> matter.
> SUSE Labs | try again. fail again. fail better.
> Research & Development, SUSE LINUX AG \ -- Samuel Beckett
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

msoffen at iso-ne

Jun 7, 2004, 9:32 AM

Post #9 of 42 (3788 views)
Permalink

LRM Testing (take 2) [In reply to]

I think that if you don't think of uuid as a char[16] but as a type (
uuid_type ) then it may or may NOT be a valid uuid.

I would also think that if it wasn't created by uuidgen, then you have no
means to determine if it is a valid uuid.

Matt

-----Original Message-----
From: Lars Marowsky-Bree [mailto:lmb [at] suse]
Sent: Monday, June 07, 2004 10:53 AM
To: High-Availability Linux Development List
Subject: Re: [Linux-ha-dev] LRM Testing (take 2)

On 2004-06-07T22:37:06,
Jiang Dong Sun <sunjd [at] cn> said:

> Normally we produce it using then "uuidgen" command ( belong to
> e2fsprogs-1.32-15 ).

If the uuid is indeed internally treated as a char[16], it shouldn't
matter at all whether it happens to be "rsc1\0\0\0\0\0\0\0\0" at all, so
rsc1 seems to be a valid UUID to me.

Just needs to make sure the remaining fields are all properly
initialized.

Maybe it'd even be better to just use a char * as the ID and let us care
about whether it's a UUID, a single byte or some kilobyte-long name.
Would be the most flexible approach for the LRM, I think...

Mit freundlichen Gr??en,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev [at] lists
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

lmb at suse

Jun 7, 2004, 11:30 AM

Post #10 of 42 (3804 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-07T11:33:05,
"Soffen, Matthew" <msoffen [at] iso-ne> said:

> I think that if you don't think of uuid as a char[16] but as a type (
> uuid_type ) then it may or may NOT be a valid uuid.
>
> I would also think that if it wasn't created by uuidgen, then you have no
> means to determine if it is a valid uuid.

A valid UUID is a random string of 128bit length.

How you'd further determine what is a valid UUID and what is not is
beyond me.

(Oh, right, if it ever clashes with something else, it is not ;-)

Sincerely,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

lists at beekhof

Jun 7, 2004, 11:32 AM

Post #11 of 42 (3797 views)
Permalink

LRM Testing (take 2) [In reply to]

Either way, if the LRM accepts it in the first place (add) it should
not then reject it in the second (query).

I also feel that the (policy free) LRM is being over-zealous here.
Checking that something with the same ID has not already been added is
a must, but I see no benefit over char* and strcmp() by using the uuid
struct or the format produced by uuidgen.

It is also quite likely that users would benefit from using human
readable/intelligable resource IDs, in which case 16 chars might turn
out to be on the short side.

Andrew

On Jun 7, 2004, at 5:33 PM, Soffen, Matthew wrote:

> I think that if you don't think of uuid as a char[16] but as a type (
> uuid_type ) then it may or may NOT be a valid uuid.
>
> I would also think that if it wasn't created by uuidgen, then you have
> no
> means to determine if it is a valid uuid.
>
> Matt
>
>
> -----Original Message-----
> From: Lars Marowsky-Bree [mailto:lmb [at] suse]
> Sent: Monday, June 07, 2004 10:53 AM
> To: High-Availability Linux Development List
> Subject: Re: [Linux-ha-dev] LRM Testing (take 2)
>
>
> On 2004-06-07T22:37:06,
> Jiang Dong Sun <sunjd [at] cn> said:
>
>> Normally we produce it using then "uuidgen" command ( belong to
>> e2fsprogs-1.32-15 ).
>
> If the uuid is indeed internally treated as a char[16], it shouldn't
> matter at all whether it happens to be "rsc1\0\0\0\0\0\0\0\0" at all,
> so
> rsc1 seems to be a valid UUID to me.
>
> Just needs to make sure the remaining fields are all properly
> initialized.
>
> Maybe it'd even be better to just use a char * as the ID and let us
> care
> about whether it's a UUID, a single byte or some kilobyte-long name.
> Would be the most flexible approach for the LRM, I think...
>
>
> Mit freundlichen Gr??en,
> Lars Marowsky-Br?e <lmb [at] suse>
>
> --
> High Availability & Clustering \ ever tried. ever failed. no
> matter.
> SUSE Labs | try again. fail again. fail better.
> Research & Development, SUSE LINUX AG \ -- Samuel Beckett
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

David.Brower at oracle

Jun 7, 2004, 2:11 PM

Post #12 of 42 (3767 views)
Permalink

LRM Testing (take 2) [In reply to]

An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20040607/fcf304d9/attachment.htm

lists at beekhof

Jun 7, 2004, 2:52 PM

Post #13 of 42 (3763 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 7, 2004, at 10:11 PM, David Brower wrote:

>
> On something someone else wrote, it is a mistake to be using a uuid as
> ?a name; if 16 chars aren't long enough, then someone is doing
> something wrong.

prod_intra_apache1

(apache server 1 for the production instance of the corporate intranet)

So I count 18 character in what I would say is a quite reasonable
*resource id* - given that this is all admins will have to go by in the
LRM (and CRM) logs.

I do not see how this naming method is any less valid than any of the
"UUID" generators out there. This one has the benefit of also
providing admins with useful information when seen in logs. You may
wish to call the above resource 8cf9d73 so you can fit into some
arbitrary limit, I however, do not.

The LRM is policy free by design, therefore it should also not dictate
what "unique" means beyond "has it been used yet" and it should also
not place restrictions on how people might wish to name their
resources. If this means calling it a name instead of a UUID, so be
it.

Andrew

lmb at suse

Jun 7, 2004, 3:01 PM

Post #14 of 42 (3759 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-07T22:52:03,
Andrew <lists [at] beekhof> said:

> I do not see how this naming method is any less valid than any of the
> "UUID" generators out there. This one has the benefit of also
> providing admins with useful information when seen in logs. You may
> wish to call the above resource 8cf9d73 so you can fit into some
> arbitrary limit, I however, do not.

Well, the UUID was an original design idea. We (or at least I) went
crazy and used it almost everywhere.

However, a single unique string of arbitary length (say, <=64 octets
including the \0) may turn out to be the better choice.

Mit freundlichen Gr??en,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

sunjd at cn

Jun 8, 2004, 3:20 AM

Post #15 of 42 (3799 views)
Permalink

LRM Testing (take 2) [In reply to]

Ok, according to the popular opinion, will change the "uuid"'s format.
Before that, please tolerate the inconvenience brought by UUID in LRM for a
while. ;-)

>On 2004-06-07T22:52:03,
> Andrew <lists [at] beekhof> said:
>
>> I do not see how this naming method is any less valid than any of the
>> "UUID" generators out there. This one has the benefit of also
>> providing admins with useful information when seen in logs. You may
>> wish to call the above resource 8cf9d73 so you can fit into some
>> arbitrary limit, I however, do not.
>
>Well, the UUID was an original design idea. We (or at least I) went
>crazy and used it almost everywhere.
>
>However, a single unique string of arbitary length (say, <=64 octets
>including the \0) may turn out to be the better choice.
>
>
>Mit freundlichen Gr?-en,
> Lars Marowsky-Br?e <lmb [at] suse>
>
>--
>High Availability & Clustering \ ever tried. ever failed.
no matter.
>SUSE Labs | try again. fail again.
fail better.
>Research & Development, SUSE LINUX AG \ -- Samuel Beckett

Thanks & Best Regards,

Sun Jiangdong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.community.tummy.com/pipermail/linux-ha-dev/attachments/20040608/9383c04d/attachment.htm

alanr at unix

Jun 11, 2004, 8:08 AM

Post #16 of 42 (3761 views)
Permalink

LRM Testing (take 2) [In reply to]

Jiang Dong Sun wrote:
> Ok, according to the popular opinion, will change the "uuid"'s format.
> Before that, please tolerate the inconvenience brought by UUID in LRM
> for a while. ;-)

I'm sorry I was off the list fixing hardware while all this went on...

The UUID format is the right answer... It is a standard, actually, and we
should just use it.

Don't mess with it.

However, it is NOT a string, and cannot be strcmp()ed... You can use a
string provided you NULL-pad the string in every case...

It is a binary value of 128 bits.

Making it of arbitrary length overly complicates the interface because you
now have to pass the length everywhere you use it - BECAUSE IT IS BINARY,
not a string.

--
Alan Robertson <alanr [at] unix>

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

alanr at unix

Jun 11, 2004, 8:26 AM

Post #17 of 42 (3795 views)
Permalink

LRM Testing (take 2) [In reply to]

Alan Robertson wrote:
> Jiang Dong Sun wrote:
>
>> Ok, according to the popular opinion, will change the "uuid"'s format.
>> Before that, please tolerate the inconvenience brought by UUID in LRM
>> for a while. ;-)
>
>
>
>
> I'm sorry I was off the list fixing hardware while all this went on...
>
> The UUID format is the right answer... It is a standard, actually, and
> we should just use it.
>
> Don't mess with it.
>
> However, it is NOT a string, and cannot be strcmp()ed... You can use a
> string provided you NULL-pad the string in every case...
>
> It is a binary value of 128 bits.
>
> Making it of arbitrary length overly complicates the interface because
> you now have to pass the length everywhere you use it - BECAUSE IT IS
> BINARY, not a string.

It should be 128 *arbitrary *bits. If you pass 128 bits, then you win.
There is no such thing as an invalid UUID, when passed as binary.
abc\0\0\0\0\0\0\0\0\0\0\0\0\0" is a valid UUID (assuming I counted \0s right).

--
Alan Robertson <alanr [at] unix>

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

lists at beekhof

Jun 11, 2004, 8:45 AM

Post #18 of 42 (3764 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 11, 2004, at 4:06 PM, Alan Robertson wrote:

> Jiang Dong Sun wrote:
>> Ok, according to the popular opinion, will change the "uuid"'s format.
>> Before that, please tolerate the inconvenience brought by UUID in LRM
>> for a while. ;-)
>
>
>
> I'm sorry I was off the list fixing hardware while all this went on...
>
> The UUID format is the right answer... It is a standard, actually,
> and we should just use it.
>
> Don't mess with it.
>
> However, it is NOT a string, and cannot be strcmp()ed... You can use
> a string provided you NULL-pad the string in every case...
>
> It is a binary value of 128 bits.
>
> Making it of arbitrary length overly complicates the interface because
> you now have to pass the length everywhere you use it - BECAUSE IT IS
> BINARY, not a string.

Two questions:

Why is a UUID automatically the right type for a resource ID? I still
dont see the benefit over a char*.

Why does the LRM care what value we pass in as long as it hasn't been
used before?

And a bonus question since I havent used UUID generators of late:

Do the UUID generators guarantee to produce UUIDs even if the program
was stopped and restarted, or run as a part of different applications?

Andrew

>
> --
> Alan Robertson <alanr [at] unix>
>
> "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
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

lists at beekhof

Jun 11, 2004, 8:52 AM

Post #19 of 42 (3803 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 11, 2004, at 4:45 PM, Andrew wrote:

>
> On Jun 11, 2004, at 4:06 PM, Alan Robertson wrote:
>
>> Jiang Dong Sun wrote:
>>> Ok, according to the popular opinion, will change the "uuid"'s
>>> format.
>>> Before that, please tolerate the inconvenience brought by UUID in
>>> LRM for a while. ;-)
>>
>>
>>
>> I'm sorry I was off the list fixing hardware while all this went on...
>>
>> The UUID format is the right answer... It is a standard, actually,
>> and we should just use it.
>>
>> Don't mess with it.
>>
>> However, it is NOT a string, and cannot be strcmp()ed... You can use
>> a string provided you NULL-pad the string in every case...
>>
>> It is a binary value of 128 bits.
>>
>> Making it of arbitrary length overly complicates the interface
>> because you now have to pass the length everywhere you use it -
>> BECAUSE IT IS BINARY, not a string.
>
> Two questions:
>
> Why is a UUID automatically the right type for a resource ID? I still
> dont see the benefit over a char*.

In the interests of clarity, that should say:

Why is a UUID automatically the right type for a resource ID? I still
dont see the benefit over a UID in the form of a human intelligible
char* (such as prod_intra_apache1).

>
> Why does the LRM care what value we pass in as long as it hasn't been
> used before?
>
> And a bonus question since I havent used UUID generators of late:
>
> Do the UUID generators guarantee to produce UUIDs even if the program
> was stopped and restarted, or run as a part of different applications?
>
> Andrew
>
>>
>> --
>> Alan Robertson <alanr [at] unix>
>>
>> "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
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

alanr at unix

Jun 11, 2004, 9:29 AM

Post #20 of 42 (3777 views)
Permalink

LRM Testing (take 2) [In reply to]

Andrew wrote:
>
> On Jun 11, 2004, at 4:06 PM, Alan Robertson wrote:
>
>> Jiang Dong Sun wrote:
>>
>>> Ok, according to the popular opinion, will change the "uuid"'s format.
>>> Before that, please tolerate the inconvenience brought by UUID in LRM
>>> for a while. ;-)
>>
>>
>>
>>
>> I'm sorry I was off the list fixing hardware while all this went on...
>>
>> The UUID format is the right answer... It is a standard, actually,
>> and we should just use it.
>>
>> Don't mess with it.
>>
>> However, it is NOT a string, and cannot be strcmp()ed... You can use
>> a string provided you NULL-pad the string in every case...
>>
>> It is a binary value of 128 bits.
>>
>> Making it of arbitrary length overly complicates the interface because
>> you now have to pass the length everywhere you use it - BECAUSE IT IS
>> BINARY, not a string.
>
>
> Two questions:
>
> Why is a UUID automatically the right type for a resource ID? I still
> dont see the benefit over a char*.

It is guaranteed unique. It is a standard used in lots of places,
including Linux filesystems

> Why does the LRM care what value we pass in as long as it hasn't been
> used before?

You need to know the semantics for comparision:
Do all bytes count?
Do only bytes up to a NULL count?
Does local character set issues matter?

You need to know the size
Have it be a fixed size (UUID)
Pass a size (arbitrary binary blob)
Have an implicit size (NUL-terminated 'C' string)
Have it be self-describing (Java string, C++ string, etc.)

And, dealing with a fixed size object is simply easier than packing a
variable length string. You can *encode* a UUID into a string. But, then
it's not a UUID, it's a string...

> And a bonus question since I havent used UUID generators of late:
>
> Do the UUID generators guarantee to produce UUIDs even if the program
> was stopped and restarted, or run as a part of different applications?

They will be unique - across reboots, across nodes in a cluster, across the
planet, across the universe, across all time and space. Perfect for Dr.
Who. Very powerful idea.

--
Alan Robertson <alanr [at] unix>

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

alanr at unix

Jun 11, 2004, 9:30 AM

Post #21 of 42 (3772 views)
Permalink

LRM Testing (take 2) [In reply to]

Andrew wrote:
>
> On Jun 11, 2004, at 4:45 PM, Andrew wrote:
>
>>
>> On Jun 11, 2004, at 4:06 PM, Alan Robertson wrote:
>>
>>> Jiang Dong Sun wrote:
>>>
>>>> Ok, according to the popular opinion, will change the "uuid"'s format.
>>>> Before that, please tolerate the inconvenience brought by UUID in
>>>> LRM for a while. ;-)
>>>
>>>
>>>
>>>
>>> I'm sorry I was off the list fixing hardware while all this went on...
>>>
>>> The UUID format is the right answer... It is a standard, actually,
>>> and we should just use it.
>>>
>>> Don't mess with it.
>>>
>>> However, it is NOT a string, and cannot be strcmp()ed... You can use
>>> a string provided you NULL-pad the string in every case...
>>>
>>> It is a binary value of 128 bits.
>>>
>>> Making it of arbitrary length overly complicates the interface
>>> because you now have to pass the length everywhere you use it -
>>> BECAUSE IT IS BINARY, not a string.
>>
>>
>> Two questions:
>>
>> Why is a UUID automatically the right type for a resource ID? I still
>> dont see the benefit over a char*.
>
>
> In the interests of clarity, that should say:
>
> Why is a UUID automatically the right type for a resource ID? I still
> dont see the benefit over a UID in the form of a human intelligible
> char* (such as prod_intra_apache1).

Because UUIDs are guaranteed to be unique. Strings are not. You're more
than welcome to keep a corresponding human string, and I'd recommend it.
For testing, you can make them the same (if you pad with zeros).

--
Alan Robertson <alanr [at] unix>

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

lists at beekhof

Jun 11, 2004, 9:55 AM

Post #22 of 42 (3784 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 11, 2004, at 5:28 PM, Alan Robertson wrote:

> Andrew wrote:
>> On Jun 11, 2004, at 4:45 PM, Andrew wrote:
>>>
>>> On Jun 11, 2004, at 4:06 PM, Alan Robertson wrote:
>>>
>>>> Jiang Dong Sun wrote:
>>>>
>>>>> Ok, according to the popular opinion, will change the "uuid"'s
>>>>> format.
>>>>> Before that, please tolerate the inconvenience brought by UUID in
>>>>> LRM for a while. ;-)
>>>>
>>>>
>>>>
>>>>
>>>> I'm sorry I was off the list fixing hardware while all this went
>>>> on...
>>>>
>>>> The UUID format is the right answer... It is a standard, actually,
>>>> and we should just use it.
>>>>
>>>> Don't mess with it.
>>>>
>>>> However, it is NOT a string, and cannot be strcmp()ed... You can
>>>> use a string provided you NULL-pad the string in every case...
>>>>
>>>> It is a binary value of 128 bits.
>>>>
>>>> Making it of arbitrary length overly complicates the interface
>>>> because you now have to pass the length everywhere you use it -
>>>> BECAUSE IT IS BINARY, not a string.
>>>
>>>
>>> Two questions:
>>>
>>> Why is a UUID automatically the right type for a resource ID? I
>>> still dont see the benefit over a char*.
>> In the interests of clarity, that should say:
>> Why is a UUID automatically the right type for a resource ID? I
>> still dont see the benefit over a UID in the form of a human
>> intelligible char* (such as prod_intra_apache1).
>
>
> Because UUIDs are guaranteed to be unique. Strings are not. You're
> more than welcome to keep a corresponding human string, and I'd
> recommend it. For testing, you can make them the same (if you pad with
> zeros).

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?

>
> --
> Alan Robertson <alanr [at] unix>
>
> "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
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

lmb at suse

Jun 11, 2004, 9:56 AM

Post #23 of 42 (3769 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-11T09:26:34,
Alan Robertson <alanr [at] unix> said:

> They will be unique - across reboots, across nodes in a cluster, across the
> planet, across the universe, across all time and space. Perfect for Dr.
> Who. Very powerful idea.

They are unique with a probability of 1 to 2^128 - which is >< this
close to infinitely likely to be unique. But iff you write another
paragraph like that, you are tempting Murphy! ;-)

Sincerely,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

lists at beekhof

Jun 11, 2004, 10:02 AM

Post #24 of 42 (3772 views)
Permalink

LRM Testing (take 2) [In reply to]

On Jun 11, 2004, at 5:55 PM, Lars Marowsky-Bree wrote:

> On 2004-06-11T09:26:34,
> Alan Robertson <alanr [at] unix> said:
>
>> They will be unique - across reboots, across nodes in a cluster,
>> across the
>> planet, across the universe, across all time and space. Perfect for
>> Dr.
>> Who. Very powerful idea.
>
> They are unique with a probability of 1 to 2^128

A theoretical probability not counting bugs and design flaws of course
:)

> - which is >< this
> close to infinitely likely to be unique. But iff you write another
> paragraph like that, you are tempting Murphy! ;-)
>
>
> Sincerely,
> Lars Marowsky-Br?e <lmb [at] suse>
>
> --
> High Availability & Clustering \ ever tried. ever failed. no
> matter.
> SUSE Labs | try again. fail again. fail better.
> Research & Development, SUSE LINUX AG \ -- Samuel Beckett
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev [at] lists
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/

lmb at suse

Jun 11, 2004, 10:06 AM

Post #25 of 42 (3787 views)
Permalink

LRM Testing (take 2) [In reply to]

On 2004-06-11T17:55:47,
Andrew <lists [at] beekhof> 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.

Sincerely,
Lars Marowsky-Br?e <lmb [at] suse>

--
High Availability & Clustering \ ever tried. ever failed. no matter.
SUSE Labs | try again. fail again. fail better.
Research & Development, SUSE LINUX AG \ -- Samuel Beckett

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads