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@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
_______________________________________________
Users mailing list: Users@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
