Thanks for all the replies.
To summarise this thread, we have 5 people who agree with the proposals,
and also a few other points:
1. Attila - We should create tests to ensure the compatibility is not
broken accidently.
2. Pifta - We should emphasize JSON can allow fields to change order, and
any
Thanx Stephen for initiating this.
+1 to have specific documented compat guidelines, all 4 points makes sense to
me..
-Ayush
> On 23-Apr-2022, at 1:41 AM, Uma Maheswara Rao Gangumalla
> wrote:
>
> Hi Stephen,
>
> Thanks for starting this thread.
>
> I am +1. I agree that adding new lines
Hi Stephen,
Thanks for starting this thread.
I am +1. I agree that adding new lines should be allowed.
It's hard to provide a flag for every addition as that can bring many flags
and make things ungly eventually.
Nilotpal, if you have some tests around validating the command
line outputs, would
Thanks for the comments Nilotpal,
I have created a Jira to track commands with missing JSON output, and added
one Jira to it already:
https://issues.apache.org/jira/browse/HDDS-6637
If you, or anyone, comes across a command that is missing the JSON option,
please add a Jira to that epic and we e
Hi Stephen ,
I am +1 on having both human readable output and json output (with an extra
argument) for CLI commands.
Please make sure, for ALL the CLI commands/sub-commands , json outputs are
present before actually making changes in human readable CLI outputs.
Otherwise, tests would still rely
Thanks for the comments Pifta.
I guess my suggestion "for JSON the existing field names and structures
should remain the same", was a little vague. I agree that with JSON, having:
{
f1: v1
f2: v2
}
Is semantically the same whether f1 or f2 comes first. The point I was
trying to make is that
Hi Stephen,
thank you for bringing this up, I strongly agree with you, we should get a
document about compatibility for sure.
On the CLI part, I also agree with all the 4 points in general, though let
me add a few things:
For #1. JSON as it is defined at: https://www.json.org/json-en.html does
not
> 1. We should ensure that information is never removed from command output,
> unless it is deprecated and removed gracefully after some number of
> releases. For JSON the existing field names and location in the JSON
> structure should remain the same.
>
> 2. Information can be added to command ou
Discussing compatibility with some team members, we realised that we don't
have anything written down about compatibility guarantees in general. There
are many areas in compatibility, but for this discussion, I would like to
focus on CLI command output.
Ozone is still relatively immature, and as s
