Re: [DISCUSS] Harry in-tree

[Marcus Eriksson]

+1!

/Marcus

On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote:
> Hi everyone,
> 
> With TCM landed, there will be way more Harry tests in-tree: we are using it 
> for many coordination tests, and there's now a simulator test that uses 
> Harry. During development, Harry has allowed us to uncover and resolve 
> numerous elusive edge cases.
> 
> I had conversations with several folks, and wanted to propose to move 
> harry-core to Cassandra test tree. This will substantially 
> simplify/streamline co-development of Cassandra and Harry. With a new 
> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
> will also be much more approachable.
> 
> Besides making it easier for everyone to develop new fuzz tests, it will also 
> substantially lower the barrier to entry. Currently, debugging an issue found 
> by Harry involves a cumbersome process of rebuilding and transferring jars 
> between Cassandra and Harry, depending on which side you modify. This not 
> only hampers efficiency but also deters broader adoption. By merging 
> harry-core into the Cassandra test tree, we eliminate this barrier.
> 
> Thank you,
> --Alex
> 
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Berenguer Blasi]

Welcome!

On 29/11/23 2:24, guo Maxwell wrote:

Congrats!

Jacek Lewandowski  于2023年11月29日周三 
06:16写道：


Congrats!!!

wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky 
napisał:

Congrats Francisco!

> On Nov 28, 2023, at 1:56 PM, C. Scott Andreas
 wrote:
>
> Congratulations, Francisco!
>
> - Scott
>
>> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi
 wrote:
>>
>> The PMC members are pleased to announce that Francisco
Guerrero Hernandez has accepted
>> the invitation to become committer today.
>>
>> Congratulations and welcome!
>>
>> The Apache Cassandra PMC members

Re: CEP-21 - Transactional cluster metadata merged to trunk

[Ekaterina Dimitrova]

I hate to say it, but I was disappointed that this email thread was started
after the TCM work had already been committed. Especially knowing how we
had even an epic with patches spread around the codebase, which are waiting
on TCM to get committed first so that we do not disturb any rebase. The
latest commits in trunk were relatively isolated. We could have committed
the last outstanding tickets part of the push for the next release and
still made some exceptions for the TCM work merge after that — just a
constructive approach and visibility.

On a positive note, thank you to everyone who worked and keeps working on
TCM! This is an extreme effort!! I'm super excited!

"Can we get these tests temporarily annotated as skipped while all the
subtickets to 19055 are being worked on"

I am against that. Considering I can see Sam, Alex, and Marcus working
around the clock to solve any test-related tickets, I think there is no
need to do this. Also, in general, ignoring tests also leads to risks of
something being forgotten, a ticket being closed by mistake, and new types
of failures being missed.

"it makes sense to do a repeated run of the new tests."
I do agree with Jacek here.

"I also had to go the route of extracting a blend of what's in circle and
what's in ASF CI (in terms of test suites, filtering, etc) since neither
represented a complete view of our CI ecosystem;"
There is a single test suite in CircleCI, and the packaging needs to be
included.

"From a cursory inspection it looks like most of the breakages being
tracked on the ticket Sam linked for TCM are likely to be circle env
specific (new *nix optimized deletion having a race, OOM's, etc). The TCM
merge is actually a great forcing function for us to surface anything env
specific in terms of timing and resourcing up-front;"
I spent my afternoon triaging the tickets and running repeated runs on
reported failures in the CASSANDRA-19055, as I do not believe we can/should
blindly blame all new failures/flakies on TCM. Unfortunately, all the
tickets I triaged were accurately assigned to TCM, and I don't think there
were more than 1 or 2 OOM tickets.

"My gut tells me it's basically impossible to have a merge of this size
that doesn't disrupt what it's merging into"
I agree with this. There is no way that everything will end smoothly and
perfectly with such extensive work. But we should all recognize the
excellent work that Sam, Alex, and Marcus are doing here to identify and
fix outstanding issues in the past two days. Thank you! I am sure everyone
appreciates that! And I would like to appeal to the community members to
keep triaging and bisecting any new test flakies/failures as we were doing
and not just blindly assign everything to the TCM follow-up epic. We should
be constructive.

"for the record, I don't think we should hold off on merging things just
because some folks are on holiday. :)"

I do not believe anyone advocates for that. I personally even often commit
disruptive patches on the weekend. This gives me the time to deal with the
fallout and reduce the potential disruption to people's work during
office hours. My main concern is what was mentioned already by Benjamin and
Jacek - creating precedent here after all the discussions that happened.


On Mon, 27 Nov 2023 at 16:34, Josh McKenzie  wrote:

> on our internal CI system
>
> Some more context:
>
> This environment adheres to the requirements we laid out in pre-commit CI
> on Cassandra
> 
>  with
> a couple required differences. We don't yet include the resource
> restriction detail in the test report; it's on my backlog of things to do
> but I can confirm that less CPU and <= equivalent ASFCI memory is being
> allocated for each test suite. I also had to go the route of extracting a
> blend of what's in circle and what's in ASF CI (in terms of test suites,
> filtering, etc) since neither represented a complete view of our CI
> ecosystem; there are currently things executed in either environment not
> executed in the other.
>
> I've been tracking the upstreaming of that declarative combination in
> CASSANDRA-18731 but have had some other priorities take front-seat (i.e.
> getting a new CI system based on that working since neither upstream ASF CI
> nor circle are re-usable in their current form) and will be upstreaming
> that ASAP. https://issues.apache.org/jira/browse/CASSANDRA-18731
>
> I've left a pretty long comment on CASSANDRA-18731 about the structure of
> things and where my opinion falls; *I think we need a separate DISCUSS
> thread on the ML about CI and what we require for pre-commit smoke*
> suites:
> https://issues.apache.org/jira/browse/CASSANDRA-18731?focusedCommentId=17790270&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17790270
>
> The TL;DR:
>
> With an *incredibly large* patch in the form of TCM (88k+ LoC, 900+ files
> touched), we have less than a 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[guo Maxwell]

Congrats!

Jacek Lewandowski  于2023年11月29日周三 06:16写道：

> Congrats!!!
>
> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky  napisał:
>
>> Congrats Francisco!
>>
>> > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas 
>> wrote:
>> >
>> > Congratulations, Francisco!
>> >
>> > - Scott
>> >
>> >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>> >>
>> >> The PMC members are pleased to announce that Francisco Guerrero
>> Hernandez has accepted
>> >> the invitation to become committer today.
>> >>
>> >> Congratulations and welcome!
>> >>
>> >> The Apache Cassandra PMC members
>>
>>

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[David Capwell]

+1 from me

