mon/AuthMonitor: log when parsing caps fails#51004
Conversation
f8173de to
b5807d0
Compare
AuthMonitor::valid_caps() checks whether or not caps are valid by checking if parsing caps is successful. The respective parsing methods print a error message to stderr when parsing fails but none print a log message. Let's add a log entry when parsing fails are caps are known to be invalid. Signed-off-by: Rishabh Dave <ridave@redhat.com>
b5807d0 to
3fcbb0b
Compare
|
@ljflores Please pick PR for QA run. |
|
jenkins test make check arm64 |
|
jenkins test windows |
| if (type == "mon") { | ||
| MonCap moncap; | ||
| if (!moncap.parse(caps, out)) { | ||
| dout(20) << "Parsing MON caps failed. MON cap: " << caps << dendl; |
There was a problem hiding this comment.
out would generally have the failure error string returned back to the CLI - were those not verbose enough for debugging. Esp. since the message logged here are pretty generic.
There was a problem hiding this comment.
It's better when logs too have an entry about failed parsing.
There was a problem hiding this comment.
IMO, it'll be a bit more helpful if the log message has details about what failed. WDYT?
There was a problem hiding this comment.
Okay. The needs the iterator that parsing uses. And that is internal to classes that parse.
There was a problem hiding this comment.
IMO, unless we additionally log the reason for parsing failure, this change does not add anything useful to debug.
There was a problem hiding this comment.
It's not useless because it's impossible to tell that parsing failed just by looking at logs. Such a message helps one to jump to a relevant part of the log and start investigating for the cause of failure from there.
Otherwise, logs is not very helpful as reader can't tell which messages were logged before the parsing failure.
There was a problem hiding this comment.
I'll leave it upto @rzarzynski to take a call for this.
There was a problem hiding this comment.
It's not useless because it's impossible to tell that parsing failed just by looking at logs
I agree that a developer not-always has access to CLI's output; having the info in one place (in the log) helps, IMHO.
|
Rados suite results: http://pulpito.front.sepia.ceph.com/?branch=wip-yuri7-testing-2023-04-19-1343 Failures, unrelated: Details: |
|
jenkins test windows |
| if (type == "mon") { | ||
| MonCap moncap; | ||
| if (!moncap.parse(caps, out)) { | ||
| dout(20) << "Parsing MON caps failed. MON cap: " << caps << dendl; |
There was a problem hiding this comment.
It's not useless because it's impossible to tell that parsing failed just by looking at logs
I agree that a developer not-always has access to CLI's output; having the info in one place (in the log) helps, IMHO.
The commit originally belongs to PR #41779. These log entries were very useful while debugging PR #41779 for parsing failures. So it's worth to get this patch merged.
Contribution Guidelines
To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "pacific"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
Checklist
Show available Jenkins commands
jenkins retest this pleasejenkins test classic perfjenkins test crimson perfjenkins test signedjenkins test make checkjenkins test make check arm64jenkins test submodulesjenkins test dashboardjenkins test dashboard cephadmjenkins test apijenkins test docsjenkins render docsjenkins test ceph-volume alljenkins test ceph-volume toxjenkins test windows