Fix #6242
closedceph CLI should honor `--help` and not return log lines back
0%
Description
I wanted to have access to the help menu in the `ceph` CLI, but for some reason it just returns a few log lines
without giving me access to the help.
This should not happen (specifically for something like `--help`) because we are shutting off users from being able
to read about options/flags
vagrant@node1:~$ ceph mon_status --help 2013-09-05 16:35:43.859174 7ff57588d700 -1 monclient(hunting): ERROR: missing keyring, cannot use cephx for authentication 2013-09-05 16:35:43.859179 7ff57588d700 0 librados: client.admin initialization error (2) No such file or directory Error connecting to cluster: ObjectNotFound vagrant@node1:~$ ceph --help 2013-09-05 16:36:43.502672 7f7aa3623700 -1 monclient(hunting): ERROR: missing keyring, cannot use cephx for authentication 2013-09-05 16:36:43.502676 7f7aa3623700 0 librados: client.admin initialization error (2) No such file or directory Error connecting to cluster: ObjectNotFound
`ceph --version` does seem to work correctly:
ceph version 0.67.2 (eb4380dd036a0b644c6283869911d615ed729ac8)
After getting help from Tamil, the culprit was that the user did not have permissions to /etc/ceph.
If this is the case, then the CLI should always report back that error, not something else that is misleading (like "cannot use cephx").
Updated by Dan Mick over 10 years ago
- Status changed from New to Duplicate
The more I consider this, the more sure I am this is really a duplicate of 5634. The problem is that we don't issue the right error message (EPERM on the keyring file
leading to no valid key) and continue on; if we didn't continue on, we wouldn't
get the confusing "missing keyring" and "ObjectNotFound" errors.
Printing help isn't an option without connecting to the monitor.
Updated by Alfredo Deza over 10 years ago
I have to disagree here. Regardless of the reasons for needing to connect to a monitor (what is the reason to need that anyway?) you should always be able to print help.
There is nothing as frustrating in a CLI tool that will not even print help because of some side effect (like not being able to connect to a monitor in this case).
Please, consider display the help menu regardless of the state of a monitor.
Displaying how to use command line flags should not be dependent on the state of anything else except the CLI tool itself.
Updated by Sage Weil over 10 years ago
- Status changed from Duplicate to 12
hmm, we could make ceph --help/-h do the basic stuff, and ceph --help-all (or similar) do the mon query to get the command set?
Updated by Josh Durgin over 10 years ago
What about having --help try the monitor, but print hardcoded help if it can't connect? It could include a warning noting that the hardcoded help may be outdated because it can't connect to the monitors.
Updated by Alfredo Deza over 10 years ago
Both suggestions from Josh and Sage are entirely acceptable here. I wouldn't mind if some section of the help tells me that it could not connect to the monitors.
I don't know why we tie the help with the ability to connect to a monitor, but failing gracefully with a nice message while still printing the help is invaluable.
Updated by Dan Mick over 10 years ago
If you can't connect to the monitor, the help is going to do you no good; you can't issue any of those commands. It seems to me that the better course is to issue a concise warning that the monitor is not working, and no commands are possible until the monitor state is fixed.
Updated by Greg Farnum over 10 years ago
Once we have our ping messages, etc, then there will be things you can do without connecting to the monitors, though, and we'll need the help text for those commands as well. So an alternate no-connection help text which includes a no-connection warning might be the most appropriate, but let's not preclude the possibility of adding other things.
The reason we tie help text with monitor connections is that the help text is automatically generated from a command list the monitor provides, Alfredo.
Updated by Alfredo Deza over 10 years ago
@Dan Mick it doesn't matter that a user cannot do anything with a monitor.
The best thing a CLI application can do is show you a help menu regardless of the state of the application. If the application is in a non-working state a help menu should
not be kept from a user.
If we need to generate commands from monitors and those commands cannot be available if the monitors are not up, that is OK. We can have an outdated help menu (like Josh suggested), a minimal help (like Sage mentioned), or both.
A CLI app that does not show any help because some part of the application does not work looks broken and will do nothing more than frustrate a user that is attempting to
make things work.
Updated by Dan Mick over 10 years ago
It does matter, but there's probably middle ground with some small fixed help. I'll work on
something like that.
Updated by Sage Weil over 10 years ago
- Target version changed from v0.71 to v0.72 Emperor
Updated by Greg Farnum over 10 years ago
- Assignee set to Greg Farnum
Need to figure out how the ceph tool works these days to fix this up, but I'm diving in.
Updated by Greg Farnum over 10 years ago
- Status changed from 12 to Fix Under Review
https://github.com/ceph/ceph/pull/739
This turned out to not be a huge deal, although I did not try and suppress the ugly output lines; just added nicer ones following. (The log lines are basically appropriate and would be somewhat difficult to turn off.)
Updated by Sage Weil over 10 years ago
- Status changed from Fix Under Review to Resolved
Updated by Alfredo Deza about 6 years ago
It is great to finally see a PR that addresses the actual problem on this ticket which was "why do we need to see error logs of the monitors when using --help"