corosync-quorumtool: print totem cluster information - #504

Can one of the admins verify this patch?

@ThomasLamprecht I like the patch (- some small nitpicks, like config_version is not strictly required so it shouldn't be reason for failure) and general idea, but I'm not so convinced it should be in the corosync-quorumtool. I mean, why corosync-quorumtool? Also the information is available via corosync-cmapctl, so does it really make sense to have duplicity? Another problem is, that it is really hard (at least for me) to tell, which information should be displayed? What is the most useful for user without being to overwhelming?

Actually, I was thinking about some tool like crm_report for quite a some time. Maybe such tool may display "important" information in default mode and do more elaborated dump in some kind of "bug report mode".

Thanks for taking a look.

Now, why corosync-quorumtool: So first, we have a small cluster status CLI command in Proxmox VE which does a few basic checks for hints to the user and then just execs "corosync-quorumtool".
This is done as "corosync-quorumtool" really looks like a neat cluster status overview, you see all nodes, qdevice, vote information, .. in short, relevant information about a cluster and it's health state, from a user perspective it could also be named "corosync-status", or the like, IMO no user would question that name.

I wanted to add this info to our tool, already applied a patch0 but then thought, hey often our user mix invocating "pvecm status" (our "tool") and "corosync-quorumtool" in our Forum, and this info is nice to have in general, so maybe just add it upstream. This naturally would has the side benefit that I do not have to do config/cmap parsing (not hard but if it can be avoided) and still get the most current info from the corosync POV.
So that was my rationale to add it there, even if it wasn't 100% ideal from the tool name and it's intended purpose.

The rationale for the information I added is:

• cluster name: nice to re-confirm an admin is operating at the correct cluster or to ensure that this is really unique (was more important in mcast times)
• config_version: makes it easy to see if a node has an old config (out of sync?)
• transport: just nice to have, especially if one tries out another one and want's to confirm the change is active.
• secauth: IMO it's important to know if my cluster communication is really encrypted if I'm on an untrusted, or just not private, network.

But yes, displaying more is hard to decide. So IMO it's good to start rather small and add was user think is useful. Almost all of above was requested by some users over different channels the last years, so that information seems of real use.

A crm_report could be nice too, IMO.

Thanks for taking a look.

Now, why corosync-quorumtool: So first, we have a small cluster status CLI command in Proxmox VE which does a few basic checks for hints to the user and then just execs "corosync-quorumtool".
This is done as "corosync-quorumtool" really looks like a neat cluster status overview, you see all

Indeed

nodes, qdevice, vote information, .. in short, relevant information about a cluster and it's health state, from a user perspective it could also be named "corosync-status", or the like, IMO no user would question that name.

And that is the thing. What about having something like corosync-status (maybe just shell script) which would call quorumtool, cmapctl, ... and gather required information? Together with parameter like --report it may behave more like crm_report?

I wanted to add this info to our tool, already applied a patch0 but then thought, hey often our user mix invocating "pvecm status" (our "tool") and "corosync-quorumtool" in our Forum, and this info is nice to have in general, so maybe just add it upstream. This naturally would has the side benefit that I do not have to do config/cmap parsing (not hard but if it can be avoided) and still get the most current info from the corosync POV.

Yep. Just to make sure we are on same page. I like the idea. I'm just not too keen to add information about cluster to quorumtool which is designed to display quorum/votequorum information.

So that was my rationale to add it there, even if it wasn't 100% ideal from the tool name and it's intended purpose.

The rationale for the information I added is:

* cluster name: nice to re-confirm an admin is operating at the correct cluster or to ensure that this is really unique (was more important in mcast times)

Agree. It's also identifier and I believe it is used by admins to distinguish between multiple clusters.

* config_version: makes it easy to see if a node has an old config (out of sync?)

Yep. It just don't need to be there so it shouldn't be fatal error if it is not found.

* transport: just nice to have, especially if one tries out another one and want's to confirm the change is active.

Yep

* secauth: IMO it's important to know if my cluster communication is really encrypted if I'm on an untrusted, or just not private, network.

I would rather see crypto_hash/cypher, because secauth is really compatibility "hack", but I agree in general.

But yes, displaying more is hard to decide. So IMO it's good to start rather small and add was user think is useful. Almost all of above was requested by some users over different channels the last years, so that information seems of real use.

Good to know.

A crm_report could be nice too, IMO.

nodes, qdevice, vote information, .. in short, relevant information about a cluster and it's health state, from a user perspective it could also be named "corosync-status", or the like, IMO no user would question that name.

And that is the thing. What about having something like corosync-status (maybe just shell script) which would call quorumtool, cmapctl, ... and gather required information? Together with parameter like --report it may behave more like crm_report?

Yes, sounds good to me. I think that would be helpful for all corosync users. Shell script could be fine, but as any other "higher" language - which would allow nice parsing/string handling - would add a total new language dependency on corosync, I guess that either C or shell (not bash :( ) is fine for such a thing.

Yep. Just to make sure we are on same page. I like the idea. I'm just not too keen to add information about cluster to quorumtool which is designed to display quorum/votequorum information.

Yeah, I mean, I agree - just added it to the place where it seemed the least misplaced ^^

Yep. It just don't need to be there so it shouldn't be fatal error if it is not found.

OK, we always enforce it with our tooling, but it's naturally fine to not have it.

I would rather see crypto_hash/cypher, because secauth is really compatibility "hack", but I agree in general.

Makes sense, has more info without drawbacks.

I agree with honza that this sort of info, while useful, doesn't belong in a quorumtool. There are a couple of options I can see here.

My suggestion would be to write another tool, (corosync-status?), that displays all sorts of other information but also has options for displaying quorum information. corosync-status could be a shell script that calls cmapctl to get general information and quorumtool to get quorum information. That way you only need to learn one tool for all uses

My suggestion would be to write another tool, (corosync-status?), that displays all sorts of other information but also has options for displaying quorum information. corosync-status could be a shell script that calls cmapctl to get general information and quorumtool to get quorum information. That way you only need to learn one tool for all uses

So we're on the exact same page as the discussion result above from honza and me, great.
I'm not sure if I got time to make this happen in the next weeks, just FYI.

@ThomasLamprecht No worries and no need to rush. Also I was thinking what should be included in the output and (IMHO) it may make sense to print also used token timeout and maybe some of the knet stats?

@ThomasLamprecht No worries and no need to rush. Also I was thinking what should be included in the output and (IMHO) it may make sense to print also used token timeout and maybe some of the knet stats?

Yes, makes IMO also sense, as those parameters can dramatically influence behaviour and stability.
And, from our experience, user will read some docs or speculation from others and change does, often making things worse, so having some "core config values currently in-effect" stats could be nice.
Which one exactly is then another question, maybe @fabbione has some good idea what is the most relevant of knet in it's corosync use case.