lmb at suse
Jun 16, 2004, 3:43 PM
Post #1 of 1
(285 views)
Permalink
|
|
Settled: UUID for nodes & resources
|
|
Hi all,
Alan and I just had a very effective phone call on this matter, with two
important results.
Summary (more detail below):
1. We are going to keep UUIDs for identifying nodes.
2. For resource naming in the CIB and between the CRM/LRM, we are going
to switch to char * with a maximum length of 128 octets (including the
\0) in UTF-8.
=> Andrew, this affects the resource.id field in the CIB. IBM team, this
is an API change. uuid_t becomes char * for the LRM API.
Details:
1. UUIDs for nodes in the messaging & membership layers are somewhat
difficult, but in the bigger picture, they allow for clusters merging
even if node names themselves clash (think two companies merging data
centers because of an acquisition...), and inherently decouple the node
name from the node id; which means we won't have so much problems with
those silly applications which require the hostname to be set for
licensing reasons etc. They are still a bit more painful, but we believe
it's worth the hassle.
Also, the OCF APIs for membership specify UUIDs for nodes. (Historical:
Partly because we couldn't agree on node numbers or node names as
identifiers ;-)
So here, we are going to continue to use them. Mapping the UUID to a
meaningful name is something for which the CRM GUI can use the CIB data,
and the STONITH layer will have to handle it somewhere too. Everyone
else please do NOT refer to nodes by unames but by UUIDs.
This implies that we need to have a messaging layer capable of sending
to/from UUID node ids etc. This needs to be put into place ASAP, or at
least be mapped somehow.
(alanr suggests that we have a library call to map from/back UUIDs for
these applications which still need it.)
2. For the resource naming (and other objects in the CIB), a UUID is
believed to not be the right choice any longer.
Instead, we agreed on a UTF-8 string of a maximum length of 128 bytes
including the \0. The size limit puts an upper bound on memory useage,
packet size etc and thus is a good idea. 128 bytes ought to be enough
for everybody! ;)
UTF-8 has several advantages: Programmatically, it's just an ASCII
string (7bit even); XML can handle it just fine, and it can be
descriptive to the user in his local language if he wants to.
Internally, we are not supposed to care about whatever it ends up being,
except for enforcing the length limit and the uniqueness.
If he ends up chosing a name in the GUI which he can't type at the
command line, that's HIS problem, not ours, though the GUI may suggest
that it's a string encodable in the POSIX charset; it's not our problem
in the end, in particular not if he edits the CIB manually with
vi/emacs. If he is sane, he uses a short ascii string, if he is not, oh
well ;-)
So, the CRM/LRM enforces the uniqueness on their objects, and obviously
everybody gets to check their size limits. Beyond that, we treat the
string as a fully opaque object which we just use for input/output.
This in particular also means that shell scripts should use proper
quoting around the string etc.
Andrew, the resource.description field is probably obsolete now, unless
we want to keep it as a "note" field for whatever memos the admin/user
wants to keep track of for a given resource; but we don't use it for
anything else anyway.
Alan, I hope this sums it up and I didn't leave out anything important
here. I'm tired, I'll let you take up from here ;-)
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
|
