[VOTE] Release Apache Cassandra 4.0.11

[Miklosovic, Stefan]

Proposing the test build of Cassandra 4.0.11 for release.

sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.11/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://github.com/apache/cassandra/blob/4.0.11-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/4.0.11-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.11

[Mick Semb Wever]

>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>


+1


Checked
- signing correct
- checksums are correct
- source artefact builds (JDK 8+11)
- binary artefact runs (JDK 8+11)
- debian package runs (JDK 8+11)
- debian repo runs (JDK 8+11)
- redhat* package runs (JDK 8+11)
- redhat* repo runs (JDK 8+11)

Re: [VOTE] Release Apache Cassandra 4.0.11

[Brandon Williams]

+1

On Thu, Jul 13, 2023, 2:13 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> Proposing the test build of Cassandra 4.0.11 for release.
>
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.11/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.11-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.0.11-tentative/NEWS.txt

Re: Changing the output of tooling between majors

[Josh McKenzie]

> I just find it ridiculous we can not change "someProperty: 10" to "Some 
> Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like 
complaining about a compiler that won't let you build if you're missing a ;

We *can* change it, but that doesn't mean the aggregate cost/benefit across our 
entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck 
things in API's before we release them. :)

On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:
> Eric,
> 
> I appreciate your feedback on this, especially more background about where 
> you are comming from in the second paragraph.
> 
> I think we are on the same page afterall. I definitely understand that people 
> are depending on this output and we need to be careful. That is why I propose 
> to change it only each major. What I feel is that everybody's usage / 
> expectations is little bit different and outputs of the commands are very 
> diverse and it is hard to balance this so everybody is happy.
> 
> I am trying to come up with a solution which would not change the most 
> important commands unnecessarily while also having some free room to tweak 
> the existing commands where we see it appropriate. I just find it ridiculous 
> we can not change "someProperty: 10" to "Some Property: 10" and there is so 
> much red tape about that.
> 
> If I had to summarize this whole discussion, the best conclustion I can think 
> of is to not change what is used the most (this would probably need to be 
> defined more explicitly) and if we have to change something else we better 
> document that extensively and provide json/yaml for people to be able to 
> divorce from the parsing of human-readable format (which probably all agree 
> should not happen in the first place).
> 
> What I am afraid of is that in order to satisfy these conditions, if, for 
> example, we just want to fix a typo or the format of a key of some value, the 
> we would need to deliver JSON/YAML format as well if there is not any yet and 
> that would mean that the change of such triviality would require way more 
> work in terms of the implementation of JSON/YAML format output. Some commands 
> are quite sophisticated and I do not want to be blocked to change a field in 
> human-readable out because providing corresponding JSON/YAML format would be 
> gigantic 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
> Subject: Re: Changing the output of tooling between majors
> 
> You don't often get email from eev...@wikimedia.org. Learn why this is 
> important
> 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 Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan 
> mailto: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 scripts aren’t going to 
> re-write them just because a better way of doing them is newly available, 
> usually they’re too busy with other work and will keep using those old 
> scripts until they stop working".
> 
> This is true. If this approach is adopted, what will happen in practice is 
> that we change the output and we provide a different format and then a user 
> detects this change because his scripts changed. As he has existing solution 
> in place which parses the text from human-readable output, he will try to fix 
> that, he will not suddenly convert all scripting he has to parsing JSON just 
> because we added it. Starting with JSON parsing might be done if he has no 
> scripting in place yet but then we would not cover already existing 
> deployments.
> 
> I think this is quite an extreme conclusion to draw.  If tooling had stable, 
> structured output formats, and if we documented an expectation that 
> human-readable console output was unstable, then presumably it would be safe 
> to assume that any new scripters would avail themselves of the stable 
> formats, or expect breakage later.  I think it's also fair to assume that at 
> least some people would spend the time to convert their scripts, particularly 
> if forced to revisit them (for example, after a breaking change to console 
> output).  As someone who manages several large-scale mission-critical 
> Cassandra clusters under constrained resources, this is how I would approach 
> it.
> 
> TL;DR Don't let perfect by the enemy of 
>

Re: Changing the output of tooling between majors

[C. Scott Andreas]

