Re: [VOTE] Release Apache Cassandra Java Driver 4.18.1

[Bret McGuire]

   Greetings.  I'm cancelling this vote on the 4.18.1 driver release.  We've 
hit some issues with the Nexus staging repositories that have to be resolved 
before we can proceed.  I'll post a follow-up here when everything has been 
resolved and we're ready to proceed with the vote on this release.

   Thanks all, and apologies for the confusion!

  - Bret -

On 2024/05/20 18:14:02 Bret McGuire wrote:
> Greetings all!  This is my first stab at this so apologies in advance if I
> get something wrong.
> 
> I’m proposing the test build of Cassandra Java Driver 4.18.1 for release.
> 
> sha1: cbdde2878786fa6c4077a21352cbe738875f2106
> 
> Git: 
> https://github.com/apache/cassandra-java-driver/tree/4.18.1
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1330
> 
> 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.
> 
>Thanks!
> 
>   - Bret -
> 

Re: [DISCUSS] ccm as a subproject

[Josh McKenzie]

Sounds like we have a general consensus from the project on being willing to 
accept the donation, should the current rights owners be interested in said 
donation.

> We've been working on this along with the python-driver (just haven't raised 
> it yet).
Which they indicate they are. :)

I'll follow up on this topic offline w/Mick. Thanks everyone for the good 
conversation and feedback on it.

~Josh

On Mon, May 20, 2024, at 2:36 PM, Jordan West wrote:
> I would also love to see CCM as an official side project. It is important to 
> the project and I personally use it regularly. 
> 
> Jordan
> 
> On Thu, May 16, 2024 at 7:55 AM Josh McKenzie  wrote:
>> __
>>> We do still have the issues of DSE-supporting code in it, as we do with the 
>>> drivers.  I doubt any of us strongly object to it: there's no trickery 
>>> happening here on the user; but we should be aware of it and have a rough 
>>> direction sketched out for when someone else comes along wanting to add 
>>> support for their proprietary product.
>> IMO as long as it's documented well at the outset and we have plans to 
>> slowly refactor to move it to clean boundaries (epic in JIRA anyone <3) so 
>> it can be extracted into a separately maintained module by folks that need 
>> it, I think we'd be in great shape. That'd also pave a path for others 
>> wanting to add support for their proprietary products as well. Win-win.
>> 
>> There's always this chicken or egg problem w/things like ccm. Do people not 
>> contribute to it because it's out of the umbrella, or is it out of the 
>> umbrella because people don't need to contribute to it?
>> 
>> I hadn't thought about other subprojects relying on it. That's a very good 
>> point.
>> 
>> On Thu, May 16, 2024, at 4:48 AM, Jacek Lewandowski wrote:
>>> +1 (my personal opinion)
>>> 
>>> How to deal with the DSE-supporting code is a separate discussion IMO
>>> 
>>> - - -- --- -  -
>>> Jacek Lewandowski
>>> 
>>> 
>>> czw., 16 maj 2024 o 10:21 Berenguer Blasi  
>>> napisał(a):
 __
 +1 ccm is super useful
 
 On 16/5/24 10:09, Mick Semb Wever wrote:
> 
> 
> On Wed, 15 May 2024 at 16:24, Josh McKenzie  wrote:
>> Right now ccm isn't formally a subproject of Cassandra or under 
>> governance of the ASF. Given it's an integral components of our CI as 
>> well as for local testing for many devs, and we now have more experience 
>> w/our muscle on IP clearance and ingesting / absorbing subprojects where 
>> we can't track down every single contributor to get an ICLA, seems like 
>> it might be worth revisiting the topic of donation of ccm to Apache.
>> 
>> For what it's worth, Sylvain originally and then DataStax after transfer 
>> have both been incredible and receptive stewards of the projects and 
>> repos, so this isn't about any response to any behavior on their part. 
>> Structurally, however, it'd be better for the health of the project(s) 
>> long-term to have ccm promoted in. As far as I know there was strong 
>> receptivity to that donation in the past but the IP clearance was the 
>> primary hurdle.
>> 
>> Anyone have any thoughts for or against?
>> 
>> https://github.com/riptano/ccm
> 
> 
> 
> We've been working on this along with the python-driver (just haven't 
> raised it yet).  It is recognised, like the python-driver, as a key 
> dependency that would best be in the project.
> 
> Obtaining the CLAs should be much easier, the contributors to ccm are 
> less diverse, being more the people we know already.
> 
> We do still have the issues of DSE-supporting code in it, as we do with 
> the drivers.  I doubt any of us strongly object to it: there's no 
> trickery happening here on the user; but we should be aware of it and 
> have a rough direction sketched out for when someone else comes along 
> wanting to add support for their proprietary product.  We also don't want 
> to be pushing downstream users to be having to create their own forks 
> either.
> 
> Great to see general consensus (so far) in receiving it :) 
>  
>> 

