[Pacemaker] RFC: Any interesting in 2.0.0 betas?

[Andrew Beekhof]

On reflection, I think making this configurable is going to cause more
trouble than its worth.
Any sysconfig mismatch between the nodes would result in major breakage.

We need to pick one way and make it the default - if people want/need
anything else, they need to use the corosync node list.
For consistency with older releases, I think your original "strip
everything" patch is the best way to go.

On Fri, Oct 26, 2012 at 9:57 PM, Vladislav Bogdanov
<bubble at hoster-ok.com> wrote:
> 26.10.2012 13:38, Vladislav Bogdanov wrote:
>> 26.10.2012 12:43, Andrew Beekhof wrote:
>> ...
>>>> May be also set it forcibly to uname if uname contains full lexem found
>>>> in dns name?
>>>
>>> Run that past me again?
>>
>> I mean that if ip address resolves to fqdn, and that fqdn begins with
>> what uname call returns (so both node itself and DNS agree on a node
>> name for a node with give IP address), then that value from uname could
>> be safely used directly.
>
> Ah, that is for local node only...
> For remote nodes I would strip FQDN part which begins right at that dot
> where FQDN of local node and its uname differ.
>
> my_ring_address == 10.0.0.XXX
> my_uname() == "host232"
> getaddinfo(my_ring_address) == host232.some.very.long.domain.name.com.
>
> my_node_name = "host232"
> my_domain = "some.very.long.domain.name.com."
>
> his_ring_address == 10.0.0.YYY
> getaddinfo(his_ring_address) == host238.some.very.long.domain.name.com.
>
> strstr("host238.some.very.long.domain.name.com.", my_domain) != NULL
>
> his_node_name = "host238"
>
>
>>
>> To illustrate:
>> ring_address == 10.0.0.XXX
>> uname() == "host232"
>> getaddinfo(ring_address) == host232.some.very.long.domain.name.com.
>>
>> then "host232" could be safely used as a node name (but not "host23" and
>> not "host232.s")
>>
>> Of course, it would be even more safe if gentnameinfo("host232") or
>> getnameinfo("host232.some.very.long.domain.name.com.") returns
>> 10.0.0.XXX, so additional check may be introduced.
>>
>> That is normal for "correct" static DNS setups, where PTR record is
>> consistent with what node has configured as a hostname internally.
>>
>> That is also what I have for DHCP-based static address assignments
>> (central configuration place for a whole cluster network), where node
>> usually sets (or at least can be configured to set) its name to what
>> DHCP server says. And DHCP server is usually set up to update A and PTR
>> records in DNS zone.
>>
>> Also that should work correctly when FQDN is used as an uname (long
>> hostname), like redhat setups usually do.
>>
>> Anyways, if FQDN does not begin with uname, then DNS info should be used
>> for node name (like it is now), possibly with that "strip" hack. That
>> could be useful for multi-ring setups I think.
>>
>> Vladislav
>>
>>
>> _______________________________________________
>> 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