> On Nov 28, 2023, at 12:55 PM, Doug Rohrer  wrote:
> 
> +1 (nb, but not a vote, so ¯\_(ツ)_/¯ ) - would be lovely to not have to deal 
> with this individually for each project in which we use the in-jvm dtest 
> framework. As Francisco noted, we’re using this in the sidecar and Analytics 
> projects now and I’ve had to jump through a lot of hoops to get everything 
> building consistently.
> 
> I’ve got some minor modifications to the way in which the existing shading 
> works that I can contribute back to the core Cassandra project (mostly, a few 
> additional relocations and not using the user’s default Maven cache as the 
> temporary installation location as it was difficult to make sure you had the 
> correct dtest jar with a bunch of them in the `.m2` directory).
> 
> Doug
> 
>> On Nov 28, 2023, at 2:51 PM, Josh McKenzie  wrote:
>> 
>> Building these jars every time we run every CI job is just silly.
>> 
>> +1.
>> 
>> On Tue, Nov 28, 2023, at 2:08 PM, Francisco Guerrero wrote:
>>> Hi Abe,
>>> 
>>> I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in 
>>> CI. We'd very
>>> much prefer to just consumed shaded dtest jars from Cassandra releases for 
>>> testing
>>> purposes.
>>> 
>>> Best,
>>> - Francisco
>>> 
>>> On 2023/11/28 19:02:17 Abe Ratnofsky wrote:
>>> > Hey folks - wanted to raise a separate thread to discuss publishing of 
>>> > dtest-shaded JARs on release.
>>> > 
>>> > Currently, adjacent projects that want to use the jvm-dtest framework 
>>> > need to build the shaded JARs themselves. This is a decent amount of 
>>> > work, and is duplicated across each project. This is mainly relevant for 
>>> > projects like Sidecar and Driver. Currently, those projects need to clone 
>>> > and build apache/cassandra themselves, run ant dtest-jar, and move the 
>>> > JAR into the appropriate place. Different build systems treat local JARs 
>>> > differently, and the whole process can be a bit complicated. Would be 
>>> > great to be able to treat these as normal dependencies.
>>> > 
>>> > https://issues.apache.org/jira/browse/CASSANDRA-19113
>>> > 
>>> > Any objections?
>>> > 
>>> > --
>>> > Abe
> 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Jacek Lewandowski]

Congrats!!!

wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky  napisał:

> Congrats Francisco!
>
> > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas 
> wrote:
> >
> > Congratulations, Francisco!
> >
> > - Scott
> >
> >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
> >>
> >> The PMC members are pleased to announce that Francisco Guerrero
> Hernandez has accepted
> >> the invitation to become committer today.
> >>
> >> Congratulations and welcome!
> >>
> >> The Apache Cassandra PMC members
>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Mick Semb Wever]

So then cutting an alpha2 is possible.
>


Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our
best plan.  Doesn't seem worth it IMHO.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

So then cutting an alpha2 is possible.

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 2:59 PM Mick Semb Wever  wrote:
>
>
> You can't change bits in a signed and checksummed artefact.  You have to cut 
> from scratch.
>
> On Tue, 28 Nov 2023 at 20:28, Brandon Williams  wrote:
>>
>> I think the last time I looked into it there was nothing in the
>> scripts that forced anything, but if that's not true I think we should
>> be fixing that, not having it drive our release decisions.
>>
>> Kind Regards,
>> Brandon
>>
>> On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever  wrote:
>> >
>> >
>> >
>> > On Tue, 28 Nov 2023 at 19:27, J. D. Jordan  
>> > wrote:
>> >>
>> >> That said. This is clearly better than and with many fixes from the 
>> >> alpha. Would people be more comfortable if this cut was released as 
>> >> another alpha and we do beta1 once the known fixes land?
>> >
>> >
>> >
>> > There is no way with our release process to do this.  The QA label is part 
>> > of our version number and that's baked in.
>> >
>> > Otherwise I entirely agree that alpha2 would have been the better label 
>> > here.  We are working in an unusual situation, one I hope we don't repeat.
>> >

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Mick Semb Wever]

You can't change bits in a signed and checksummed artefact.  You have to
cut from scratch.

On Tue, 28 Nov 2023 at 20:28, Brandon Williams  wrote:

> I think the last time I looked into it there was nothing in the
> scripts that forced anything, but if that's not true I think we should
> be fixing that, not having it drive our release decisions.
>
> Kind Regards,
> Brandon
>
> On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever  wrote:
> >
> >
> >
> > On Tue, 28 Nov 2023 at 19:27, J. D. Jordan 
> wrote:
> >>
> >> That said. This is clearly better than and with many fixes from the
> alpha. Would people be more comfortable if this cut was released as another
> alpha and we do beta1 once the known fixes land?
> >
> >
> >
> > There is no way with our release process to do this.  The QA label is
> part of our version number and that's baked in.
> >
> > Otherwise I entirely agree that alpha2 would have been the better label
> here.  We are working in an unusual situation, one I hope we don't repeat.
> >
>

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Doug Rohrer]

+1 (nb, but not a vote, so ¯\_(ツ)_/¯ ) - would be lovely to not have to deal 
with this individually for each project in which we use the in-jvm dtest 
framework. As Francisco noted, we’re using this in the sidecar and Analytics 
projects now and I’ve had to jump through a lot of hoops to get everything 
building consistently.

I’ve got some minor modifications to the way in which the existing shading 
works that I can contribute back to the core Cassandra project (mostly, a few 
additional relocations and not using the user’s default Maven cache as the 
temporary installation location as it was difficult to make sure you had the 
correct dtest jar with a bunch of them in the `.m2` directory).

Doug

> On Nov 28, 2023, at 2:51 PM, Josh McKenzie  wrote:
> 
> Building these jars every time we run every CI job is just silly.
> 
> +1.
> 
> On Tue, Nov 28, 2023, at 2:08 PM, Francisco Guerrero wrote:
>> Hi Abe,
>> 
>> I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in 
>> CI. We'd very
>> much prefer to just consumed shaded dtest jars from Cassandra releases for 
>> testing
>> purposes.
>> 
>> Best,
>> - Francisco
>> 
>> On 2023/11/28 19:02:17 Abe Ratnofsky wrote:
>> > Hey folks - wanted to raise a separate thread to discuss publishing of 
>> > dtest-shaded JARs on release.
>> > 
>> > Currently, adjacent projects that want to use the jvm-dtest framework need 
>> > to build the shaded JARs themselves. This is a decent amount of work, and 
>> > is duplicated across each project. This is mainly relevant for projects 
>> > like Sidecar and Driver. Currently, those projects need to clone and build 
>> > apache/cassandra themselves, run ant dtest-jar, and move the JAR into the 
>> > appropriate place. Different build systems treat local JARs differently, 
>> > and the whole process can be a bit complicated. Would be great to be able 
>> > to treat these as normal dependencies.
>> > 
>> > https://issues.apache.org/jira/browse/CASSANDRA-19113
>> > 
>> > Any objections?
>> > 
>> > --
>> > Abe

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Francisco Guerrero]

Thanks everyone! I'm happy to be part of the Cassandra community, now as a
committer. Thanks again to everyone who has helped me onboard in the project
and for the guidance navigating in the project.

I'm looking forward to working with you.

Best,
- Francisco