Re: [DISCUSS] ccm as a subproject

[Jordan West]

I would also love to see CCM as an official side project. It is important
to the project and I personally use it regularly.

Jordan

On Thu, May 16, 2024 at 7:55 AM Josh McKenzie  wrote:

> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers.  I doubt any of us strongly object to it: there's no trickery
> happening here on the user; but we should be aware of it and have a rough
> direction sketched out for when someone else comes along wanting to add
> support for their proprietary product.
>
> IMO as long as it's documented well at the outset and we have plans to
> slowly refactor to move it to clean boundaries (epic in JIRA anyone <3) so
> it can be extracted into a separately maintained module by folks that need
> it, I think we'd be in great shape. That'd also pave a path for others
> wanting to add support for their proprietary products as well. Win-win.
>
> There's always this chicken or egg problem w/things like ccm. Do people
> not contribute to it because it's out of the umbrella, or is it out of the
> umbrella because people don't need to contribute to it?
>
> I hadn't thought about other subprojects relying on it. That's a very good
> point.
>
> On Thu, May 16, 2024, at 4:48 AM, Jacek Lewandowski wrote:
>
> +1 (my personal opinion)
>
> How to deal with the DSE-supporting code is a separate discussion IMO
>
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 16 maj 2024 o 10:21 Berenguer Blasi 
> napisał(a):
>
>
> +1 ccm is super useful
> On 16/5/24 10:09, Mick Semb Wever wrote:
>
>
>
> On Wed, 15 May 2024 at 16:24, Josh McKenzie  wrote:
>
> Right now ccm isn't formally a subproject of Cassandra or under governance
> of the ASF. Given it's an integral components of our CI as well as for
> local testing for many devs, and we now have more experience w/our muscle
> on IP clearance and ingesting / absorbing subprojects where we can't track
> down every single contributor to get an ICLA, seems like it might be worth
> revisiting the topic of donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after transfer
> have both been incredible and receptive stewards of the projects and repos,
> so this isn't about any response to any behavior on their part.
> Structurally, however, it'd be better for the health of the project(s)
> long-term to have ccm promoted in. As far as I know there was strong
> receptivity to that donation in the past but the IP clearance was the
> primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
>
>
>
> We've been working on this along with the python-driver (just haven't
> raised it yet).  It is recognised, like the python-driver, as a key
> dependency that would best be in the project.
>
> Obtaining the CLAs should be much easier, the contributors to ccm are less
> diverse, being more the people we know already.
>
> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers.  I doubt any of us strongly object to it: there's no trickery
> happening here on the user; but we should be aware of it and have a rough
> direction sketched out for when someone else comes along wanting to add
> support for their proprietary product.  We also don't want to be pushing
> downstream users to be having to create their own forks either.
>
> Great to see general consensus (so far) in receiving it :)
>
>
>
>

Re: [DISCUSS] CEP-40: Data Transfer Using Cassandra Sidecar for Live Migrating Instances

[Jordan West]

On Wed, May 1, 2024 at 3:34 AM Alex Petrov  wrote:

>
> We can implement CEP-40 using a similar approach: we can leave the source
> node as both a read and write target, and allow the new node to be a target
> for (pending) writes. Unfortunately, this does not help with availability
> (in fact, it decreases write availability, since we will have to collect
> 2+1 mandatory write responses instead of just 2), but increases durability,
> and I think helps to fully eliminate the second phase. This also increases
> read availability when the source node is up, since we can still use the
> source node as a part of read quorum.
>
>
I 100% agree that this is the more durable approach. And that bringing the
source node down reduces availability during the second phase. While my
inclination is that it would be better to implement the logic in the manner
you describe, from a pure correctness perspective, that loss of
availability of the r/w quorum is rare in my experience. Running a setup
like CEP-40 currently describes (but using S3 for the file transfer) for
over 3 years, in practice I have a hard time remembering one incident of
it. I'm sure its happened, but at the rate we replace hardware its not
something we deal with regularly despite taking the risk. I do agree as
well it needs to be well documented as surprising edge cases are never fun.
I think the existing and future TCM implementations cover the more
conservative/correct case and having this option as an alternative, or for
when the instance is unable to bring up the C* process, is a good to have.



