[Pacemaker] getnameinfo() vs uname()

[Andrew Beekhof]

On Fri, Aug 31, 2012 at 5:55 PM, Lars Marowsky-Bree <lmb at suse.com> wrote:
> On 2012-08-31T12:43:20, Andrew Beekhof <andrew at beekhof.net> wrote:
>
>> [1] We will implement equivalent functions for the other cluster types.
>> [2] The nodelist section looks something like:
>> nodelist {
>>     node {
>>         nodeid: 1
>>         ring0_addr: pcmk-1
>>         quorum_votes: 1
>>     }
>>     node {
>>         nodeid: 2
>>         ring0_addr: pcmk-2
>>         quorum_votes: 2
>>     }
>> }
>
> A statically configured node list inside pacemaker?

God no.  Thats (optionally) in corosync.conf
Its analogous to a list of ucast entries in ha.cf

>
> I must be missing something here (if so, as usual, please forgive me
> ;-). But the nodes already have a unique identifier (the nodeid, which
> they assign for themselves, and which is used internally).
>
> Obviously, nobody wants to read nodeids in logs, especially not the
> auto-generated ones.
>
> But shouldn't the nodes announce their name (either locally configured,
> or auto-picked from uname().nodename) too, and then other nodes should
> update their mapping?
>
> Isn't, like, that was is already happening? Why do we need an explicit
> nodelist, or am I missing something?

Pacemaker doesn't now and never will.  But /IF/ its already there, we
might as well use it.
For instance, since fencing is name based, it is useful to know the
name of nodes we've never seen before (otherwise we can't shoot them).

If you check the archives, you'll see I was very vocal in preventing
the nodelist from being made mandatory at the corosync level.
So you're a little late, but welcome to the party :)

What I was mostly talking about is avoiding needing everything to be
set to 'uname -n' (because we use node names in some places, uname -n
in others, and method $X in still others).
So IF you have a node list, and IF you set it to something other than
'uname -n', Pacemaker wont crap out.

> If this is just about a mechanism for configuring the *local* name (and
> in fact distribute it dynamically), I'd advise to not keep that in
> corosync.conf, but in, say, /etc/corosync/local/uname by default. Then
> one doesn't have to redistribute corosync.conf to all nodes just because
> one node is added, and still can keep it identical across all nodes.
>
>
> Regards,
>     Lars
>
> --
> Architect Storage/HA
> SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org