On 2023/11/28 19:56:09 Arjun Ashok wrote:
> Congrats Francisco!
> 
> On Tue, Nov 28, 2023 at 10:54 AM Dinesh Joshi  wrote:
> 
> > The PMC members are pleased to announce that Francisco Guerrero Hernandez
> > has accepted
> > the invitation to become committer today.
> >
> > Congratulations and welcome!
> >
> > The Apache Cassandra PMC members
> 
> 
> 
> -- 
> 
> Arjun Ashok
> 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Arjun Ashok]

Congrats Francisco!

On Tue, Nov 28, 2023 at 10:54 AM Dinesh Joshi  wrote:

> The PMC members are pleased to announce that Francisco Guerrero Hernandez
> has accepted
> the invitation to become committer today.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members



-- 

Arjun Ashok

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Sam Tunnicliffe]

Congrats Francisco!

> On 28 Nov 2023, at 18:52, Dinesh Joshi  wrote:
> 
> The PMC members are pleased to announce that Francisco Guerrero Hernandez has 
> accepted
> the invitation to become committer today.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Josh McKenzie]

Congrats Francisco!

On Tue, Nov 28, 2023, at 2:37 PM, Melissa Logan wrote:
> Congrats Francisco!
> 
> On Tue, Nov 28, 2023 at 11:34 AM Vinay Chella  wrote:
>> Congratulations Francisco !!
>> 
>> Thanks,
>> Vinay Chella
>> 
>> 
>> On Tue, Nov 28, 2023 at 11:24 AM Mick Semb Wever  wrote:
>>> 
>>> 
>>> On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi  wrote:
 The PMC members are pleased to announce that Francisco Guerrero Hernandez 
 has accepted
 the invitation to become committer today.
 
 Congratulations and welcome!
>>> 
>>> 
>>> Congrats !!

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Josh McKenzie]

Building these jars every time we run every CI job is just silly.

+1.

On Tue, Nov 28, 2023, at 2:08 PM, Francisco Guerrero wrote:
> Hi Abe,
> 
> I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in 
> CI. We'd very
> much prefer to just consumed shaded dtest jars from Cassandra releases for 
> testing
> purposes.
> 
> Best,
> - Francisco
> 
> On 2023/11/28 19:02:17 Abe Ratnofsky wrote:
> > Hey folks - wanted to raise a separate thread to discuss publishing of 
> > dtest-shaded JARs on release.
> > 
> > Currently, adjacent projects that want to use the jvm-dtest framework need 
> > to build the shaded JARs themselves. This is a decent amount of work, and 
> > is duplicated across each project. This is mainly relevant for projects 
> > like Sidecar and Driver. Currently, those projects need to clone and build 
> > apache/cassandra themselves, run ant dtest-jar, and move the JAR into the 
> > appropriate place. Different build systems treat local JARs differently, 
> > and the whole process can be a bit complicated. Would be great to be able 
> > to treat these as normal dependencies.
> > 
> > https://issues.apache.org/jira/browse/CASSANDRA-19113
> > 
> > Any objections?
> > 
> > --
> > Abe
> 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Melissa Logan]

Congrats Francisco!

On Tue, Nov 28, 2023 at 11:34 AM Vinay Chella 
wrote:

> Congratulations Francisco !!
>
> Thanks,
> Vinay Chella
>
>
> On Tue, Nov 28, 2023 at 11:24 AM Mick Semb Wever  wrote:
>
>>
>>
>> On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi  wrote:
>>
>>> The PMC members are pleased to announce that Francisco Guerrero
>>> Hernandez has accepted
>>> the invitation to become committer today.
>>>
>>> Congratulations and welcome!
>>
>>
>>
>> Congrats !!
>>
>

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Vinay Chella]

Congratulations Francisco !!

Thanks,
Vinay Chella


On Tue, Nov 28, 2023 at 11:24 AM Mick Semb Wever  wrote:

>
>
> On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi  wrote:
>
>> The PMC members are pleased to announce that Francisco Guerrero Hernandez
>> has accepted
>> the invitation to become committer today.
>>
>> Congratulations and welcome!
>
>
>
> Congrats !!
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

I think the last time I looked into it there was nothing in the
scripts that forced anything, but if that's not true I think we should
be fixing that, not having it drive our release decisions.

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 12:54 PM Mick Semb Wever  wrote:
>
>
>
> On Tue, 28 Nov 2023 at 19:27, J. D. Jordan  wrote:
>>
>> That said. This is clearly better than and with many fixes from the alpha. 
>> Would people be more comfortable if this cut was released as another alpha 
>> and we do beta1 once the known fixes land?
>
>
>
> There is no way with our release process to do this.  The QA label is part of 
> our version number and that's baked in.
>
> Otherwise I entirely agree that alpha2 would have been the better label here. 
>  We are working in an unusual situation, one I hope we don't repeat.
>

Re: [DISCUSSION] CEP-38: CQL Management API

[Alexander DEJANOVSKI]

Hi Maxim,

I'm part of the K8ssandra team and am very happy to hear that you like our
management API design.
Looking at the CEP, I see that your current target design mentions the
k8ssandra-management-api.
What do you have in mind specifically there? Do you plan on rewriting a
brand new implementation which would be partially inspired by our agent? Or
would the project integrate our agent code in-tree or as a dependency?
The latter would require of course changes to remove the CQL interceptor
and run the queries naturally against Cassandra, along with extracting just
the agent without the REST server.
The former suggests that we'd have to modify our REST server to interact
with the newly developed agent from the Cassandra project.

For the metrics, we were using MCAC
 so far
in the K8ssandra project but the use of collectd (while very convenient for
non kubernetes use cases) and the design issues it created led us to build
a metrics endpoint directly into the management api which hooks on to the
metrics registry, and is out of the box scrapable by Prometheus. As you
mentioned, it also allows us to extend the set of metrics easily, which
we've done recently to expose running compactions and streams as metrics.
It is also very efficient compared to JMX based alternatives.

Let us know how we can help move this CEP forward as we're willing to
participate.
I think it would be great to have a single api that could be used by all
sidecars, may they be custom or officially supported by the project.

Cheers,

Alex

Le mar. 28 nov. 2023 à 01:00, Francisco Guerrero  a
écrit :

