[GitHub] [ozone] sodonnel commented on pull request #3306: HDDS-6579. Add commandline argument for Container Info command.

[GitBox <gi...@apache.org>]

sodonnel commented on PR #3306:
URL: https://github.com/apache/ozone/pull/3306#issuecomment-1103032556

   In my opinion this change needs reverted and rethought. When we have 10 such changes to this **human readable** command output, and someone needs all the information are they supposed to pass something like the below?
   
   ```
   ozone admin container list --a --b --c --d --e --f --g --h --i --j --k ....
   ```
   
   The user friendly approach is to display all the output. In order to be compatible, we don't guarantee the total output will never change - more we should guarantee information will never be removed, but more information can be added. Otherwise we are overly constraining ourselves for the future. In this case the new information is in a new section of the report and does not alter any existing information. It meets the criteria of "adding and not modifying existing code".
   
   For these "free text" CLI commands. which are generally intended for an administrator to read and use to debug problems, I also believe we should not even be concerned about the formatting of the existing information changing, but I am open to discuss the pros and cons of that. I can see cases where we may want to add some additional information in an existing line of output as the product matures and features are added.
   
   Most commands provide a JSON output too, and it is designed to be consumed by a computer rather than a human. If someone develops a tool to consume this data, they should be consuming the JSON data, which has a well defined parsing approach, and is suited to addition of new fields and data. If the program consuming it is correctly coded, it will not be impacted by new additions, provided existing fields do not move location and are not renamed.
   
   This approach here is not scalable as we simply cannot add flag after flag to for each new piece of information we want to add to each command.
   
   For the record, I am -1 on this change, and I would like it reverted and a discussion in the community to agree a way forward if my arguments here are not sufficient to convince you this is a bad path to continue down.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@ozone.apache.org
For additional commands, e-mail: issues-help@ozone.apache.org