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

[Lars Marowsky-Bree]

On 2004-06-14T07:55:54,
   Alan Robertson <alanr at unix.sh> said:

> You mean log files always have to be in English? 

No, I don't mean that, even if the Linux kernel itself adheres to this
policy and leaves translation to appropriate user-space tools, because
any other way lies madness for low-level tools. Even the cluster: The
logging is not meant for consumption by end-users, but by admins. And
any admin on Linux will need to know at least some English, surely
enough to name a resource.

The argument is that we need a unique short identifier which the user
can use for interacting with the system. Localizing it is NOT GOING TO
MAKE US HAPPY. Trust me. That way lies madness. Unless we mandate the
encoding etc, so there are no conversion issues. I propose we do that
right after Unix login names have been localized ;-)

And UUIDs are not going to make users happy. They are a pain to spell
and require cut & paste all the way if you want to go from the logfile
to the command line tools.

> 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.

Heh, you are exactly reversing my argument ;-) 

I just don't want to impose the UUIDs on anyone. It's painful. It's
vicious to enter on the commandline and make sense of the logfiles. 

The logfiles need to be meaningful to admins and developers. I do not
WANT a logfile in which everything is referenced by localized japanese.
I'd rather replace the UUID with a short identifier and make it
configurable by the user. Solves two problems at once.

So yes, maybe the "native language" description is superfluous too, and
it's more like a note field in the GUI. Who knows.

> There is no way that anyone other than the developers on this project will 
> every be able to generate correct XML for configurations. 

Uh? It's plain XML, ie text. And not very complex either. Anyone who can
generate an Apache configuration file by hand or write a shell script
sure should be able to do that too.

> Therefore, arguments about the difficulty of generating uuids by hand are 
> irrelevant.

I disagree strongly. The configuration MUST be creatable by hand by a
competent admin.

One might try to argue that a UUID is not that difficult to enter, sure,
but the presumption that the only way to generate the configuration is
by GUI is not acceptable.

Anyway, the argument is that we need to validate the CIB as it comes in
and make sure what we were fed as a UUID is indeed unique within the
CIB, and thus we already do that validation anyway, and can just as well
do it for an ASCII string.

A UUID doesn't convey any sensible information beyond being unique.
That's not helpful for a user interface, neither logging nor command
line.

No user is going to tell us to move d50d0980-26ab-46ba-ab54-967609713f51
to node 2a2494de-430e-40af-a80b-eefbc333397d; they are going to tell us
to move the resource ip-web-1 to geronimo. Nobody would accept the first
as a CLI.

So, in any case, I'm not going to get too religious about it. If you
insist that we carry along a UUID, so be it, I just think it's perfectly
void of meaning to have two unique identifiers. We need one, and I'd
rather make that an ASCII string. If someone insists, uuidgen also
generates ASCII output, so we can have both.


Sincerely,
    Lars Marowsky-Brée <lmb at suse.de>

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