[Pacemaker] RFC: Any interesting in 2.0.0 betas?

[Vladislav Bogdanov]

25.10.2012 07:50, Andrew Beekhof wrote:
> On Thu, Oct 25, 2012 at 3:08 PM, Vladislav Bogdanov
> <bubble at hoster-ok.com> wrote:
>> 25.10.2012 04:47, Andrew Beekhof wrote:
>>> Does anyone out there have the capacity and interest to test betas of 2.0.0 if I release them?
>>
>> Sure.
>>
>>> If so, for what distro and version?
>>
>> Git tag would be enough for me.
> 
> "HEAD" ? :-)

Yeah, it is usually enough too, but it is better to know that you
consider some revision to be "stable enough" or at least "not broken
very much" so it is tagged. :)

One issue we discussed earlier - node names in CIB. I saw you did the
move from uname to a consistent resolving after 1.1.8 I currently
evaluating (with my patch I sent earlier), But, I did not see any code
for node name post-processing in case of DNS with FQDN names. So, in
case on DNS-only setup (without /etc/hosts) node names will contain what
reverse DNS lookup returns.

What I would expect to be "right" is to have DNS _domain_ name (what
dnsdomainname returns, actually everything after the first dot) stripped
from them. On the other hand, I saw setups where node names were made
FQDN intentionally to differentiate between clusters in crm_mon output.
Although IMHO it could be convenient for two-node clusters, in case of
8-16 nodes that output becomes a mess. Actually in my clusters I have
FQDNs longer than 35 characters, with host names of 4-5 chars. And I
feel much better when I do not need to parse two or three lines of text
by eyes just to determine on which node do I have a problem.

So, I think it would be nice to have a way to affect how cluster node
name is constructed in case of DNS-resolved names without need to patch
code. F.e. "leave as is", "strip after Nth dot", "strip what is in
'domain' clause in /etc/resolv.conf", "strip what is in Nth part of
'search' clause in /etc/resolv.conf", "strip what is in
'totem.cluster_name' corosync parameter", etc. Sure, that should be
consistent over the whole cluster, but that is another story.


Best,
Vladislav