"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 fields that exist today are likely to cause problems - as Josh mentions. These seem best to take 
on a case-by-case basis rather than trying to hammer out an abstract policy. What changes would you like to make?I do think we will have difficulty evolving output formats of text-based Cassandra 
tooling until we offer machine-parseable output formats.– ScottOn Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:I just find it ridiculous we can not change 
"someProperty: 10" to "Some Property: 10" and there is so much red tape about that.Well, we're talking about programmatic parsing here. This feels like complaining about a compiler 
that won't let you build if you're missing a ;We can change it, but that doesn't mean the aggregate cost/benefit across our entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck things in API's before we release them. :)On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:Eric,I appreciate your 
feedback on this, especially more background about where you are comming from in the second paragraph.I think we are on the same page afterall. I definitely understand that people are depending on this 
output and we need to be careful. That is why I propose to change it only each major. What I feel is that everybody's usage / expectations is little bit different and outputs of the commands are very 
diverse and it is hard to balance this so everybody is happy.I am trying to come up with a solution which would not change the most important commands unnecessarily while also having some free room to 
tweak the existing commands where we see it appropriate. I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about 
that.If I had to summarize this whole discussion, the best conclustion I can think of is to not change what is used the most (this would probably need to be defined more explicitly) and if we have to 
change something else we better document that extensively and provide json/yaml for people to be able to divorce from the parsing of human-readable format (which probably all agree should not happen in 
the first place).What I am afraid of is that in order to satisfy these conditions, if, for example, we just want to fix a typo or the format of a key of some value, the we would need to deliver 
JSON/YAML format as well if there is not any yet and that would mean that the change of such triviality would require way more work in terms of the implementation of JSON/YAML format output. Some 
commands are quite sophisticated and I do not want to be blocked to change a field in human-readable out because providing corresponding JSON/YAML format would be gigantic 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:48To: dev@cassandra.apache.orgSubject: Re: Changing the output of tooling between majorsYou don't often get email from 
eev...@wikimedia.org. Learn why this is importantNetApp 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 Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan mailto: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 scripts 
aren’t going to re-write them just because a better way of doing them is newly available, usually they’re too busy with other work and will keep using those old scripts until they stop 
working".This is true. If this approach is adopted, what will happen in practice is that we change the output and we provide a different format and then a user detects this change because his 
scripts changed. As he has existing solution in place which parses the text from human-readable output, he will try to fix that, he will not suddenly convert all scripting he has to parsing JSON just 
because we added it. Starting with JSON parsing might be done if he has no scripting in place yet but then we would not cover already existing deployments.I think this is quite an extreme conclusion to 
draw.  If tooling had stable, structured output formats, and if we documented an expectation that human-readable console output was unstable, then presumably it would be safe to assume that any new 
scripter

Re: Changing the output of tooling between majors

[Miklosovic, Stefan]

For example Dinesh said this:

"Until nodetool can support JSON as output format for all interaction and there 
is a significant adoption in the user community, I would strongly advise 
against making breaking changes to the CLI output."

That is where I get the need to have a JSON output in order to fix a typo from. 
That is if we look at fixing a typo as a breaking change. Which I would say it 
is as if 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
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 the content is safe.



> "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 fields that exist today are likely to cause 
problems - as Josh mentions. These seem best to take on a case-by-case basis 
rather than trying to hammer out an abstract policy. What changes would you 
like to make?

I do think we will have difficulty evolving output formats of text-based 
Cassandra tooling until we offer machine-parseable output formats.

– Scott

On Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:


I just find it ridiculous we can not change "someProperty: 10" to "Some 
Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like 
complaining about a compiler that won't let you build if you're missing a ;

We can change it, but that doesn't mean the aggregate cost/benefit across our 
entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck 
things in API's before we release them. :)

On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:
Eric,

I appreciate your feedback on this, especially more background about where you 
are comming from in the second paragraph.

I think we are on the same page afterall. I definitely understand that people 
are depending on this output and we need to be careful. That is why I propose 
to change it only each major. What I feel is that everybody's usage / 
expectations is little bit different and outputs of the commands are very 
diverse and it is hard to balance this so everybody is happy.

I am trying to come up with a solution which would not change the most 
important commands unnecessarily while also having some free room to tweak the 
existing commands where we see it appropriate. I just find it ridiculous we can 
not change "someProperty: 10" to "Some Property: 10" and there is so much red 
tape about that.

If I had to summarize this whole discussion, the best conclustion I can think 
of is to not change what is used the most (this would probably need to be 
defined more explicitly) and if we have to change something else we better 
document that extensively and provide json/yaml for people to be able to 
divorce from the parsing of human-readable format (which probably all agree 
should not happen in the first place).

What I am afraid of is that in order to satisfy these conditions, if, for 
example, we just want to fix a typo or the format of a key of some value, the 
we would need to deliver JSON/YAML format as well if there is not any yet and 
that would mean that the change of such triviality would require way more work 
in terms of the implementation of JSON/YAML format output. Some commands are 
quite sophisticated and I do not want to be blocked to change a field in 
human-readable out because providing corresponding JSON/YAML format would be 
gigantic 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 mailto:eev...@wikimedia.org>>
Sent: Wednesday, July 12, 2023 19:48
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
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 Wed, Jul 12, 2023 at 1:54 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>>>
 wrote:
