[Pacemaker] pacemaker service start failed.

[Andrew Beekhof]

On Fri, Nov 2, 2012 at 4:57 PM, Yuusuke Iida <iidayuus at intellilink.co.jp> wrote:
> Hi, Andrew
>
>
> (2012/10/30 13:51), Andrew Beekhof wrote:
>>
>> On Mon, Oct 29, 2012 at 7:10 PM, Yuusuke Iida
>> <iidayuus at intellilink.co.jp> wrote:
>>>
>>> Hi, Andrew
>>>
>>>
>>> (2012/10/26 9:31), Andrew Beekhof wrote:
>>>>>
>>>>>
>>>>> When I described the IP which I used in ring0 in /etc/hosts, I
>>>>> confirmed
>>>>>>
>>>>>> that start of pacemaker succeeded.
>>>>>>
>>>>
>>>> [moved first question to the end]
>>>
>>>
>>> I understood that name solution was necessary.
>>>
>>>
>>>>
>>>>>> Was there any problem with a conventional method to use uname()?
>>>>
>>>>
>>>> The problem with uname() is that your peers don't know the value until
>>>> you send it to them.
>>>> Which creates a conceptual race condition - how do you send a message
>>>> to (or fence) a peer who's name you don't know yet?
>>>
>>>
>>> sorry, I did not understand it a little.
>>> What kind of situation is it?
>>
>>
>> Mostly during startup.
>> Since corosync only knows nodeids, that is all we know about our peers
>> until they send us a message (which contains their name).  So if we
>> need to send them a message before we hear from it, then we have no
>> way to how to address it.  Likewise, if one suffers a failure we have
>> no idea who to shoot.
>
> I understood these problems.
>
>
>>
>>>>>> Will setting to convert IP of such ring0 into the name be necessary by
>>>>>> all
>>>>>> means in future?
>>>>
>>>>
>>>> In a word "no":-)
>>>>
>>>> There are a couple of options:
>>>>
>>>> - you can specify the names to use in corosync.conf (nodelist)
>>>>     using a nodelist doesn't prevent you from using multicast
>>>>
>>>> - you can setup /etc/hosts as you did above
>>>>
>>>> - I have just now re-instated the uname() default for corosync 2.0
>>>> cluster types.  It didn't occur to me that people wouldn't set up
>>>> anything:-)
>>>>     The patch is:https://github.com/beekhof/pacemaker/commit/9a81945
>>>> can you give it a try?
>>>
>>>
>>> I tried this correction.
>>> The correction seems to run without a problem.
>>
>>
>> I will probably amend that patch to drop everything after the first '.'
>> Does that sound like a good idea to you?
>
> Because I do not so know a lot in FQDN, there is not the good idea.
>
> I am worried about the problem that is different from this.
>
> When the name that I got in "uname -n" is different from the name that I got
> in name solution,
> A thing treating using "uname -n" in RA might not work.
>
> pgsql and mysql use "uname -n" as representative RA.
>
> For example, it is the following cases.
> uname: node1
> DNS(or /etc/hosts): node1_eth1
>
> How do you think about this?

A bit of an update....

The reverse lookup functionality has turned out to cause far more
problems and confusion than it was intended to solve.
So I am basically removing it.  Anyone worried about that
bootstrapping case will be encouraged to use a corosync nodelist.

Below is the new section I added to the asciidoc documentation yesterday:


== Where Pacemaker Gets the Node Name ==

Traditionally, Pacemaker required nodes to be referred to by the value
returned by `uname -n`.  This can be problematic for services that
require the `uname -n` to be a specific value (ie. for a licence
file).

Since version 2.0.0 of Pacemaker, this requirement has been relaxed
for clusters using Corosync 2.0 or later.  The name Pacemaker uses is:

. The value stored in 'corosync.conf' under +ring0_addr+ in the
+nodelist+, if it does not contain an IP address; otherwise
. The value stored in 'corosync.conf' under +name+ in the +nodelist+; otherwise
. The value of `uname -n`

Pacemaker provides the `crm_node -n` command which displays the name
used by a running cluster.

If a Corosync nodelist is used, `crm_node --name-for-id $number` is also
available to display the name used by the node with the corosync
+nodeid+ of '$number', eg. `crm_node --name-for-id 2`