[ClusterLabs] corosync-quorum tool, output name key on Name column if set?

[Jan Friesse]

Thomas Lamprecht napsal(a):
> On 09/20/2016 12:36 PM, Christine Caulfield wrote:
>> On 20/09/16 10:46, Thomas Lamprecht wrote:
>>> Hi,
>>>
>>> when I'm using corosync-quorumtool [-l] and have my ring0_addr set to a
>>> IP address,
>>> which does not resolve to a hostname, I get the nodes IP addresses for
>>> the 'Name' column.
>>>
>>> As I'm using the nodelist.node.X.name key to set the name of a node it
>>> seems a bit confusing
>>> to me that not this one gets preferred or at least also outputted. Its
>>> quite a minor issue if
>>> not nit picking but as I associate my nodes with there name I.
>>>
>>> I'd be ready to assemble a patch and one possibility would be adapting
>>> the output to something
>>> like:
>>>
>>>> # corosync-quorumtool
>>>>
>>>> Quorum information
>>>> ------------------
>>>> Date:             Tue Sep 20 11:12:14 2016
>>>> Quorum provider:  corosync_votequorum
>>>> Nodes:            3
>>>> Node ID:          1
>>>> Ring ID:          1/1784
>>>> Quorate:          Yes
>>>>
>>>> Votequorum information
>>>> ----------------------
>>>> Expected votes:   3
>>>> Highest expected: 3
>>>> Total votes:      3
>>>> Quorum:           2
>>>> Flags:            Quorate
>>>>
>>>> Membership information
>>>> ----------------------
>>>>      Nodeid      Votes Name ring0_addr
>>>>           1          1 uno  10.10.20.1 (local)
>>>>           2          1 due  10.10.20.2
>>>>           3          1 tre  10.10.20.3
>>>>
>>> And respective:
>>>
>>>> # corosync-quorumtool -l
>>>>
>>>> Membership information
>>>> ----------------------
>>>>      Nodeid      Votes Name ring0_addr
>>>>           1          1 uno  10.10.20.1 (local)
>>>>           2          1 due  10.10.20.2
>>>>           3          1 tre  10.10.20.3
>>> additional ring1_addr could be also outputted if set.
>>>
>>> This would be just a general idea, if there are suggestions I'll gladly
>>> hear them.
>>>
>>> As such a change may be not ideal during a stable release, e.g as
>>> corosync user could
>>> parse the corosync-quorumtool output (I mean there are quite better
>>> places to get the
>>> info but there may be still user doing this)  another possibility would
>>> be adding an
>>> option flag to corosync similar to '-i' (show node IP addresses instead
>>> of the resolved
>>> name) which then shows the nodelist.node.X.name value instead of IP or
>>> resolved name.
>>>
>>> Another, third, option would be letting the output as is but if the '-i'
>>> option is not
>>> set prefer the nodelist.node.X.name over the resolved hostname and fall
>>> back to IP if
>>> both are not available.
>>> I'd almost prefer this change the most, it lets the output as it is and
>>> it seems logical
>>> that the Name column outputs the name key if possible, imo.
>>>
>>> Would such a patch be welcomed or is this just something I find a little
>>> strange?
>> Hi Tomas,
>>
>> I'd be happy to receive such a patch. The main reason it's not done this
>> way is that it's not always obvious how to resolve a name from it's IP
>> address. If corosync.conf has a nodelist then using that does seem like
>> the best option though (and bear in mind that more than 1 ring is
>> possible). If corosync.conf is set up to use multicast then we have no
>> choice to guess at what the name might be (as happens now).
>>
>> Most of corosync-quorumtool was written when nodelist was not the
>> dominant way of configuring a cluster which is why it is the way it is
>> at the moment.
>>
>> As to what should be the default and which options are most useful, I
>> would be interested to hear the views of the community as to what they
>> would like to see :)
>>
>> Chrissie
>
> Hi Chrissie,
>
> Thanks for your answer!
>

Thomas,

> OK, then I'll look into it a bit more and try to figure out which options
> really could make sense, if earlier code hadn't the nodelist configuration
> wasn't that dominant, I may find other places too where it could be used
> for
> outputs or as input parameter.
>
> You mean if corosync.conf is setup without nodelist, just with multicast?

I believe so. Simply because nodelist is pretty new concept (2.x).

> As with the nodelist section configured multicast is also possible, asking
> just to understand you correctly.
>
> Yes, would be nice to get some input here, I'll wait a bit, else I'll
> send a
> patch to get the discussion going. :)
>
> I have also another, organizational question. I saw on the GitHub page from
> corosync that pull request there are preferred, and also that the

True

> communication should occur through GitHub, so should I use GitHub
> instead of
> the clusterlabs list for mails like my initial one from this thread?

Nope, not necessarily. Way "First discuss on ML then send PR" works very 
same as "Open issue, discuss and then send PR". Actually from time to 
time ML way is better because you get broader audience.

Regards,
   Honza

>
> Thanks,
> Thomas
>
>
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org