[Pacemaker] RFC: Any interesting in 2.0.0 betas?

[Vladislav Bogdanov]

30.10.2012 04:27, Andrew Beekhof wrote:
> 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.

That is OK for me as I currently use it.

Although I'd ask you to think again about stripping "known" domain name
part from resolver-provided FQDN if uname and FQDN of local node match
at the beginning. Something says me this would provide better backwards
compatibility, while visible result for the discussed use-case will be
exactly the same. I know at least one cluster (not mine) which will be
broken if just to strip everything at the first dot - it uses long
hostnames (and this is the default for a fresh-installed redhat/fedora
if you enter FQDN in the anaconda prompt when installing a node).

Also, way I propose provides better flexibility - assume that one sets
hostname using two lexems from FQDN - node01.cluster01 (or n01.c01)
instead of just node01 or n01. FQDN itself could be
n01.c01.some.location.domain.com. That could be done just to add safety
for shell actions - hostname is usually shown in the shell prompt (I
recall many cases when I issued command on a different host from I
thought I do it on). The same applies to cluster commands. If visible
nodenames have some (administrator controlled) hints, cluster could be
safer to operate. And this way should not cause any breakage - cluster
node are usually named the same way and no additional configuration is
involved.

I can develop patch for that if you want. It would introduce one global
var (domain name), and will have one extra call to uname() and three or
less calls to string-handling functions.

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