+1 to always version the output format
From: Dinesh Joshi
Sent: Thursday, July 13, 2023 3:36 PM
To: dev
Subject: [EXTERNAL] Re: Changing the output of tooling between majors
This adds maintenance overhead but is a potential alternative. I would only
flip the
As Eric said, a major release is not a license to make externally visible
breaking changes. We are too mature a project now.
I have OCD tendencies like many people here, but one must learn to live with
aesthetically imperfect tool output. Internal changes are fine, external
changes that are act
This adds maintenance overhead but is a potential alternative. I would only
flip the flag. I would prefer to make the default "legacy" output and innovate
behind a "--output-format=v2" flag. That way tools do not break or have to
change to pass in the new flag.
Ideally we should always version
gt; --
> *From:* Miklosovic, Stefan
> *Sent:* Thursday, July 13, 2023 8:20 AM
> *To:* dev@cassandra.apache.org
> *Subject:* [EXTERNAL] Re: Changing the output of tooling between majors
>
> "Dinesh's message cautions against making "breaki
AM
To: dev@cassandra.apache.org
Subject: [EXTERNAL] Re: Changing the output of tooling between majors
"Dinesh's message cautions against making "breaking" changes that are likely to
break parsing of output by current users (e.g., changes to naming/meaning/"
That is 100% correct. So
.
From: Eric Evans
Sent: Thursday, July 13, 2023 17:09
To: dev@cassandra.apache.org
Subject: Re: Changing the output of tooling between majors
You don't often get email from eev...@wikimedia.org. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
NetApp Secur
somebody is "greping" it and it is not there, it will break.
Do you understand that the same way or am I interpreting that wrong?
From: C. Scott Andreas
Sent: Thursday, July 13, 2023 16:35
To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org
__
> From: C. Scott Andreas
> Sent: Thursday, July 13, 2023 16:35
> To: dev@cassandra.apache.org
> Cc: dev
> Subject: Re: Changing the output of tooling between majors
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open a
Dinesh's message cautions against making "breaking" changes that are likely to break parsing of output by current users (e.g., changes to naming/meaning/position of existing fields vs. adding new ones). I don't read his message as saying that any change to nodetool output is conditional on
offeri
_
From: C. Scott Andreas
Sent: Thursday, July 13, 2023 16:35
To: dev@cassandra.apache.org
Cc: dev
Subject: Re: Changing the output of tooling between majors
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know
"From what I see you guys want to condition any change by offering json/yaml as well."I don't think I've seen a proposal to block changes to nodetool output on machine-parseable formats in
this thread.Additions of new delimited fields to nodetool output are mostly straightforward. Changes to fiel
igantic portion of the work itself.
>
> From what I see you guys want to condition any change by offering json/yaml
> as well and I dont know if that is just not too much.
>
>
> ____
> From: Eric Evans
> Sent: Wednesday, July 12, 2023 19:48
> To: dev@cassandra.apache.org
> S
ra.apache.org
Subject: Re: Changing the output of tooling between majors
You don't often get email from eev...@wikimedia.org. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
NetApp Security WARNING: This is an external email. Do not click links or open
Agreed with Eric’s point here, yes.- ScottOn Jul 12, 2023, at 10:48 AM, Eric Evans wrote:On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan wrote:I agree with Jackson that having a different output format (JSON/YAML) in order to be able to change the default output
On Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> I agree with Jackson that having a different output format (JSON/YAML) in
> order to be able to change the default output resolves nothing in practice.
>
> As Jackson said, "operators who maintain these scr
read/drrpskmoyd2t4tcyk6jgx52y8fhhtjt6
(2) https://lists.apache.org/thread/2w5pdd4ncsc8s3qz0fbw2rkgy30ky4r6
From: Fleming, Jackson
Sent: Tuesday, July 11, 2023 1:06
To: dev@cassandra.apache.org
Subject: Re: Changing the output of tooling between majors
NetApp Sec
ally a
> solution to this problem.
>
> Regards,
>
> Jackson
>
> From: Eric Evans
> Date: Tuesday, 11 July 2023 at 4:14 am
> To: dev@cassandra.apache.org
> Subject: Re: Changing the output of tooling between majors
> You don't often get email from john.eric.ev...@g
Subject: Re: Changing the output of tooling between majors
You don't often get email from john.eric.ev...@gmail.com. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
NetApp Security WARNING: This is an external email. Do not click links or open
attachments
On Sun, Jul 9, 2023 at 9:10 PM Dinesh Joshi wrote:
> On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
>
>
>
> If we are providing CQL / JSON / YAML for couple years, I do not believe
> that the argument "lets not break it for folks in nodetool" is still
> re
On Fri, Jul 7, 2023 at 10:20 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
> Hi list,
>
> I want to clarify the policy we have when we want to / going to change the
> output of the tooling (nodetool or tools/bin etc.).
>
> I am not sure it is written somewhere explicitly, but how I
> On Jul 8, 2023, at 8:43 AM, Miklosovic, Stefan
> wrote:
>
> If we are providing CQL / JSON / YAML for couple years, I do not believe that
> the argument "lets not break it for folks in nodetool" is still relevant. CQL
> output is there from times of 4.0 at least (at least!) and YAML / JSON
ink the problem of changing the
>> output is too hot. There is basically like 15 at most commands for which the
>> output matter because there is not their CQL equivalent or JSON / YAML
>> output.
>>
>> If we are providing CQL / JSON / YAML for couple years, I do not
at
> the argument "lets not break it for folks in nodetool" is still relevant. CQL
> output is there from times of 4.0 at least (at least!) and YAML / JSON is
> also not something completely new. It is not like we are suddenly forcing
> people to change their habits, there
that if it is changed"
in this particular case.
From: Miklosovic, Stefan
Sent: Saturday, July 8, 2023 17:43
To: dev
Subject: Re: Changing the output of tooling between majors
Thank you, Josh, for your insight.
I think they should not parse that out
ist to probe the situation a little
bit.
(1) https://gist.github.com/smiklosovic/3f4ea8ccae53ad503af13c53789815be
(2) https://gist.github.com/smiklosovic/f9a681016c22e2dfe88c883b6881cb7c
________________________
From: Josh McKenzie
Sent: Saturday, July 8, 2023 14:47
To: dev
Subje
> Once there is, we are free to change the default output however we want.
One thing I always try to keep in mind on discussions like this. A thought
experiment (with very hand-wavy numbers; try not to get hung up on them):
* Let's say there are 5,000 discrete "users" of C* out there (different g
On Fri, Jul 7, 2023 at 2:20 PM Miklosovic, Stefan
wrote:
>
> Great thanks. That might work.
>
> So we do not change the default output unless there is json / yaml equivalent.
>
> Once there is, we are free to change the default output however we want.
Yes, exactly. Then we have the best of both
@cassandra.apache.org
Subject: Re: Changing the output of tooling between majors
NetApp Security WARNING: This is an external email. Do not click links or open
attachments unless you recognize the sender and know the content is safe.
On Fri, Jul 7, 2023 at 2:11 PM Miklosovic, Stefan
wrote:
>
&g
On Fri, Jul 7, 2023 at 2:11 PM Miklosovic, Stefan
wrote:
>
> Yes, that is true, but the original, unfixed, output, is still there. Are we
> OK with that?
When we have a serialized output available, we do whatever we like to
the display output.
uot; flag is just nice to
have, just another way how to interpret the results. But you mean that we are
not going to touch "someValue" output ever again?
From: Brandon Williams
Sent: Friday, July 7, 2023 21:05
To: dev@cassandra.apache.org
Subject: Re:
On Fri, Jul 7, 2023 at 2:02 PM Miklosovic, Stefan
wrote:
>
> There is just no clear path how to improve that over time and exposing the
> same output via different format is not really solving it ... the
> discrepancies are still there.
I'm not sure what you mean, can you explain? In my mind,
of this is happening in scale?
From: Brandon Williams
Sent: Friday, July 7, 2023 20:39
To: dev@cassandra.apache.org
Subject: Re: Changing the output of tooling between majors
NetApp Security WARNING: This is an external email. Do not click links or open
attachme
On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
wrote:
>
> Anyway, the main question here is if we are OK to change the output in majors.
I think we always want to strive for compatibility whenever possible.
My personal litmus test is "can this information be obtained
elsewhere?" and if the an
On Fri, Jul 7, 2023 at 10:21 AM Miklosovic, Stefan
wrote:
> If that is the case, we should start to treat this problem completely
> differently and we should not rely on the output of tooling at all and we
> should either provide corresponding JMX method to retrieve it or we should
> offer othe
Hi list,
I want to clarify the policy we have when we want to / going to change the
output of the tooling (nodetool or tools/bin etc.).
I am not sure it is written somewhere explicitly, but how I get it from the
gossip over years is that we should not change the output (e.g. changing the
name
35 matches
Mail list logo