> Hi Maxim,
>
> Thanks for working on this CEP!
>
> The CEP addresses some of the features we have been discussing for
> Cassandra Sidecar. For example, a dedicated admin port, moving towards more
> CQL-like interfacing with Cassandra, among others.
>
> I think virtual tables intended to bring the gap down between JMX and CQL.
> However, virtual tables cannot action on node operations, so CEP-38 is
> finally addressing that gap.
>
> I look forward to collaborating in this CEP, I think Cassandra and its
> ecosystem will greatly benefit from this enhancement.
>
> Best,
> - Francisco
>
> On 2023/11/13 18:08:54 Maxim Muzafarov wrote:
> > Hello everyone,
> >
> > While we are still waiting for the review to make the settings virtual
> > table updatable (CASSANDRA-15254), which will improve the
> > configuration management experience for users, I'd like to take
> > another step forward and improve the C* management approach we have as
> > a whole. This approach aims to make all Cassandra management commands
> > accessible via CQL, but not only that.
> >
> > The problem of making commands accessible via CQL presents a complex
> > challenge, especially if we aim to minimize code duplication across
> > the implementation of management operations for different APIs and
> > reduce the overall maintenance burden. The proposal's scope goes
> > beyond simply introducing a new CQL syntax. It encompasses several key
> > objectives for C* management operations, beyond their availability
> > through CQL:
> > - Ensure consistency across all public APIs we support, including JMX
> > MBeans and the newly introduced CQL. Users should see consistent
> > command specifications and arguments, irrespective of whether they're
> > using an API or a CLI;
> > - Reduce source code maintenance costs. With this new approach, when a
> > new command is implemented, it should automatically become available
> > across JMX MBeans, nodetool, CQL, and Cassandra Sidecar, eliminating
> > the need for additional coding;
> > - Maintain backward compatibility, ensuring that existing setups and
> > workflows continue to work the same way as they do today;
> >
> > I would suggest discussing the overall design concept first, and then
> > diving into the CQL command syntax and other details once we've found
> > common ground on the community's vision. However, regardless of these
> > details, I would appreciate any feedback on the design.
> >
> > I look forward to your comments!
> >
> > Please, see the design document: CEP-38: CQL Management API
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API
> >
>

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Mick Semb Wever]

On Tue, 28 Nov 2023 at 19:54, Dinesh Joshi  wrote:

> The PMC members are pleased to announce that Francisco Guerrero Hernandez
> has accepted
> the invitation to become committer today.
>
> Congratulations and welcome!



Congrats !!

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Brandon Williams]

Congrats Francisco!

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 12:53 PM Dinesh Joshi  wrote:
>
> The PMC members are pleased to announce that Francisco Guerrero Hernandez has 
> accepted
> the invitation to become committer today.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Jyothsna Konisa]

Congratulations Francisco!

On Tue, Nov 28, 2023 at 11:10 AM Ekaterina Dimitrova 
wrote:

> Congrats Francisco! Well deserved !
>
> On Tue, 28 Nov 2023 at 14:08, J. D. Jordan 
> wrote:
>
>> Congrats!
>>
>> > On Nov 28, 2023, at 12:57 PM, C. Scott Andreas 
>> wrote:
>> >
>> > Congratulations, Francisco!
>> >
>> > - Scott
>> >
>> >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>> >>
>> >> The PMC members are pleased to announce that Francisco Guerrero
>> Hernandez has accepted
>> >> the invitation to become committer today.
>> >>
>> >> Congratulations and welcome!
>> >>
>> >> The Apache Cassandra PMC members
>>
>

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Ekaterina Dimitrova]

Congrats Francisco! Well deserved !

On Tue, 28 Nov 2023 at 14:08, J. D. Jordan 
wrote:

> Congrats!
>
> > On Nov 28, 2023, at 12:57 PM, C. Scott Andreas 
> wrote:
> >
> > Congratulations, Francisco!
> >
> > - Scott
> >
> >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
> >>
> >> The PMC members are pleased to announce that Francisco Guerrero
> Hernandez has accepted
> >> the invitation to become committer today.
> >>
> >> Congratulations and welcome!
> >>
> >> The Apache Cassandra PMC members
>

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Francisco Guerrero]

Hi Abe,

I'm +1 on this. Several Cassandra-ecosystem projects build the dtest jar in CI. 
We'd very
much prefer to just consumed shaded dtest jars from Cassandra releases for 
testing
purposes.

Best,
- Francisco

On 2023/11/28 19:02:17 Abe Ratnofsky wrote:
> Hey folks - wanted to raise a separate thread to discuss publishing of 
> dtest-shaded JARs on release.
> 
> Currently, adjacent projects that want to use the jvm-dtest framework need to 
> build the shaded JARs themselves. This is a decent amount of work, and is 
> duplicated across each project. This is mainly relevant for projects like 
> Sidecar and Driver. Currently, those projects need to clone and build 
> apache/cassandra themselves, run ant dtest-jar, and move the JAR into the 
> appropriate place. Different build systems treat local JARs differently, and 
> the whole process can be a bit complicated. Would be great to be able to 
> treat these as normal dependencies.
> 
> https://issues.apache.org/jira/browse/CASSANDRA-19113
> 
> Any objections?
> 
> --
> Abe

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Ekaterina Dimitrova]

“The QA label is part of our version number and that's baked in.”


How can we have beta 2, but there is no way for alpha 2?

On Tue, 28 Nov 2023 at 13:55, Mick Semb Wever  wrote:

>
>
> On Tue, 28 Nov 2023 at 19:27, J. D. Jordan 
> wrote:
>
>> That said. This is clearly better than and with many fixes from the
>> alpha. Would people be more comfortable if this cut was released as another
>> alpha and we do beta1 once the known fixes land?
>>
>
>
> There is no way with our release process to do this.  The QA label is part
> of our version number and that's baked in.
>
> Otherwise I entirely agree that alpha2 would have been the better label
> here.  We are working in an unusual situation, one I hope we don't repeat.
>
>

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[J. D. Jordan]

Congrats!

> On Nov 28, 2023, at 12:57 PM, C. Scott Andreas  wrote:
> 
> Congratulations, Francisco!
> 
> - Scott
> 
>> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>> 
>> The PMC members are pleased to announce that Francisco Guerrero Hernandez 
>> has accepted
>> the invitation to become committer today.
>> 
>> Congratulations and welcome!
>> 
>> The Apache Cassandra PMC members

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Yifan Cai]

Congratulations! It is well deserved.

发件人: C. Scott Andreas 
发送时间: Wednesday, November 29, 2023 2:56:34 AM
收件人: dev@cassandra.apache.org 
主题: Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

Congratulations, Francisco!

- Scott

> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>
> The PMC members are pleased to announce that Francisco Guerrero Hernandez 
> has accepted
> the invitation to become committer today.
>
> Congratulations and welcome!
>
> The Apache Cassandra PMC members

[DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Abe Ratnofsky]

Hey folks - wanted to raise a separate thread to discuss publishing of 
dtest-shaded JARs on release.

Currently, adjacent projects that want to use the jvm-dtest framework need to 
build the shaded JARs themselves. This is a decent amount of work, and is 
duplicated across each project. This is mainly relevant for projects like 
Sidecar and Driver. Currently, those projects need to clone and build 
apache/cassandra themselves, run ant dtest-jar, and move the JAR into the 
appropriate place. Different build systems treat local JARs differently, and 
the whole process can be a bit complicated. Would be great to be able to treat 
these as normal dependencies.

https://issues.apache.org/jira/browse/CASSANDRA-19113

Any objections?

--
Abe

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Abe Ratnofsky]

Congrats Francisco!

> On Nov 28, 2023, at 1:56 PM, C. Scott Andreas  wrote:
> 
> Congratulations, Francisco!
> 
> - Scott
> 
>> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>> 
>> The PMC members are pleased to announce that Francisco Guerrero Hernandez 
>> has accepted
>> the invitation to become committer today.
>> 
>> Congratulations and welcome!
>> 
>> The Apache Cassandra PMC members

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[C. Scott Andreas]

