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: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to