Thomas Lamprecht napsal(a):
On 09/20/2016 12:36 PM, Christine Caulfield wrote:
On 20/09/16 10:46, Thomas Lamprecht wrote:

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

# 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 (local)
          2          1 due
          3          1 tre

And respective:

# corosync-quorumtool -l

Membership information
     Nodeid      Votes Name ring0_addr
          1          1 uno (local)
          2          1 due
          3          1 tre
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 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 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
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 :)


Hi Chrissie,

Thanks for your answer!


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


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.



Users mailing list:

Project Home:
Getting started:

Users mailing list:

Project Home:
Getting started:

Reply via email to