Congratulations, Francisco!

- Scott

> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
> 
> The PMC members are pleased to announce that Francisco Guerrero Hernandez 
> has accepted
> the invitation to become committer today.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: [DISCUSS] Harry in-tree

[Abe Ratnofsky]

Another strong +1 to have Harry in-tree, and another +1 to building shaded 
dtest JARs on release. There are a number of projects that would benefit from 
having these JARs available in a central repository, like Sidecar, Driver, etc. 
I didn't see a ticket so created one: 
https://issues.apache.org/jira/browse/CASSANDRA-19113

> On Nov 28, 2023, at 3:12 AM, Alex Petrov  wrote:
> 
> Sure, that should be possible. I will check and will get back.
> 
> On Mon, Nov 27, 2023, at 10:10 PM, Ekaterina Dimitrova wrote:
>> +1, also, Alex, just an idea - maybe you want to make a virtual talk, as 
>> part of the contributors meetings? 
>> 
>> 
>> На понеделник, 27 ноември 2023 г. Yifan Cai > > написа:
>> +1
>> 
>> 
>> 发件人: Sam Tunnicliffe mailto:s...@beobal.com>>
>> 发送时间: Tuesday, November 28, 2023 2:43:51 AM
>> 收件人: dev mailto:dev@cassandra.apache.org>>
>> 主题: Re: [DISCUSS] Harry in-tree
>>  
>> Definite +1 to bringing harry-core in tree.
>> 
>>> On 24 Nov 2023, at 15:43, Alex Petrov >> > wrote:
>>> 
>>> Hi everyone,
>>> 
>>> With TCM landed, there will be way more Harry tests in-tree: we are using 
>>> it for many coordination tests, and there's now a simulator test that uses 
>>> Harry. During development, Harry has allowed us to uncover and resolve 
>>> numerous elusive edge cases.
>>> 
>>> I had conversations with several folks, and wanted to propose to move 
>>> harry-core to Cassandra test tree. This will substantially 
>>> simplify/streamline co-development of Cassandra and Harry. With a new 
>>> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
>>> will also be much more approachable.
>>> 
>>> Besides making it easier for everyone to develop new fuzz tests, it will 
>>> also substantially lower the barrier to entry. Currently, debugging an 
>>> issue found by Harry involves a cumbersome process of rebuilding and 
>>> transferring jars between Cassandra and Harry, depending on which side you 
>>> modify. This not only hampers efficiency but also deters broader adoption. 
>>> By merging harry-core into the Cassandra test tree, we eliminate this 
>>> barrier.
>>> 
>>> Thank you,
>>> --Alex
>>> 
>>> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
>>> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
>>> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Mick Semb Wever]

On Tue, 28 Nov 2023 at 19:27, J. D. Jordan 
wrote:

> That said. This is clearly better than and with many fixes from the alpha.
> Would people be more comfortable if this cut was released as another alpha
> and we do beta1 once the known fixes land?
>


There is no way with our release process to do this.  The QA label is part
of our version number and that's baked in.

Otherwise I entirely agree that alpha2 would have been the better label
here.  We are working in an unusual situation, one I hope we don't repeat.

Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Dinesh Joshi]

The PMC members are pleased to announce that Francisco Guerrero Hernandez has 
accepted
the invitation to become committer today.

Congratulations and welcome!

The Apache Cassandra PMC members

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Caleb Rackliffe]

If the consensus is that meaningful community testing will occur in the
week between "beta1 but SAI is broken, friends" and "ok, beta2, it's fixed
now, go for it"...then go for it.

On Tue, Nov 28, 2023 at 12:40 PM Patrick McFadin  wrote:

> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need people looking
> today because they will find new bugs and the signal is lost on alpha. It's
> too yolo for most people.
>
> On Tue, Nov 28, 2023 at 10:36 AM Benjamin Lerer  wrote:
>
>> -1 based on the problems raised by Caleb.
>>
>> I would be fine with releasing that version as an alpha as Jeremiah
>> proposed.
>>
>> As of this time, I'm also not aware of a user of the project operating a
>>> build from the 5.0 branch at substantial scale to suss out the operational
>>> side of what can be expected. If someone is running a build supporting
>>> non-perf-test traffic derived from the 5.0 branch and has an experience
>>> report to share it would be great to read.
>>
>>
>> Some people at Datastax are working on such testing. It will take a bit
>> of time before we get the final results though.
>>
>> Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
>> écrit :
>>
>>> That said. This is clearly better than and with many fixes from the
>>> alpha. Would people be more comfortable if this cut was released as another
>>> alpha and we do beta1 once the known fixes land?
>>>
>>> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
>>> wrote:
>>>
>>> 
>>> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
>>> would think we should re-cut beta1 at the end of the week.
>>>
>>> On Nov 28, 2023, at 12:06 PM, Patrick McFadin 
>>> wrote:
>>>
>>> 
>>> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
>>> especially if there are declared known issues. We need people outside of
>>> this tight group using it and finding issues. I know how this rolls. Very
>>> few people touch a Alpha release. Beta is when the engine starts and we
>>> need to get it started asap. Otherwise we are telling ourselves we have the
>>> perfect testing apparatus and don't need more users testing. I don't think
>>> that is the case.
>>>
>>> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking
>>> about Cassandra 5 in the keynotes. In that time, our call to action is
>>> going to be to test the beta.
>>>
>>> Patrick
>>>
>>> On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:
>>>
 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 11+17)
 - binary artefact runs (JDK 11+17)
 - debian package runs (JDK 11+17)
 - debian repo runs (JDK 11+17)
 - redhat* package runs (JDK11+17)
 - redhat* repo runs (JDK 11+17)


 With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
 fixes to be available soon in 5.0-beta2.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Jeff Jirsa]

-0 to cutting a beta we know has a very obvious correctness flaw with a fix
already understood



On Tue, Nov 28, 2023 at 10:40 AM Patrick McFadin  wrote:

> JD, that wasn't my point. It feels like we are treating a beta like an RC,
> which it isn't. Ship Beta 1 now and Beta 2 later. We need people looking
> today because they will find new bugs and the signal is lost on alpha. It's
> too yolo for most people.
>
> On Tue, Nov 28, 2023 at 10:36 AM Benjamin Lerer  wrote:
>
>> -1 based on the problems raised by Caleb.
>>
>> I would be fine with releasing that version as an alpha as Jeremiah
>> proposed.
>>
>> As of this time, I'm also not aware of a user of the project operating a
>>> build from the 5.0 branch at substantial scale to suss out the operational
>>> side of what can be expected. If someone is running a build supporting
>>> non-perf-test traffic derived from the 5.0 branch and has an experience
>>> report to share it would be great to read.
>>
>>
>> Some people at Datastax are working on such testing. It will take a bit
>> of time before we get the final results though.
>>
>> Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
>> écrit :
>>
>>> That said. This is clearly better than and with many fixes from the
>>> alpha. Would people be more comfortable if this cut was released as another
>>> alpha and we do beta1 once the known fixes land?
>>>
>>> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
>>> wrote:
>>>
>>> 
>>> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
>>> would think we should re-cut beta1 at the end of the week.
>>>
>>> On Nov 28, 2023, at 12:06 PM, Patrick McFadin 
>>> wrote:
>>>
>>> 
>>> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
>>> especially if there are declared known issues. We need people outside of
>>> this tight group using it and finding issues. I know how this rolls. Very
>>> few people touch a Alpha release. Beta is when the engine starts and we
>>> need to get it started asap. Otherwise we are telling ourselves we have the
>>> perfect testing apparatus and don't need more users testing. I don't think
>>> that is the case.
>>>
>>> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking
>>> about Cassandra 5 in the keynotes. In that time, our call to action is
>>> going to be to test the beta.
>>>
>>> Patrick
>>>
>>> On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:
>>>
 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 11+17)
 - binary artefact runs (JDK 11+17)
 - debian package runs (JDK 11+17)
 - debian repo runs (JDK 11+17)
 - redhat* package runs (JDK11+17)
 - redhat* repo runs (JDK 11+17)


 With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
 fixes to be available soon in 5.0-beta2.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Patrick McFadin]

JD, that wasn't my point. It feels like we are treating a beta like an RC,
which it isn't. Ship Beta 1 now and Beta 2 later. We need people looking
today because they will find new bugs and the signal is lost on alpha. It's
too yolo for most people.

On Tue, Nov 28, 2023 at 10:36 AM Benjamin Lerer  wrote:

> -1 based on the problems raised by Caleb.
>
> I would be fine with releasing that version as an alpha as Jeremiah
> proposed.
>
> As of this time, I'm also not aware of a user of the project operating a
>> build from the 5.0 branch at substantial scale to suss out the operational
>> side of what can be expected. If someone is running a build supporting
>> non-perf-test traffic derived from the 5.0 branch and has an experience
>> report to share it would be great to read.
>
>
> Some people at Datastax are working on such testing. It will take a bit of
> time before we get the final results though.
>
> Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
> écrit :
>
>> That said. This is clearly better than and with many fixes from the
>> alpha. Would people be more comfortable if this cut was released as another
>> alpha and we do beta1 once the known fixes land?
>>
>> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
>> wrote:
>>
>> 
>> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
>> would think we should re-cut beta1 at the end of the week.
>>
>> On Nov 28, 2023, at 12:06 PM, Patrick McFadin  wrote:
>>
>> 
>> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
>> especially if there are declared known issues. We need people outside of
>> this tight group using it and finding issues. I know how this rolls. Very
>> few people touch a Alpha release. Beta is when the engine starts and we
>> need to get it started asap. Otherwise we are telling ourselves we have the
>> perfect testing apparatus and don't need more users testing. I don't think
>> that is the case.
>>
>> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about
>> Cassandra 5 in the keynotes. In that time, our call to action is going to
>> be to test the beta.
>>
>> Patrick
>>
>> On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:
>>
>>> 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 11+17)
>>> - binary artefact runs (JDK 11+17)
>>> - debian package runs (JDK 11+17)
>>> - debian repo runs (JDK 11+17)
>>> - redhat* package runs (JDK11+17)
>>> - redhat* repo runs (JDK 11+17)
>>>
>>>
>>> With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
>>> fixes to be available soon in 5.0-beta2.
>>>
>>>
>>>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Caleb Rackliffe]

I'm fine w/ alpha2 now and beta1 once we resolve 19011.

On Tue, Nov 28, 2023 at 12:36 PM Benjamin Lerer  wrote:

> -1 based on the problems raised by Caleb.
>
> I would be fine with releasing that version as an alpha as Jeremiah
> proposed.
>
> As of this time, I'm also not aware of a user of the project operating a
>> build from the 5.0 branch at substantial scale to suss out the operational
>> side of what can be expected. If someone is running a build supporting
>> non-perf-test traffic derived from the 5.0 branch and has an experience
>> report to share it would be great to read.
>
>
> Some people at Datastax are working on such testing. It will take a bit of
> time before we get the final results though.
>
> Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
> écrit :
>
>> That said. This is clearly better than and with many fixes from the
>> alpha. Would people be more comfortable if this cut was released as another
>> alpha and we do beta1 once the known fixes land?
>>
>> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
>> wrote:
>>
>> 
>> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
>> would think we should re-cut beta1 at the end of the week.
>>
>> On Nov 28, 2023, at 12:06 PM, Patrick McFadin  wrote:
>>
>> 
>> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
>> especially if there are declared known issues. We need people outside of
>> this tight group using it and finding issues. I know how this rolls. Very
>> few people touch a Alpha release. Beta is when the engine starts and we
>> need to get it started asap. Otherwise we are telling ourselves we have the
>> perfect testing apparatus and don't need more users testing. I don't think
>> that is the case.
>>
>> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about
>> Cassandra 5 in the keynotes. In that time, our call to action is going to
>> be to test the beta.
>>
>> Patrick
>>
>> On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:
>>
>>> 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 11+17)
>>> - binary artefact runs (JDK 11+17)
>>> - debian package runs (JDK 11+17)
>>> - debian repo runs (JDK 11+17)
>>> - redhat* package runs (JDK11+17)
>>> - redhat* repo runs (JDK 11+17)
>>>
>>>
>>> With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
>>> fixes to be available soon in 5.0-beta2.
>>>
>>>
>>>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Benjamin Lerer]

-1 based on the problems raised by Caleb.

I would be fine with releasing that version as an alpha as Jeremiah
proposed.

As of this time, I'm also not aware of a user of the project operating a
> build from the 5.0 branch at substantial scale to suss out the operational
> side of what can be expected. If someone is running a build supporting
> non-perf-test traffic derived from the 5.0 branch and has an experience
> report to share it would be great to read.


Some people at Datastax are working on such testing. It will take a bit of
time before we get the final results though.

Le mar. 28 nov. 2023 à 19:27, J. D. Jordan  a
écrit :

> That said. This is clearly better than and with many fixes from the alpha.
> Would people be more comfortable if this cut was released as another alpha
> and we do beta1 once the known fixes land?
>
> On Nov 28, 2023, at 12:21 PM, J. D. Jordan 
> wrote:
>
> 
> -0 (NB) on this cut. Given the concerns expressed so far in the thread I
> would think we should re-cut beta1 at the end of the week.
>
> On Nov 28, 2023, at 12:06 PM, Patrick McFadin  wrote:
>
> 
> I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
> especially if there are declared known issues. We need people outside of
> this tight group using it and finding issues. I know how this rolls. Very
> few people touch a Alpha release. Beta is when the engine starts and we
> need to get it started asap. Otherwise we are telling ourselves we have the
> perfect testing apparatus and don't need more users testing. I don't think
> that is the case.
>
> Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about
> Cassandra 5 in the keynotes. In that time, our call to action is going to
> be to test the beta.
>
> Patrick
>
> On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:
>
>> 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 11+17)
>> - binary artefact runs (JDK 11+17)
>> - debian package runs (JDK 11+17)
>> - debian repo runs (JDK 11+17)
>> - redhat* package runs (JDK11+17)
>> - redhat* repo runs (JDK 11+17)
>>
>>
>> With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
>> fixes to be available soon in 5.0-beta2.
>>
>>
>>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[J. D. Jordan]