> On Fri, Apr 5, 2024, at 12:46 PM, Venkata Hari Krishna Nukala wrote:
>
> Hi all,
>
> I have filed CEP-40 [1] for live migrating Cassandra instances using the
> Cassandra Sidecar.
>
> When someone needs to move all or a portion of the Cassandra nodes
> belonging to a cluster to different hosts, the traditional approach of
> Cassandra node replacement can be time-consuming due to repairs and the
> bootstrapping of new nodes. Depending on the volume of the storage service
> load, replacements (repair + bootstrap) may take anywhere from a few hours
> to days.
>
> Proposing a Sidecar based solution to address these challenges. This
> solution proposes transferring data from the old host (source) to the new
> host (destination) and then bringing up the Cassandra process at the
> destination, to enable fast instance migration. This approach would help to
> minimise node downtime, as it is based on a Sidecar solution for data
> transfer and avoids repairs and bootstrap.
>
> Looking forward to the discussions.
>
> [1]
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-40%3A+Data+Transfer+Using+Cassandra+Sidecar+for+Live+Migrating+Instances
>
> Thanks!
> Hari
>
>
>

[RELEASE] Apache Cassandra 4.0.13 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.0.13.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 4.0 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now
https://debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/40x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-4.0.13/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.0.13/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[VOTE] Release Apache Cassandra Java Driver 4.18.1

[Bret McGuire]

Greetings all!  This is my first stab at this so apologies in advance if I
get something wrong.

I’m proposing the test build of Cassandra Java Driver 4.18.1 for release.

sha1: cbdde2878786fa6c4077a21352cbe738875f2106

Git: 
https://github.com/apache/cassandra-java-driver/tree/4.18.1

Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1330

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.

   Thanks!

  - Bret -

[RELEASE] Apache Cassandra 4.1.5 released

[Brandon Williams]

The Cassandra team is pleased to announce the release of Apache
Cassandra version 4.1.5.

Apache Cassandra is a fully distributed database. It is the right
choice when you need scalability and high availability without
compromising performance.

 http://cassandra.apache.org/

Downloads of source and binary distributions are listed in our download section:

 http://cassandra.apache.org/download/

This version is a bug fix release[1] on the 4.1 series. As always,
please pay attention to the release notes[2] and Let us know[3] if you
were to encounter any problem.

[WARNING] Debian and RedHat package repositories have moved! Debian
/etc/apt/sources.list.d/cassandra.sources.list and RedHat
/etc/yum.repos.d/cassandra.repo files must be updated to the new
repository URLs. For Debian it is now
https://debian.cassandra.apache.org . For RedHat it is now
https://redhat.cassandra.apache.org/41x/ .

Enjoy!

[1]: CHANGES.txt
https://github.com/apache/cassandra/blob/cassandra-4.1.5/CHANGES.txt
[2]: NEWS.txt https://github.com/apache/cassandra/blob/cassandra-4.1.5/NEWS.txt
[3]: https://issues.apache.org/jira/browse/CASSANDRA

Re: [VOTE] Release Apache Cassandra 4.0.13

[Brandon Williams]

With five +1 (3 binding including my own) and no -1, the vote passes.
I'll get the artifacts published.

Kind Regards,
Brandon

On Thu, May 2, 2024 at 10:16 AM Brandon Williams  wrote:
>
> Proposing the test build of Cassandra 4.0.13 for release.
>
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
>
> 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.13/
>
> 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.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
>
> Kind Regards,
> Brandon

Re: [VOTE] Release Apache Cassandra 4.1.5

[Brandon Williams]

With five +1 (4 binding including my own) and no -1, the vote passes.
I'll get the artifacts published.

On Thu, May 2, 2024 at 11:36 AM Brandon Williams
 wrote:
>
> Proposing the test build of Cassandra 4.1.5 for release.
>
> sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
> Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1329/org/apache/cassandra/cassandra-all/4.1.5/
>
> 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.1.5/
>
> 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.1.5-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.1.5-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.13

[Marcus Eriksson]

+1

On Thu, May 02, 2024 at 10:16:38AM -0500, Brandon Williams wrote:
> Proposing the test build of Cassandra 4.0.13 for release.
> 
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
> 
> 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.13/
> 
> 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.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
> 
> Kind Regards,
> Brandon