[Pacemaker] override node name when using cman

[Patrick H.]

Sent: Thu Aug 30 2012 23:00:25 GMT-0400 (EDT)
From: Andrew Beekhof <andrew at beekhof.net>
To: Patrick H. <pacemaker at feystorm.net> The Pacemaker cluster resource 
manager <pacemaker at oss.clusterlabs.org>
Subject: Re: [Pacemaker] override node name when using cman
> On Wed, Aug 29, 2012 at 11:59 PM, Patrick H.<pacemaker at feystorm.net>  wrote:
>> Sent: Wed Aug 29 2012 08:00:53 GMT-0400 (EDT)
>> From: Andrew Beekhof<andrew at beekhof.net>
>> To: The Pacemaker cluster resource manager<pacemaker at oss.clusterlabs.org>
>> Subject: Re: [Pacemaker] override node name when using cman
>>
>>> On Wed, Aug 29, 2012 at 4:56 AM, Patrick Hemmer<pacemaker at feystorm.net>
>>> wrote:
>>>> It looks like when using pacemaker with cman, pacemaker gets the name of
>>>> the
>>>> node from the<clusternode>   'name' attribute. Is there any way to
>>>> override
>>>> this?
>>> Basically no.  Nodes need to be addressable by whatever name is supplied.
>> Can this be put in as a feature request? It doesn't make sense to call a
>> node by the name of it's interface. Also cman is more than happy to let you
>> put IPs in the<clusternode>  and<altname>  'name' attribute (making things
>> less ambiguous is always a good thing). But Having to identify the node (in
>> crm shell) by the IP address of one of it's interfaces is just not right.
> Wait. What now?
> We don't require (or want) people to use IP addresses as node names.
>
> The requirement is that the 'name' attribute needs to match the output
> of 'uname -n'.
> Although I just posted a lengthy email about a plan to remove the
> 'uname -n' requirement in most cases.
I completely agree, using an IP as a node name is not desirable. But as 
pacemaker pulls the node name from the <clusternode> 'node' parameter, 
that's what happens.

Maybe if I provided an example you'd see why I'm considering this a 
significant issue. So lets assume I have the following config:
<clusternode nodeid='1' name='192.168.0.1'>
<altname name='hanode01' />
</clusternode>
<clusternode nodeid='2' name='192.168.0.2'>
<altname name='hanode02' />
</clusternode>

Now in the above example, the 'hanode01' has 2 interfaces, the eth0 
public interface, and an eth1 secondary interface. The eth1 interface is 
connected via crossover to 'hanode02', and I want to use this link as 
the primary link for communication between machines (maybe it's a faster 
connection, maybe it's more reliable, or something else). As such this 
interface has to be listed in the <clusternode> 'name' attribute (and 
not <altname>) for it to be used as the primary interface. In this 
example I put the IP in the config (but I could also just add an entry 
to /etc/hosts with '192.168.0.1 hanode01-eth1' and use 'hanode01-eth1' 
as the name). So pacemaker ends up using '192.168.0.1' as the name of 
the node. If I were to put a 'hanode-eth1' entry in /etc/hosts, 
pacemaker would still end up using 'hanode-eth1' as the node's name. 
Neither one of these is the value of `uname -n` or `hostname`.

>
>>>> If the node has multiple interfaces, I may want corosync to use an
>>>> interface
>>>> other than the node's main interface as the main interface for
>>>> communication
>>>> (like if I had a crossover cable between nodes). If I use the IP of the
>>>> second interface then pacemaker uses that IP as the node name. If I give
>>>> the
>>>> second interface a name, it still ends up using that name instead of the
>>>> node's real name (`uname -n`).
>>>>
>>>> _______________________________________________
>>>> 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
>>> _______________________________________________
>>> 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