01.11.2012 03:28, Andrew Beekhof wrote:
> On Tue, Oct 30, 2012 at 5:13 PM, Vladislav Bogdanov
> <bub...@hoster-ok.com> wrote:
>> 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.
>
> Again though, uname() only works for the current node.
> You can't know what the other nodes are using - and by extension if
> you should strip their name as well.
But you can guess it, as admins usually name nodes the same way. If not
- that is problem of admins.
>
>> 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).
>
> How do they configure corosync.conf / cluster.conf though?
That is for corosync1. But when/if they decide to migrate to corosync2 -
they will have the broken cluster (because of location constraints do
not work too).
> The stripping only applies when people put IP addresses in there (or
> use multicast without a node list).
>
> If people put node names we will use them unmodified.
> Adding a node list is recommended by upstream corosync, so it makes
> sense for us to use it as the official way to use a non-default naming
> scheme.
>
>>
>> Also, way I propose provides better flexibility
>
> It feels more fragile to me. Its going to break really badly if some
> nodes use FQDN and some dont.
That would be the side effect of having zoo in network instead of
well-defined structure. Not your problem.
Well, that should not work for 1.1.8 too...
And, does that work for corosync1?
>
>> - 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
>>> <bub...@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@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@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@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@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@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@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
