Ceph » CephFS

(Sorry for the late update)

This was discussed in cephfs standup. mgr/nfs returns data in both stdout and stderr (say, when trying up update multiple exports and some of exports fail to update). The data returned in stderr is a string while the one in stdout is a JSON. While this is not totally incorrect and ceph-mgr cpp handles this, the question is should mgr/nfs stick to the convention of either retuning stdout or stderr.

Leonid mentioned that its not totally incorrect to use both, but in mgr/nfs case, the stdout is a JSON carrying information for the failed exports and stderr being a string giving some more details about the exports.

I don't see any issue with the example stdout response for a successful operation - or any operation status, for that matter. The JSON's contents are irrelevant to this discussion, as long as it's a well-formed JSON following the documented schema.

I want to challenge the part of the comment where it requests that stderr output should be kept minimal and only used for error cases. It could be a good rule of thumb for default command output, but commands may include a verbosity control, in which case the user would expect arbitrarily more output. This additional output is usually expected on stderr to not interfere with the command's documented result format that is to be consumed via the stdout.

Hence, while I completely agree with the statement that "Everything programmatically consumable should be put on stdout", I'd be fine with some affirmative messages on stderr for a successful operation, though I'd prefer if I could control the verbosity, which could be in the form of a --quite mode to suppress this output if it's there by default.

As for having 'state': "added" as part of the json object returned on the stdout, IMO it's not violating the general cli contract. It is a question to the designers of the specific command and this command's intended usage scenario.

Venky Shankar wrote:

(Sorry for the late update)

This was discussed in cephfs standup. mgr/nfs returns data in both stdout and stderr (say, when trying up update multiple exports and some of exports fail to update). The data returned in stderr is a string while the one in stdout is a JSON. While this is not totally incorrect and ceph-mgr cpp handles this, the question is should mgr/nfs stick to the convention of either retuning stdout or stderr.

Leonid mentioned that its not totally incorrect to use both, but in mgr/nfs case, the stdout is a JSON carrying information for the failed exports and stderr being a string giving some more details about the exports.

How about segregating export (creation/update) failure and successes and feeding the data accordingly to stdout and stderr?

Venky Shankar wrote:

(Sorry for the late update)

This was discussed in cephfs standup. mgr/nfs returns data in both stdout and stderr (say, when trying up update multiple exports and some of exports fail to update). The data returned in stderr is a string while the one in stdout is a JSON. While this is not totally incorrect and ceph-mgr cpp handles this, the question is should mgr/nfs stick to the convention of either retuning stdout or stderr.

If we are to follow this convention then IMO even a single export creation/update failure should be treated as failure as whole; that means the success data would also land up in stderr(this might look a bit weird but my rationale here is that we must prioritise failures first since it is the programmatically consumable and non-trivial bit of information rather than a JSON entry saying "state" : "added")

Leonid Usov wrote:

I don't see any issue with the example stdout response for a successful operation - or any operation status, for that matter. The JSON's contents are irrelevant to this discussion, as long as it's a well-formed JSON following the documented schema.

I want to challenge the part of the comment where it requests that stderr output should be kept minimal and only used for error cases. It could be a good rule of thumb for default command output, but commands may include a verbosity control, in which case the user would expect arbitrarily more output. This additional output is usually expected on stderr to not interfere with the command's documented result format that is to be consumed via the stdout.

Agree that tools that have verbose switch should dump information strings to stderr, these cli commands are kind of an query interface that's wired up in ceph-mgr and I can only guess the limitation arises from somewhere around that (although one can dump loads of (json) string to stdout, so why not for stderr).

Hence, while I completely agree with the statement that "Everything programmatically consumable should be put on stdout", I'd be fine with some affirmative messages on stderr for a successful operation, though I'd prefer if I could control the verbosity, which could be in the form of a --quite mode to suppress this output if it's there by default.

As for having 'state': "added" as part of the json object returned on the stdout, IMO it's not violating the general cli contract. It is a question to the designers of the specific command and this command's intended usage scenario.

That's likely a best programming practice and (kind of) rule to not have commands tell what they did.

As far as this tracker is concerned, it looks like there isn't any violation of contract. So, I'm fine with closing this unless there is more to discuss.