That said. This is clearly better than and with many fixes from the alpha. Would people be more comfortable if this cut was released as another alpha and we do beta1 once the known fixes land?On Nov 28, 2023, at 12:21 PM, J. D. Jordan  wrote:-0 (NB) on this cut. Given the concerns expressed so far in the thread I would think we should re-cut beta1 at the end of the week.On Nov 28, 2023, at 12:06 PM, Patrick McFadin  wrote:I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect especially if there are declared known issues. We need people outside of this tight group using it and finding issues. I know how this rolls. Very few people touch a Alpha release. Beta is when the engine starts and we need to get it started asap. Otherwise we are telling ourselves we have the perfect testing apparatus and don't need more users testing. I don't think that is the case. Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about Cassandra 5 in the keynotes. In that time, our call to action is going to be to test the beta. PatrickOn Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote: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.+1Checked- signing correct- checksums are correct- source artefact builds (JDK 11+17)- binary artefact runs (JDK 11+17)- debian package runs (JDK 11+17)- debian repo runs (JDK 11+17)- redhat* package runs (JDK11+17)- redhat* repo runs (JDK 11+17)With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with fixes to be available soon in 5.0-beta2.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[J. D. Jordan]

-0 (NB) on this cut. Given the concerns expressed so far in the thread I would think we should re-cut beta1 at the end of the week.On Nov 28, 2023, at 12:06 PM, Patrick McFadin  wrote:I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect especially if there are declared known issues. We need people outside of this tight group using it and finding issues. I know how this rolls. Very few people touch a Alpha release. Beta is when the engine starts and we need to get it started asap. Otherwise we are telling ourselves we have the perfect testing apparatus and don't need more users testing. I don't think that is the case. Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about Cassandra 5 in the keynotes. In that time, our call to action is going to be to test the beta. PatrickOn Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote: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.+1Checked- signing correct- checksums are correct- source artefact builds (JDK 11+17)- binary artefact runs (JDK 11+17)- debian package runs (JDK 11+17)- debian repo runs (JDK 11+17)- redhat* package runs (JDK11+17)- redhat* repo runs (JDK 11+17)With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with fixes to be available soon in 5.0-beta2.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Patrick McFadin]

I'm a +1 on a beta now vs maybe later. Beta doesn't imply perfect
especially if there are declared known issues. We need people outside of
this tight group using it and finding issues. I know how this rolls. Very
few people touch a Alpha release. Beta is when the engine starts and we
need to get it started asap. Otherwise we are telling ourselves we have the
perfect testing apparatus and don't need more users testing. I don't think
that is the case.

Scott, Ekaterina, and I are going to be on stage in 2 weeks talking about
Cassandra 5 in the keynotes. In that time, our call to action is going to
be to test the beta.

Patrick

On Tue, Nov 28, 2023 at 9:41 AM Mick Semb Wever  wrote:

> 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 11+17)
> - binary artefact runs (JDK 11+17)
> - debian package runs (JDK 11+17)
> - debian repo runs (JDK 11+17)
> - redhat* package runs (JDK11+17)
> - redhat* repo runs (JDK 11+17)
>
>
> With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
> fixes to be available soon in 5.0-beta2.
>
>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[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 11+17)
- binary artefact runs (JDK 11+17)
- debian package runs (JDK 11+17)
- debian repo runs (JDK 11+17)
- redhat* package runs (JDK11+17)
- redhat* repo runs (JDK 11+17)


With the disclaimer:  There's a few known bugs in SAI, e.g. 19011, with
fixes to be available soon in 5.0-beta2.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Mick Semb Wever]

>
> Compared to the rigor of our previous major release, this feels rushed and
> timeline-driven rather than anchored in values of quality and data
> integrity.
>


Yes, it is (unfortunately) time-driven.  But rather than say rushed I would
say incremental.

At the Summit, whatever release we end up with is the release users will
take and play with.
I worry less about what the users think about our alpha and beta
definitions, and more about the end QA of the release they are playing with.

And while we can hope for the best, we should prepare for the worst.
Every vote has a chance of being vetoed.  We cannot count that a new vote
next week will make it through.
Therefore I would rather see this beta1 out, as an improved mitigation over
having only the alpha1.

19011 pushes me to ensure beta2 happens next week, rather than to veto
beta1.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[C. Scott Andreas]

Agreed with Brandon, yes. I'm at a "-0 (nb)" on a beta release at this point. We're clearly finding (and 
resolving) lots of significant and in some case serious issues - ones that violate fundamental properties of the 
database. I'm very glad that we're finding and fixing these, but they feel like late and lucky catches rather than 
the result of a standardized and rigorous validation process. This sentiment isn't specific to a particular feature. 
As of this time, I'm also not aware of a user of the project operating a build from the 5.0 branch at substantial 
scale to suss out the operational side of what can be expected. If someone is running a build supporting 
non-perf-test traffic derived from the 5.0 branch and has an experience report to share it would be great to read. 
Compared to the rigor of our previous major release, this feels rushed and timeline-driven rather than anchored in 
values of quality and data integrity. – Scott On Nov 28, 2023, at 9:20 AM, Brandon Williams  
wrote: If we are going to commit to beta2 before the summit because "putting a beta w/ SAI in this state into 
users’ hands at summit would be very, very bad" I don't see why we need to have a subpar beta1 at all? Kind 
Regards, Brandon On Tue, Nov 28, 2023 at 11:16 AM Mick Semb Wever  wrote: On Tue, 28 Nov 2023 
at 18:06, Caleb Rackliffe  wrote: Just to update this thread, Mike has identified the 
root cause of 19011 and in the process uncovered 2 additional very closely related issues. (Fantastic job fuzzing 
there!) Fixes for all three issues are in hand, and he continues to test. After some conversation w/ Mick, Alex, and 
Mike, I feel like cutting a beta1 now is fine as long as we commit to a beta2 before summit that includes 19011. 
Putting a beta w/ SAI in this state into users’ hands at summit would be very, very bad. In case this sounds weird, 
to clarify: this is a mitigation action – there's a risk with every release that it does not make it through. beta1 
might not be great for SAI, but getting it out is better than having only alpha1 available come Summit. It might feel 
odd to have a beta2 right after a beta1, but I don't mind (and would rather) take the time and investment. beta1 
would be announced with an appropriate disclaimer.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Brandon Williams]

If we are going to commit to beta2 before the summit because "putting
a beta w/ SAI in this state into users’ hands at summit would be very,
very bad" I don't see why we need to have a subpar beta1 at all?

Kind Regards,
Brandon

