Bug #3748
closedceph osd dump --format=json includes non-JSON line
0%
Description
ceph osd dump --format=json includes the non-JSON "dumped osdmap epoch N" at the top of the output, which of course breaks parsing.
This is a symptom of a larger problem, where messages in the 'reply string' part of the message are output to stdout if no error, stderr if err, but then also the 'reply bufferlist' is output
(to stdout, or the file specified). We should probably clarify which messages are 'status only'
and therefore appropriate for stderr, and which are actually "data payload" for stdout.
The other option is just not to do statusy-type things when outputting formatted data.
Updated by Joao Eduardo Luis over 11 years ago
One other option would be to provide "standard" fields for status output when using json, regardless of any other expected output.
Time permitting, we could even move all status output from the monitors to json, and add said support (which would mean being able to parse json, which we are not) to the Ceph tool. It would be the Ceph tool's responsibility to parse those results. But anyway, this ends up being tightly related with how thin the Ceph tool is, as has been discussed before.
Updated by Joao Eduardo Luis over 11 years ago
- Status changed from New to Fix Under Review
wip-3748 has a fix, commit:0edb53f02231fb83f33d3bc5f58b37b14cd5df82
Updated by Sage Weil over 11 years ago
- Status changed from Fix Under Review to Resolved
Updated by Dan Mick over 11 years ago
I sorta think we ought to clean up how the various output channels are used in this code in general. This fixes the immediate problem, but the issue remains: where should errors go, where should 'status' go, and where should output-output (JSON, XML, or not) go.
I think the code could use a lot more rigor around those topics. Maybe that's a separate bug, but we ought to think about it.
Updated by Sage Weil over 11 years ago
Funny you should mention it: that is step #1 (or maybe 2 or 3) for the management API work, IMHO. :)