I agree with Jackson that having a different output format (JSON

Re: Changing the output of tooling between majors

[C. Scott Andreas]

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 
offering a JSON/YAML representation, though.What are some changes that you'd like to make?– ScottOn Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan"  wrote:For example Dinesh said this:"Until nodetool can support JSON as output format for all interaction and 
there is a significant adoption in the user community, I would strongly advise against making breaking changes to the CLI output."That is where I get the need to have a JSON output in order to fix a typo from. That is if we look at fixing a typo as a breaking change. Which I would say it is as if 
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:35To: dev@cassandra.apache.orgCc: devSubject: 
Re: Changing the output of tooling between majorsNetApp 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."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 fields that exist today are likely to cause problems - as Josh mentions. These seem best to take on a 
case-by-case basis rather than trying to hammer out an abstract policy. What changes would you like to make?I do think we will have difficulty evolving output formats of text-based Cassandra tooling until we offer machine-parseable output formats.– ScottOn Jul 13, 2023, at 6:39 AM, Josh McKenzie 
 wrote:I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about that.Well, we're talking about programmatic parsing here. This feels like complaining about a compiler that won't let you build if 
you're missing a ;We can change it, but that doesn't mean the aggregate cost/benefit across our entire ecosystem is worth it. The value of correcting a typo is pretty small, and the cost for everyone downstream is not. This is why we should spellcheck things in API's before we release them. :)On Wed, Jul 
12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:Eric,I appreciate your feedback on this, especially more background about where you are comming from in the second paragraph.I think we are on the same page afterall. I definitely understand that people are depending on this output and we need to be careful. 
That is why I propose to change it only each major. What I feel is that everybody's usage / expectations is little bit different and outputs of the commands are very diverse and it is hard to balance this so everybody is happy.I am trying to come up with a solution which would not change the most important 
commands unnecessarily while also having some free room to tweak the existing commands where we see it appropriate. I just find it ridiculous we can not change "someProperty: 10" to "Some Property: 10" and there is so much red tape about that.If I had to summarize this whole discussion, 
the best conclustion I can think of is to not change what is used the most (this would probably need to be defined more explicitly) and if we have to change something else we better document that extensively and provide json/yaml for people to be able to divorce from the parsing of human-readable format 
(which probably all agree should not happen in the first place).What I am afraid of is that in order to satisfy these conditions, if, for example, we just want to fix a typo or the format of a key of some value, the we would need to deliver JSON/YAML format as well if there is not any yet and that would 
mean that the change of such triviality would require way more work in terms of the implementation of JSON/YAML format output. Some commands are quite sophisticated and I do not want to be blocked to change a field in human-readable out because providing corresponding JSON/YAML format would be gigantic 
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 mailto:eev...@wikimedia.org>>Sent: Wednesday, July 12, 2023 
19:48To: dev@cassandra.apache.orgSubject: Re: Changing the output of tooling between majorsYou don't often get email from eev...@wikimedia.org. Learn why this is importantNetApp 
Security WARNING: This is an e

Re: Changing the output of tooling between majors

[Eric Evans]

On Thu, Jul 13, 2023 at 9:44 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> For example Dinesh said this:
>
> "Until nodetool can support JSON as output format for all interaction and
> there is a significant adoption in the user community, I would strongly
> advise against making breaking changes to the CLI output."
>
> That is where I get the need to have a JSON output in order to fix a typo
> from. That is if we look at fixing a typo as a breaking change. Which I
> would say it is as if 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?
>

I interpreted this to mean: If we want to get to a place where we can
freely edit human-readable output formats, we should provide stable
alternatives.


>
> 
> 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 the content is
> safe.
>
>
>
> > "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 fields that exist today are likely to cause
> problems - as Josh mentions. These seem best to take on a case-by-case
> basis rather than trying to hammer out an abstract policy. What changes
> would you like to make?
>
> I do think we will have difficulty evolving output formats of text-based
> Cassandra tooling until we offer machine-parseable output formats.
>
> – Scott
>
> On Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:
>
>
> I just find it ridiculous we can not change "someProperty: 10" to "Some
> Property: 10" and there is so much red tape about that.
> Well, we're talking about programmatic parsing here. This feels like
> complaining about a compiler that won't let you build if you're missing a ;
>
> We can change it, but that doesn't mean the aggregate cost/benefit across
> our entire ecosystem is worth it. The value of correcting a typo is pretty
> small, and the cost for everyone downstream is not. This is why we should
> spellcheck things in API's before we release them. :)
>
> On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:
> Eric,
>
> I appreciate your feedback on this, especially more background about where
> you are comming from in the second paragraph.
>
> I think we are on the same page afterall. I definitely understand that
> people are depending on this output and we need to be careful. That is why
> I propose to change it only each major. What I feel is that everybody's
> usage / expectations is little bit different and outputs of the commands
> are very diverse and it is hard to balance this so everybody is happy.
>
> I am trying to come up with a solution which would not change the most
> important commands unnecessarily while also having some free room to tweak
> the existing commands where we see it appropriate. I just find it
> ridiculous we can not change "someProperty: 10" to "Some Property: 10" and
> there is so much red tape about that.
>
> If I had to summarize this whole discussion, the best conclustion I can
> think of is to not change what is used the most (this would probably need
> to be defined more explicitly) and if we have to change something else we
> better document that extensively and provide json/yaml for people to be
> able to divorce from the parsing of human-readable format (which probably
> all agree should not happen in the first place).
>
> What I am afraid of is that in order to satisfy these conditions, if, for
> example, we just want to fix a typo or the format of a key of some value,
> the we would need to deliver JSON/YAML format as well if there is not any
> yet and that would mean that the change of such triviality would require
> way more work in terms of the implementation of JSON/YAML format output.
> Some commands are quite sophisticated and I do not want to be blocked to
> change a field in human-readable out because providing corresponding
> JSON/YAML format would be gigantic 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 mailto:eev...@wikimedia.org>>
> Sent: Wednesday, July 12, 2023 19:48
> To: dev@cassandra.apache.org
> Subject: Re: Changing the output of tooling between majors
>
> You don't often get email from eev...@wikimedia.org eev...@wikimedia.org>. Learn why this is important<
> https://aka.ms/LearnAboutSenderIdentification>
> NetApp Security 

Re: Changing the output of tooling between majors

[Miklosovic, Stefan]

"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 by that logic, changing the output which you grep on 
to something else will break your scripts if you expect it there.

For example, take sstablemetadata command - I know it is not nodetool but it 
does not matter. This is just an example. Same "problem" can be found in 
nodetool probably, sstablemetadata just came to my mind first as that is what I 
hit recently.

sstablemetadata write this:

Repaired at: 0
Originating host id: d2d12c56-7d9c-49a7-aaef-05bd2633b09e
Pending repair: --
Replay positions covered: {CommitLogPosition(segmentId=1689261027905, 
position=59450)=CommitLogPosition(segmentId=1689261027905, position=60508)}
totalColumnsSet: 0
totalRows: 1
Estimated tombstone drop times:


Do you see "totalColumsSet" and "totalRows" when all other keys in that ouput 
(in whole command) are following different format? In this case, it should be 
"Total columns set" and "Total rows".

So when we change it to that, anybody who is grepping "totalRows" will have no 
output. That is a breaking change to me. His script stopped to work.

You are correct and I agree with you completely that STRICT ADDITIONS (what I 
was suggesting) are fine because we are not breaking anything to anybody.

So here, if I want to change this, by what Dinesh says, (we change the naming 
and we break it), I need to offer JSON / YAML alternative to what 
sstablemetadata prints currently. (might be as well nodetool, just an example).


From: C. Scott Andreas 
Sent: Thursday, July 13, 2023 17:01
To: dev@cassandra.apache.org
Cc: 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 
attachments unless you recognize the sender and know the content is safe.



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 
offering a JSON/YAML representation, though.

What are some changes that you'd like to make?

– Scott

On Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan" 
 wrote:


For example Dinesh said this:

"Until nodetool can support JSON as output format for all interaction and there 
is a significant adoption in the user community, I would strongly advise 
against making breaking changes to the CLI output."

That is where I get the need to have a JSON output in order to fix a typo from. 
That is if we look at fixing a typo as a breaking change. Which I would say it 
is as if 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
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 the content is safe.



"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 fields that exist today are likely to cause 
problems - as Josh mentions. These seem best to take on a case-by-case basis 
rather than trying to hammer out an abstract policy. What changes would you 
like to make?

I do think we will have difficulty evolving output formats of text-based 
Cassandra tooling until we offer machine-parseable output formats.

– Scott

On Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:


I just find it ridiculous we can not change "someProperty: 10" to "Some 
Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like 
complaining about a compiler that won't let you build if you're missing a ;

We can change it, but that doesn't mean the aggregate cost/benefit across our 
entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck 
things in API's before we release them. :)

On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:
Eric,

I appreciate your feedback on this, especially more background about where you 
are comming from in the second paragraph.

I think we are on the same page afterall. I definitely understand that people 
are depending on this output and we need to be careful. That is why I propos

Re: Changing the output of tooling between majors

[Miklosovic, Stefan]

I am starting to slowly but surely share same opinion. Maybe we should just 
stop advancing this discussion altogether and we should rather focus on a way 
how to implement alternative output to nodetool etc. We probably need to do 
this command by command.


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
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 Thu, Jul 13, 2023 at 9:44 AM Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:
For example Dinesh said this:

"Until nodetool can support JSON as output format for all interaction and there 
is a significant adoption in the user community, I would strongly advise 
against making breaking changes to the CLI output."

That is where I get the need to have a JSON output in order to fix a typo from. 
That is if we look at fixing a typo as a breaking change. Which I would say it 
is as if 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?

I interpreted this to mean: If we want to get to a place where we can freely 
edit human-readable output formats, we should provide stable alternatives.



From: C. Scott Andreas mailto:sc...@paradoxica.net>>
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 the content is safe.



> "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 fields that exist today are likely to cause 
problems - as Josh mentions. These seem best to take on a case-by-case basis 
rather than trying to hammer out an abstract policy. What changes would you 
like to make?

I do think we will have difficulty evolving output formats of text-based 
Cassandra tooling until we offer machine-parseable output formats.

– Scott

On Jul 13, 2023, at 6:39 AM, Josh McKenzie 
mailto:jmcken...@apache.org>> wrote:


I just find it ridiculous we can not change "someProperty: 10" to "Some 
Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like 
complaining about a compiler that won't let you build if you're missing a ;

We can change it, but that doesn't mean the aggregate cost/benefit across our 
entire ecosystem is worth it. The value of correcting a typo is pretty small, 
and the cost for everyone downstream is not. This is why we should spellcheck 
things in API's before we release them. :)

On Wed, Jul 12, 2023, at 2:45 PM, Miklosovic, Stefan wrote:
Eric,

I appreciate your feedback on this, especially more background about where you 
are comming from in the second paragraph.

I think we are on the same page afterall. I definitely understand that people 
are depending on this output and we need to be careful. That is why I propose 
to change it only each major. What I feel is that everybody's usage / 
expectations is little bit different and outputs of the commands are very 
diverse and it is hard to balance this so everybody is happy.

I am trying to come up with a solution which would not change the most 
important commands unnecessarily while also having some free room to tweak the 
existing commands where we see it appropriate. I just find it ridiculous we can 
not change "someProperty: 10" to "Some Property: 10" and there is so much red 
tape about that.

If I had to summarize this whole discussion, the best conclustion I can think 
of is to not change what is used the most (this would probably need to be 
defined more explicitly) and if we have to change something else we better 
document that extensively and provide json/yaml for people to be able to 
divorce from the parsing of human-readable format (which probably all agree 
should not happen in the first place).

What I am afraid of is that in order to satisfy these conditions, if, for 
example, we just want to fix a typo or the format of a key of some value, the 
we would need to deliver JSON/YAML format as well if there is not any yet and 
that would mean that the change of such triviality would require way more work 
in terms of the implementation of JSON/YAML format output. Some commands are 
quite sophisticated and I do not want to be block

Re: Changing the output of tooling between majors

[German Eichberger via dev]

Let's take this discussion in a different direction: If we add a --legacy 
​ argument where we are supporting an old version for those who 
need/want it but have the (breaking) changes on the default this feels like a 
compromise - and then we can deprecate the legacy format without impacting 
innovation. We can also flip this with requiring a flag for the changed format 
if we feel this is better.

This let's us innovate without breaking anyone. Thoughts?

Thanks,
German


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 "breaking" changes that are likely to 
break parsing of output by current users (e.g., changes to naming/meaning/"

That is 100% correct. So by that logic, changing the output which you grep on 
to something else will break your scripts if you expect it there.

For example, take sstablemetadata command - I know it is not nodetool but it 
does not matter. This is just an example. Same "problem" can be found in 
nodetool probably, sstablemetadata just came to my mind first as that is what I 
hit recently.

sstablemetadata write this:

Repaired at: 0
Originating host id: d2d12c56-7d9c-49a7-aaef-05bd2633b09e
Pending repair: --
Replay positions covered: {CommitLogPosition(segmentId=1689261027905, 
position=59450)=CommitLogPosition(segmentId=1689261027905, position=60508)}
totalColumnsSet: 0
totalRows: 1
Estimated tombstone drop times:


Do you see "totalColumsSet" and "totalRows" when all other keys in that ouput 
(in whole command) are following different format? In this case, it should be 
"Total columns set" and "Total rows".

So when we change it to that, anybody who is grepping "totalRows" will have no 
output. That is a breaking change to me. His script stopped to work.

You are correct and I agree with you completely that STRICT ADDITIONS (what I 
was suggesting) are fine because we are not breaking anything to anybody.

So here, if I want to change this, by what Dinesh says, (we change the naming 
and we break it), I need to offer JSON / YAML alternative to what 
sstablemetadata prints currently. (might be as well nodetool, just an example).


From: C. Scott Andreas 
Sent: Thursday, July 13, 2023 17:01
To: dev@cassandra.apache.org
Cc: 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 
attachments unless you recognize the sender and know the content is safe.



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 
offering a JSON/YAML representation, though.

What are some changes that you'd like to make?

– Scott

On Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan" 
 wrote:


For example Dinesh said this:

"Until nodetool can support JSON as output format for all interaction and there 
is a significant adoption in the user community, I would strongly advise 
against making breaking changes to the CLI output."

That is where I get the need to have a JSON output in order to fix a typo from. 
That is if we look at fixing a typo as a breaking change. Which I would say it 
is as if 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
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 the content is safe.



"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 fields that exist today are likely to cause 
problems - as Josh mentions. These seem best to take on a case-by-case basis 
rather than trying to hammer out an abstract policy. What changes would you 
like to make?

I do think we will have difficulty evolving output formats of text-based 
Cassandra tooling until we offer machine-parseable output formats.

– Scott

On Jul 13, 2023, at 6:39 AM, Josh McKenzie  wrote:


I just find it ridiculous we can not change "someProperty: 10" to "Some 
Property: 10" and there is so much red tape about that.
Well, we're talking about programmatic parsing here. This feels like 
complaining about a compile

Re: Changing the output of tooling between majors

[Ekaterina Dimitrova]

On German’s point, to be honest in pre-4.1 any new changes we tried to add
with a flag after concerns for breaking changes were raised. So in that
sense I think it will be confusing to flip that to - new output by default
and moving to legacy the old one

On Thu, 13 Jul 2023 at 12:09, German Eichberger via dev <
dev@cassandra.apache.org> wrote:

> Let's take this discussion in a different direction: If we add a --legacy
> ​ argument where we are supporting an old version for those who
> need/want it but have the (breaking) changes on the default this feels like
> a compromise - and then we can deprecate the legacy format without
> impacting innovation. We can also flip this with requiring a flag for the
> changed format if we feel this is better.
>
> This let's us innovate without breaking anyone. Thoughts?
>
> Thanks,
> German
>
> --
> *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 "breaking" changes that are
> likely to break parsing of output by current users (e.g., changes to
> naming/meaning/"
>
> That is 100% correct. So by that logic, changing the output which you grep
> on to something else will break your scripts if you expect it there.
>
> For example, take sstablemetadata command - I know it is not nodetool but
> it does not matter. This is just an example. Same "problem" can be found in
> nodetool probably, sstablemetadata just came to my mind first as that is
> what I hit recently.
>
> sstablemetadata write this:
>
> Repaired at: 0
> Originating host id: d2d12c56-7d9c-49a7-aaef-05bd2633b09e
> Pending repair: --
> Replay positions covered: {CommitLogPosition(segmentId=1689261027905,
> position=59450)=CommitLogPosition(segmentId=1689261027905, position=60508)}
> totalColumnsSet: 0
> totalRows: 1
> Estimated tombstone drop times:
>
>
> Do you see "totalColumsSet" and "totalRows" when all other keys in that
> ouput (in whole command) are following different format? In this case, it
> should be "Total columns set" and "Total rows".
>
> So when we change it to that, anybody who is grepping "totalRows" will
> have no output. That is a breaking change to me. His script stopped to work.
>
> You are correct and I agree with you completely that STRICT ADDITIONS
> (what I was suggesting) are fine because we are not breaking anything to
> anybody.
>
> So here, if I want to change this, by what Dinesh says, (we change the
> naming and we break it), I need to offer JSON / YAML alternative to what
> sstablemetadata prints currently. (might be as well nodetool, just an
> example).
>
> 
> From: C. Scott Andreas 
> Sent: Thursday, July 13, 2023 17:01
> To: dev@cassandra.apache.org
> Cc: 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 attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> 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 offering a JSON/YAML representation, though.
>
> What are some changes that you'd like to make?
>
> – Scott
>
> On Jul 13, 2023, at 7:44 AM, "Miklosovic, Stefan" <
> stefan.mikloso...@netapp.com> wrote:
>
>
> For example Dinesh said this:
>
> "Until nodetool can support JSON as output format for all interaction and
> there is a significant adoption in the user community, I would strongly
> advise against making breaking changes to the CLI output."
>
> That is where I get the need to have a JSON output in order to fix a typo
> from. That is if we look at fixing a typo as a breaking change. Which I
> would say it is as if 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
> 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 the content is
> safe.
>
>
>
> "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 fields that exist today are likely to cause
> problems - as Josh mentions. These seem 

[Discuss] CQLSH confusion

[German Eichberger via dev]

All,

I am working with clusters with different Cassandra versions and have been 
using some cqlsh which "just worked". Recently I wanted to use virtual tables 
and ran into [1]. After that I filed [2].

Brandon states that "do not use a cqlsh that is from a different version than 
what is distributed with the server" since I have no idea what other 
incompatibilities like this there are, compatibility of that kind has never 
been a goal."

I would like to open the discussion if this is what we want: cqlsh needs to be 
in lockstep with the C* version.

Assuming, this is how things should be, I would propose to change the cqlsh 
versioning to be in line with the C* versioning. Right now I am using cqlsh 
6.0.1 and I have no idea to which C* version that translates to. Aligning 
versions would make this much easier.

Thanks,
German

Re: [Discuss] CQLSH confusion

[German Eichberger via dev]

Forgot the references:
[1] https://the-asf.slack.com/archives/CJZLTM05A/p1686771286554899
[2] https://issues.apache.org/jira/browse/CASSANDRA-18666

From: German Eichberger via dev 
Sent: Thursday, July 13, 2023 10:14 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] [Discuss] CQLSH confusion

All,

I am working with clusters with different Cassandra versions and have been 
using some cqlsh which "just worked". Recently I wanted to use virtual tables 
and ran into [1]. After that I filed [2].

Brandon states that "do not use a cqlsh that is from a different version than 
what is distributed with the server" since I have no idea what other 
incompatibilities like this there are, compatibility of that kind has never 
been a goal."

I would like to open the discussion if this is what we want: cqlsh needs to be 
in lockstep with the C* version.

Assuming, this is how things should be, I would propose to change the cqlsh 
versioning to be in line with the C* versioning. Right now I am using cqlsh 
6.0.1 and I have no idea to which C* version that translates to. Aligning 
versions would make this much easier.

Thanks,
German

Re: [Discuss] CQLSH confusion

[Brandon Williams]

You forgot to link references,
https://issues.apache.org/jira/browse/CASSANDRA-18666 has it all
though I think

I think it's too late to align versions, that cat is out of the bag.
What we can do though is what I last suggested there: keep the C*
version somewhere in cqlsh and warn when it doesn't match the server.

Kind Regards,
Brandon

On Thu, Jul 13, 2023 at 12:14 PM German Eichberger via dev
 wrote:
>
> All,
>
> I am working with clusters with different Cassandra versions and have been 
> using some cqlsh which "just worked". Recently I wanted to use virtual tables 
> and ran into [1]. After that I filed [2].
>
> Brandon states that "do not use a cqlsh that is from a different version than 
> what is distributed with the server" since I have no idea what other 
> incompatibilities like this there are, compatibility of that kind has never 
> been a goal."
>
> I would like to open the discussion if this is what we want: cqlsh needs to 
> be in lockstep with the C* version.
>
> Assuming, this is how things should be, I would propose to change the cqlsh 
> versioning to be in line with the C* versioning. Right now I am using cqlsh 
> 6.0.1 and I have no idea to which C* version that translates to. Aligning 
> versions would make this much easier.
>
> Thanks,
> German

Re: [Discuss] CQLSH confusion

[Ekaterina Dimitrova]

“ keep the C*
version somewhere in cqlsh and warn when it doesn't match the server.”

+1 on this suggestion. I had horrible experience recently with things
changing their versioning in another project. It brings mostly confusion.
Warning and adding C* version makes it simple and obvious. No need to dig
into docs, tickets, PRs

On Thu, 13 Jul 2023 at 13:26, Brandon Williams  wrote:

> You forgot to link references,
> https://issues.apache.org/jira/browse/CASSANDRA-18666 has it all
> though I think
>
> I think it's too late to align versions, that cat is out of the bag.
> What we can do though is what I last suggested there: keep the C*
> version somewhere in cqlsh and warn when it doesn't match the server.
>
> Kind Regards,
> Brandon
>
> On Thu, Jul 13, 2023 at 12:14 PM German Eichberger via dev
>  wrote:
> >
> > All,
> >
> > I am working with clusters with different Cassandra versions and have
> been using some cqlsh which "just worked". Recently I wanted to use virtual
> tables and ran into [1]. After that I filed [2].
> >
> > Brandon states that "do not use a cqlsh that is from a different version
> than what is distributed with the server" since I have no idea what other
> incompatibilities like this there are, compatibility of that kind has never
> been a goal."
> >
> > I would like to open the discussion if this is what we want: cqlsh needs
> to be in lockstep with the C* version.
> >
> > Assuming, this is how things should be, I would propose to change the
> cqlsh versioning to be in line with the C* versioning. Right now I am using
> cqlsh 6.0.1 and I have no idea to which C* version that translates to.
> Aligning versions would make this much easier.
> >
> > Thanks,
> > German
>

Re: Changing the output of tooling between majors

[Dinesh Joshi]

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 our output format - structured or not.

Dinesh

> On Jul 13, 2023, at 9:08 AM, German Eichberger via dev 
>  wrote:
> 
> Let's take this discussion in a different direction: If we add a --legacy 
> ​ argument where we are supporting an old version for those who 
> need/want it but have the (breaking) changes on the default this feels like a 
> compromise - and then we can deprecate the legacy format without impacting 
> innovation. We can also flip this with requiring a flag for the changed 
> format if we feel this is better.
> 
> This let's us innovate without breaking anyone. Thoughts?
> 
> Thanks,
> German

Re: [VOTE] Release Apache Cassandra 4.0.11

[Dinesh Joshi]

+1

> On Jul 13, 2023, at 12:12 AM, Miklosovic, Stefan 
>  wrote:
> 
> Proposing the test build of Cassandra 4.0.11 for release.
> 
> sha1: f8584b943e7cd62ed4cb66ead2c9b4a8f1c7f8b5
> Git: https://github.com/apache/cassandra/tree/4.0.11-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1303/org/apache/cassandra/cassandra-all/4.0.11/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.11/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt: 
> https://github.com/apache/cassandra/blob/4.0.11-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.11-tentative/NEWS.txt

Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of the release process

[Brad]

I agree that a CEP is a good idea, I'll discuss with Jeff and hope to draft
something.

On Wed, Jul 12, 2023 at 6:13 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> CEP is a great idea. The devil is in details and while this looks cool, it
> will definitely not hurt to have the nuances ironed out.
>
> 
> From: Patrick McFadin 
> Sent: Tuesday, July 11, 2023 2:24
> To: dev@cassandra.apache.org; German Eichberger
> Subject: Re: CASSANDRA-18654 - start publishing CQLSH to PyPI as part of
> the release process
>
> 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.
>
>
>
> I would say it helps a lot of people. 45k downloads in just last month:
> https://pypistats.org/packages/cqlsh
>
> I feel like a CEP would be in order, along the lines of CEP-8:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> >
>
> Unless anyone objects, I can help you get the CEP together and we can get
> a vote, then a JIRA in place for any changes in trunk.
>
> Patrick
>
> On Mon, Jul 10, 2023 at 4:58 PM German Eichberger via dev <
> dev@cassandra.apache.org> wrote:
> Same - really appreciate those efforts and also welcome the upstreaming
> and release automation...
>
> German
> 
> From: Jeff Widman mailto:j...@jeffwidman.com>>
> Sent: Sunday, July 9, 2023 1:44 PM
> To: Max C. mailto:mc_cassand...@core43.com>>
> Cc: dev@cassandra.apache.org <
> dev@cassandra.apache.org>; Brad
> Schoening mailto:bscho...@gmail.com>>
> Subject: [EXTERNAL] Re: CASSANDRA-18654 - start publishing CQLSH to PyPI
> as part of the release process
>
> You don't often get email from j...@jeffwidman.com j...@jeffwidman.com>. Learn why this is important<
> https://aka.ms/LearnAboutSenderIdentification>
> Thanks Max, always encouraging to hear that the time I spend on open
> source is helping others.
>
> Your use case is very similar to what drove my original desire to get
> involved with the project. Being able to `pip install cqlsh` from a dev
> machine was so much lighter weight than the alternatives.
>
> Anyone else care to weigh in on this?
>
> What are the next steps to move to a decision?
>
> Cheers,
> Jeff
>
> On Sat, Jul 8, 2023, 7:23 PM Max C.  mc_cassand...@core43.com>> wrote:
>
> As a user, I really appreciate your efforts Jeff & Brad.  I would *love*
> for the C* project to officially support this.
>
> In our environment we have a lot of client machines that all share common
> NFS mounted directories.  It's much easier for us to create a Python
> virtual environment on a file server with the cqlsh PyPI package installed
> than it is to install the Cassandra RPMs on every single machine.  Before I
> discovered your PyPI package, our developers would need to login to  a
> Cassandra node in order to run cqlsh.  The cqlsh PyPI package, however, is
> in our standard "python dev tools" virtual environment -- along with
> Ansible, black, isort and various other Python packages; which means it's
> accessible to everyone, everywhere.
>
> I agree that this should not replace packaging cqlsh in the Cassandra RPM,
> so much provide an additional option for installing cqlsh without the
> baggage of installing the full Cassandra package.
>
> Thanks again for your work Jeff & Brad.
>
> - Max
>
> On 7/6/2023 5:55 PM, Jeff Widman wrote:
> Myself and Brad Schoening currently maintain
> https://pypi.org/project/cqlsh/ which
> repackages CQLSH that ships with every Cassandra release.
>
> This way:
>
>   *   anyone who wants a lightweight client to talk to a remote cassandra
> can simply `pip install cqlsh` without having to download the full
> cassandra source, unzip it, etc.
>   *   it's very easy for folks to use it as scaffolding in their python
> scripts/tooling since they can simply include it in the list of their
> required dependencies.
>
> We currently handle the packaging by waiting for a release, then manually
> copy/pasting the code out of the cassandra source tree into
> https://github.com/jeffwidman/cqlsh
> which has some additional build/python package configuration files, then
> using standard python tooling to publish to PyPI.
>
> Given that our project is simply a build/packaging project, I wanted to
> start a conversation about upstreaming this into core Cassandra. I realize
> that Cassandra has no interest in maintaining lots of build targets... but
> given that cqlsh is written in Python and publishing to PyPI enables DBA's
> to share more complicated tooling built on top of it this seems like a
> natural fit for core cassandr