On Tue, Nov 28, 2023 at 11:16 AM Mick Semb Wever  wrote:
>
>
>
> On Tue, 28 Nov 2023 at 18:06, Caleb Rackliffe  
> wrote:
>>
>> Just to update this thread, Mike has identified the root cause of 19011 and 
>> in the process uncovered 2 additional very closely related issues. 
>> (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and 
>> he continues to test.
>>
>> After some conversation w/ Mick, Alex, and Mike, I feel like cutting a beta1 
>> now is fine as long as we commit to a beta2 before summit that includes 
>> 19011. Putting a beta w/ SAI in this state into users’ hands at summit would 
>> be very, very bad.
>
>
>
> In case this sounds weird, to clarify:  this is a mitigation action – there's 
> a risk with every release that it does not make it through.  beta1 might not 
> be great for SAI, but getting it out is better than having only alpha1 
> available come Summit.  It might feel odd to have a beta2 right after a 
> beta1, but I don't mind (and would rather) take the time and investment.
>
> beta1 would be announced with an appropriate disclaimer.
>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Mick Semb Wever]

On Tue, 28 Nov 2023 at 18:06, Caleb Rackliffe 
wrote:

> Just to update this thread, Mike has identified the root cause of 19011
> and in the process uncovered 2 additional very closely related issues.
> (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and
> he continues to test.
>
> After some conversation w/ Mick, Alex, and Mike, I feel like cutting a
> beta1 now is fine as long as we commit to a beta2 before summit that
> includes 19011. Putting a beta w/ SAI in this state into users’ hands at
> summit would be very, very bad.
>


In case this sounds weird, to clarify:  this is a mitigation action –
there's a risk with every release that it does not make it through.  beta1
might not be great for SAI, but getting it out is better than having only
alpha1 available come Summit.  It might feel odd to have a beta2 right
after a beta1, but I don't mind (and would rather) take the time and
investment.

beta1 would be announced with an appropriate disclaimer.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Caleb Rackliffe]

Just to update this thread, Mike has identified the root cause of 19011 and in the process uncovered 2 additional very closely related issues. (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and he continues to test.After some conversation w/ Mick, Alex, and Mike, I feel like cutting a beta1 now is fine as long as we commit to a beta2 before summit that includes 19011. Putting a beta w/ SAI in this state into users’ hands at summit would be very, very bad.On Nov 27, 2023, at 12:21 PM, Mike Adamson  wrote:> Furthermore, we don't even know if it's still an issue after 19034 was committed. It's a difficult one to reproduce because we don't have access to the harry script that generated the error in the first place. I am investigating it but without the original reproduction it may take some time.On Mon, 27 Nov 2023 at 16:19, Mick Semb Wever  wrote:On Mon, 27 Nov 2023 at 16:28, Brandon Williams  wrote:On Mon, Nov 27, 2023 at 9:25 AM Mick Semb Wever  wrote:
>
> It was agreed to move them to 5.0-rc

Where?
Typo, "it" not "them".I'm only talking about 19011.  The others were already 5.0-rc, or infact forward from 5.0.x.Here:  https://issues.apache.org/jira/browse/CASSANDRA-19011?focusedCommentId=17789202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17789202Furthermore, we don't even know if it's still an issue after 19034 was committed.  We want to figure this out before the vote window closes. 
-- Mike AdamsonEngineering+1 650 389 6000 | datastax.comFind DataStax Online:        

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

[Jacek Lewandowski]

Should I assume it's an agreement?

- - -- --- -  -
Jacek Lewandowski


wt., 28 lis 2023 o 12:05 Mick Semb Wever  napisał(a):

>
>
> So, assuming beta2, can it be merged to cassandra-5.0 now?
>>
>
>
> Yes from me.
> And I would interpret Brandon and Maxwell's statements as supporting too.
>
>
>

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

[Mick Semb Wever]

So, assuming beta2, can it be merged to cassandra-5.0 now?
>


Yes from me.
And I would interpret Brandon and Maxwell's statements as supporting too.

Re: Include CASSANDRA-18464 in 5.0-beta1 (direct I/O support for commitlog write)

[Jacek Lewandowski]

So, assuming beta2, can it be merged to cassandra-5.0 now?

- - -- --- -  -
Jacek Lewandowski


pon., 27 lis 2023 o 16:02 Mick Semb Wever  napisał(a):

>
> I don't want to veto the 5.0-beta1 release for this.
>
> I would rather cut and include it in the next: 5.0-beta2; release.
> Given it's an add-on and does not change default behaviour, I believe this
> would be ok – if we agree.
>
> I feel this would be a better use of our time.  And would mean, yes commit
> to cassandra-5.0
>
>
>
>
> On Mon, 27 Nov 2023 at 14:04, Jacek Lewandowski <
> lewandowski.ja...@gmail.com> wrote:
>
>> Hey,
>>
>> I'd like to ask if we can include
>> https://issues.apache.org/jira/browse/CASSANDRA-18464 in the 5.0-beta1
>> release. This introduces the ability to write to the commitlog using direct
>> I/O and bringing some noticeable performance improvements when enabled
>> (disabled by default).
>>
>> Since it introduces a change in the yaml config, it probably cannot be
>> delivered in RC or 5.0.x - hence my question.
>>
>> The ticket has been reviewed and tested. It is basically in the
>> read-to-commit state.
>>
>> thanks,
>> Jacek
>>
>>

Re: [DISCUSS] Harry in-tree

[Alex Petrov]

Sure, that should be possible. I will check and will get back.

On Mon, Nov 27, 2023, at 10:10 PM, Ekaterina Dimitrova wrote:
> +1, also, Alex, just an idea - maybe you want to make a virtual talk, as part 
> of the contributors meetings? 
> 
> 
> На понеделник, 27 ноември 2023 г. Yifan Cai  написа:
>> +1
>> 
>> 
>> *发件人:* Sam Tunnicliffe 
>> *发送时间:* Tuesday, November 28, 2023 2:43:51 AM
>> *收件人:* dev 
>> *主题:* Re: [DISCUSS] Harry in-tree
>>  
>> Definite +1 to bringing harry-core in tree.
>> 
>>> On 24 Nov 2023, at 15:43, Alex Petrov  wrote:
>>> 
>>> Hi everyone,
>>> 
>>> With TCM landed, there will be way more Harry tests in-tree: we are using 
>>> it for many coordination tests, and there's now a simulator test that uses 
>>> Harry. During development, Harry has allowed us to uncover and resolve 
>>> numerous elusive edge cases.
>>> 
>>> I had conversations with several folks, and wanted to propose to move 
>>> harry-core to Cassandra test tree. This will substantially 
>>> simplify/streamline co-development of Cassandra and Harry. With a new 
>>> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
>>> will also be much more approachable.
>>> 
>>> Besides making it easier for everyone to develop new fuzz tests, it will 
>>> also substantially lower the barrier to entry. Currently, debugging an 
>>> issue found by Harry involves a cumbersome process of rebuilding and 
>>> transferring jars between Cassandra and Harry, depending on which side you 
>>> modify. This not only hampers efficiency but also deters broader adoption. 
>>> By merging harry-core into the Cassandra test tree, we eliminate this 
>>> barrier.
>>> 
>>> Thank you,
>>> --Alex
>>> 
>>> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
>>> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
>>> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932