Re: [VOTE] Release Apache Cassandra 5.0-beta1

[German Eichberger via dev]

I don't think outside people will know the distinction between alpha and beta - 
for them anything which isn't GA doesn't get deployed  (and even then they 
might wait another year or two).

People following this mailing list would lilkey know that 5.0-beta-1 is pretty 
close to 5.0-alpha-3 -- so I am supporting releasing to hit the date, At this 
point it's semantics...

Thanks,
German

From: Maxim Muzafarov 
Sent: Thursday, November 30, 2023 3:12 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-beta1

I'm gonna take a moment to outline the question. Here we have a point
in time where a time-driven release process clashes with the
alpha/beta release naming convention: we want to have a beta ready
_before_ the Summit.

Here's the Cassandra release lifecycle document [1] that I found
(still under discussion I think) and according to the 'beta'
definition we should have a green CI and no regressions for a beta
release.  This means that there may be known bugs in the new features
we are trying to ship. Unless I'm not missing something, 5.0 currently
meets the 'beta' criteria and the definition itself sounds clear to
me.

So, the question is - should we find a better place for the [1] page
and move it somewhere under the 'officially accepted'? :-)

[1] 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fdisplay%2FCASSANDRA%2FRelease%2BLifecycle&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7C1ec418c7eb5040f7acaf08dbf1955153%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638369395848575700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hE9tInVzW9GAhR7IbuMASiOpTaHuaMb9455HVBRaMx4%3D&reserved=0

On Thu, 30 Nov 2023 at 07:39, Jacek Lewandowski
 wrote:
>>
>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>> will signal to the community that we’re prioritizing stability and it could 
>> be a good opportunity to get people to test the beta or RC before we stamp 
>> it as production ready.
>
>
> I agree with Paulo's comment
>
> czw., 30 lis 2023 o 04:44 Paulo Motta  napisał(a):
>>
>> > if any contributor has an opinion which is not technically refuted it will 
>> > usually be backed by a PMC via a binding -1
>>
>> clarifying a bit my personal view: if any contributor has an opinion against 
>> a proposal (in this case this release proposal) that is not refuted it will 
>> usually be backed by a PMC via binding -1
>>
>> Opinions supporting the proposal are also valuable, provided there are no 
>> valid claims against a proposal.
>>
>> On Wed, 29 Nov 2023 at 22:27 Paulo Motta  wrote:
>>>
>>> To me, the goal of a beta is to find unknown bugs. If no new bugs are found 
>>> during a beta release, then it can be automatically promoted to RC via 
>>> re-tagging. Likewise, if no new bugs are found during a RC after X time, 
>>> then it can be promoted to final.
>>>
>>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>>> will signal to the community that we’re prioritizing stability and it could 
>>> be a good opportunity to get people to test the beta or RC before we stamp 
>>> it as production ready.
>>>
>>> WDYT?
>>>
>>> >  Aaron (and anybody who takes the time to follow this list, really), your 
>>> > opinion matters, that's why we discuss it here.
>>>
>>> +1, PMC are just officers who endorse community decisions, so if any 
>>> contributor has an opinion which is not technically refuted it will usually 
>>> be backed by a PMC via a binding -1 (as seen on this thread)
>>>
>>> On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:



 On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko  
 wrote:
>
> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now, 
> but I’m not sure there is significant value to be had from it. Merge the 
> fixes for outstanding issues listed above, then cut beta1.

 

 Agree with Aleksey. -1 on a beta we know has issues with a top-line new 
 feature.

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Alex Petrov]

I will try to resopnd, but please keep in mind that all these terms are 
somewhat contextual. 

I think long and burn tests are somewhat synonymous. But most long/burn tests 
that we have in-tree aren't actually that long. They are just long compared to 
the unit tests. I personally would call the test long when it runs for hours at 
least, but realistically for days. 

Fuzz tests are randomised tests that attempt to find issues in the system under 
test. Most of fuzz tests we wrote using Harry are also property-based: they are 
using a model checker to simulate an internal state of the system and check its 
responses with a simplified representation.

Simulator tests are just tests that use our simulator framework, that executes 
a test against a cluster of nodes deterministically by fully serialising all of 
its operations. We also have a bunch of smaller simulations that simulate 
different scenarios: bounces, metadata changes, etc, without actually starting 
the cluster. Those are not simulator tests though. I have also used the word 
"simulate" in the context of model-checking, but also mostly to illustrate that 
it's all context-dependent. 

I personally believe that many tests, and test pipelines can (and probably 
should) be deprecated. But last time I brought this up, there was a bit of 
pushback, so I think before we can consider deprecation of tests that we think 
are redundant we will have to substantially improve adoption of the tools that 
allow better multiplexing.

As regards configurations, I do not think it is necessary to re-run an entire 
set of u/d/injvm tests with vnode/trie/etc configurations, and instead these 
scenarios should be exercised by config permuation using a fuzzer. As 
experience (and several recent issues particularly) show - some important 
settings are never touched by any of the tests at all, and since tests are 
static, a chance of finding any issues with some combination of those is slim. 

Apart from what we already have (data and schema generators and failure 
injection), we now need configuration generators that will find interesting 
configurations and run randomly generated workflows against those, expecting 
any configuration of Cassandra to behave the same. 

I do find our test matrix a bit convoluted, and in my experience you spend way 
more time tweaking tests to work for all configurations after some code 
changes, and they find legimitate issues rather infrequently. We would probably 
be better off with a quick "sanity check" for major configurations per commit 
which, again, would exercise a common set of operations, combined with a 
comprehensive test suite which will try to cover as much ground as possible.

Hope this helps.
--Alex


On Thu, Nov 30, 2023, at 10:25 AM, Jacek Lewandowski wrote:
> Hi,
> 
> I'm getting a bit lost - what are the exact differences between those test 
> scenarios? What are the criteria for qualifying a test to be part of a 
> certain scenario?
> 
> I'm working a little bit with tests and build scripts and the number of 
> different configurations for which we have a separate target in the build 
> starts to be problematic, I cannot imagine how problematic it is for a new 
> contributor.
> 
> It is not urgent, but we should at least have a plan on how to simplify and 
> unify things.
> 
> I'm in favour of reducing the number of test targets to the minimum - for 
> different configurations I think we should provide a parameter pointing to 
> jvm options file and maybe to cassandra.yaml. I know that we currently do 
> some super hacky things with cassandra yaml for different configs - like 
> concatenting parts of it. I presume it is not necessary - we can have a 
> default test config yaml and a directory with overriding yamls; while 
> building we could have a tool which is able to load the default 
> configuration, apply the override and save the resulting yaml somewhere in 
> the build/test/configs for example. That would allows us to easily use those 
> yamls in IDE as well - currently it is impossible.
> 
> What do you think?
> 
> Thank you and my apologize for bothering about lower priority stuff while we 
> have a 5.0 release headache...
> 
> Jacek
> 

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Benedict]

I don’t know - I’m not sure what fuzz test means in this context. It’s a newer concept that I didn’t introduce.On 30 Nov 2023, at 20:06, Jacek Lewandowski  wrote:How those burn tests then compare to the fuzz tests? (the new ones)czw., 30 lis 2023, 20:22 użytkownik Benedict  napisał:By “could run indefinitely” I don’t mean by default they run forever. There will be parameters that change how much work is done for a given run, but just running repeatedly (each time with a different generated seeds) is the expected usage. Until you run out of compute or patience.I agree they are only of value pre-commit to check they haven’t been broken in some way by changes. On 30 Nov 2023, at 18:36, Josh McKenzie  wrote:that may be long-running and that could be run indefinitelyPerfect. That was the distinction I wasn't aware of. Also means having the burn target as part of regular CI runs is probably a mistake, yes? i.e. if someone adds a burn tests that runs indefinitely, are there any guardrails or built-in checks or timeouts to keep it from running right up to job timeout and then failing?On Thu, Nov 30, 2023, at 1:11 PM, Benedict wrote:A burn test is a randomised test targeting broad coverage of a single system, subsystem or utility, that may be long-running and that could be run indefinitely, each run providing incrementally more assurance of quality of the system.A long test is a unit test that sometimes takes a long time to run, no more no less. I’m not sure any of these offer all that much value anymore, and perhaps we could look to deprecate them.On 30 Nov 2023, at 17:20, Josh McKenzie  wrote:Strongly agree. I started working on a declarative refactor out of our CI configuration so circle, ASFCI, and other systems could inherit from it (for instance, see pre-commit pipeline declaration here); I had to set that down while I finished up implementing an internal CI system since the code in neither the ASF CI structure nor circle structure (.sh embedded in .yml /cry) was re-usable in their current form.Having a jvm.options and cassandra.yaml file per suite and referencing them from a declarative job definition would make things a lot easier to wrap our heads around and maintain I think.As for what qualifies as burn vs. long... /shrug couldn't tell you. Would have to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone else on-list knows.On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:Hi,I'm getting a bit lost - what are the exact differences between those test scenarios? What are the criteria for qualifying a test to be part of a certain scenario?I'm working a little bit with tests and build scripts and the number of different configurations for which we have a separate target in the build starts to be problematic, I cannot imagine how problematic it is for a new contributor.It is not urgent, but we should at least have a plan on how to simplify and unify things.I'm in favour of reducing the number of test targets to the minimum - for different configurations I think we should provide a parameter pointing to jvm options file and maybe to cassandra.yaml. I know that we currently do some super hacky things with cassandra yaml for different configs - like concatenting parts of it. I presume it is not necessary - we can have a default test config yaml and a directory with overriding yamls; while building we could have a tool which is able to load the default configuration, apply the override and save the resulting yaml somewhere in the build/test/configs for example. That would allows us to easily use those yamls in IDE as well - currently it is impossible.What do you think?Thank you and my apologize for bothering about lower priority stuff while we have a 5.0 release headache...Jacek

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Jacek Lewandowski]

How those burn tests then compare to the fuzz tests? (the new ones)

czw., 30 lis 2023, 20:22 użytkownik Benedict  napisał:

> By “could run indefinitely” I don’t mean by default they run forever.
> There will be parameters that change how much work is done for a given run,
> but just running repeatedly (each time with a different generated seeds) is
> the expected usage. Until you run out of compute or patience.
>
> I agree they are only of value pre-commit to check they haven’t been
> broken in some way by changes.
>
>
>
> On 30 Nov 2023, at 18:36, Josh McKenzie  wrote:
>
> 
>
> that may be long-running and that could be run indefinitely
>
> Perfect. That was the distinction I wasn't aware of. Also means having the
> burn target as part of regular CI runs is probably a mistake, yes? i.e. if
> someone adds a burn tests that runs indefinitely, are there any guardrails
> or built-in checks or timeouts to keep it from running right up to job
> timeout and then failing?
>
> On Thu, Nov 30, 2023, at 1:11 PM, Benedict wrote:
>
>
> A burn test is a randomised test targeting broad coverage of a single
> system, subsystem or utility, that may be long-running and that could be
> run indefinitely, each run providing incrementally more assurance of
> quality of the system.
>
> A long test is a unit test that sometimes takes a long time to run, no
> more no less. I’m not sure any of these offer all that much value anymore,
> and perhaps we could look to deprecate them.
>
> On 30 Nov 2023, at 17:20, Josh McKenzie  wrote:
>
> 
> Strongly agree. I started working on a declarative refactor out of our CI
> configuration so circle, ASFCI, and other systems could inherit from it
> (for instance, see pre-commit pipeline declaration here
> );
> I had to set that down while I finished up implementing an internal CI
> system since the code in neither the ASF CI structure nor circle structure
> (.sh embedded in .yml /cry) was re-usable in their current form.
>
> Having a jvm.options and cassandra.yaml file per suite and referencing
> them from a declarative job definition
> 
> would make things a lot easier to wrap our heads around and maintain I
> think.
>
> As for what qualifies as burn vs. long... /shrug couldn't tell you. Would
> have to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone
> else on-list knows.
>
> On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:
>
> Hi,
>
> I'm getting a bit lost - what are the exact differences between those
> test scenarios? What are the criteria for qualifying a test to be part of a
> certain scenario?
>
> I'm working a little bit with tests and build scripts and the number of
> different configurations for which we have a separate target in the build
> starts to be problematic, I cannot imagine how problematic it is for a new
> contributor.
>
> It is not urgent, but we should at least have a plan on how to
> simplify and unify things.
>
> I'm in favour of reducing the number of test targets to the minimum - for
> different configurations I think we should provide a parameter pointing to
> jvm options file and maybe to cassandra.yaml. I know that we currently do
> some super hacky things with cassandra yaml for different configs - like
> concatenting parts of it. I presume it is not necessary - we can have a
> default test config yaml and a directory with overriding yamls; while
> building we could have a tool which is able to load the default
> configuration, apply the override and save the resulting yaml somewhere in
> the build/test/configs for example. That would allows us to easily use
> those yamls in IDE as well - currently it is impossible.
>
> What do you think?
>
> Thank you and my apologize for bothering about lower priority stuff while
> we have a 5.0 release headache...
>
> Jacek
>
>
>
>

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Benedict]

By “could run indefinitely” I don’t mean by default they run forever. There will be parameters that change how much work is done for a given run, but just running repeatedly (each time with a different generated seeds) is the expected usage. Until you run out of compute or patience.I agree they are only of value pre-commit to check they haven’t been broken in some way by changes. On 30 Nov 2023, at 18:36, Josh McKenzie  wrote:that may be long-running and that could be run indefinitelyPerfect. That was the distinction I wasn't aware of. Also means having the burn target as part of regular CI runs is probably a mistake, yes? i.e. if someone adds a burn tests that runs indefinitely, are there any guardrails or built-in checks or timeouts to keep it from running right up to job timeout and then failing?On Thu, Nov 30, 2023, at 1:11 PM, Benedict wrote:A burn test is a randomised test targeting broad coverage of a single system, subsystem or utility, that may be long-running and that could be run indefinitely, each run providing incrementally more assurance of quality of the system.A long test is a unit test that sometimes takes a long time to run, no more no less. I’m not sure any of these offer all that much value anymore, and perhaps we could look to deprecate them.On 30 Nov 2023, at 17:20, Josh McKenzie  wrote:Strongly agree. I started working on a declarative refactor out of our CI configuration so circle, ASFCI, and other systems could inherit from it (for instance, see pre-commit pipeline declaration here); I had to set that down while I finished up implementing an internal CI system since the code in neither the ASF CI structure nor circle structure (.sh embedded in .yml /cry) was re-usable in their current form.Having a jvm.options and cassandra.yaml file per suite and referencing them from a declarative job definition would make things a lot easier to wrap our heads around and maintain I think.As for what qualifies as burn vs. long... /shrug couldn't tell you. Would have to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone else on-list knows.On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:Hi,I'm getting a bit lost - what are the exact differences between those test scenarios? What are the criteria for qualifying a test to be part of a certain scenario?I'm working a little bit with tests and build scripts and the number of different configurations for which we have a separate target in the build starts to be problematic, I cannot imagine how problematic it is for a new contributor.It is not urgent, but we should at least have a plan on how to simplify and unify things.I'm in favour of reducing the number of test targets to the minimum - for different configurations I think we should provide a parameter pointing to jvm options file and maybe to cassandra.yaml. I know that we currently do some super hacky things with cassandra yaml for different configs - like concatenting parts of it. I presume it is not necessary - we can have a default test config yaml and a directory with overriding yamls; while building we could have a tool which is able to load the default configuration, apply the override and save the resulting yaml somewhere in the build/test/configs for example. That would allows us to easily use those yamls in IDE as well - currently it is impossible.What do you think?Thank you and my apologize for bothering about lower priority stuff while we have a 5.0 release headache...Jacek

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Josh McKenzie]

> that may be long-running and that could be run indefinitely
Perfect. That was the distinction I wasn't aware of. Also means having the burn 
target as part of regular CI runs is probably a mistake, yes? i.e. if someone 
adds a burn tests that runs indefinitely, are there any guardrails or built-in 
checks or timeouts to keep it from running right up to job timeout and then 
failing?

On Thu, Nov 30, 2023, at 1:11 PM, Benedict wrote:
> 
> A burn test is a randomised test targeting broad coverage of a single system, 
> subsystem or utility, that may be long-running and that could be run 
> indefinitely, each run providing incrementally more assurance of quality of 
> the system.
> 
> A long test is a unit test that sometimes takes a long time to run, no more 
> no less. I’m not sure any of these offer all that much value anymore, and 
> perhaps we could look to deprecate them.
> 
>> On 30 Nov 2023, at 17:20, Josh McKenzie  wrote:
>> 
>> Strongly agree. I started working on a declarative refactor out of our CI 
>> configuration so circle, ASFCI, and other systems could inherit from it (for 
>> instance, see pre-commit pipeline declaration here 
>> );
>>  I had to set that down while I finished up implementing an internal CI 
>> system since the code in neither the ASF CI structure nor circle structure 
>> (.sh embedded in .yml /cry) was re-usable in their current form.
>> 
>> Having a jvm.options and cassandra.yaml file per suite and referencing them 
>> from a declarative job definition 
>> 
>>  would make things a lot easier to wrap our heads around and maintain I 
>> think.
>> 
>> As for what qualifies as burn vs. long... /shrug couldn't tell you. Would 
>> have to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone 
>> else on-list knows.
>> 
>> On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:
>>> Hi,
>>> 
>>> I'm getting a bit lost - what are the exact differences between those test 
>>> scenarios? What are the criteria for qualifying a test to be part of a 
>>> certain scenario?
>>> 
>>> I'm working a little bit with tests and build scripts and the number of 
>>> different configurations for which we have a separate target in the build 
>>> starts to be problematic, I cannot imagine how problematic it is for a new 
>>> contributor.
>>> 
>>> It is not urgent, but we should at least have a plan on how to simplify and 
>>> unify things.
>>> 
>>> I'm in favour of reducing the number of test targets to the minimum - for 
>>> different configurations I think we should provide a parameter pointing to 
>>> jvm options file and maybe to cassandra.yaml. I know that we currently do 
>>> some super hacky things with cassandra yaml for different configs - like 
>>> concatenting parts of it. I presume it is not necessary - we can have a 
>>> default test config yaml and a directory with overriding yamls; while 
>>> building we could have a tool which is able to load the default 
>>> configuration, apply the override and save the resulting yaml somewhere in 
>>> the build/test/configs for example. That would allows us to easily use 
>>> those yamls in IDE as well - currently it is impossible.
>>> 
>>> What do you think?
>>> 
>>> Thank you and my apologize for bothering about lower priority stuff while 
>>> we have a 5.0 release headache...
>>> 
>>> Jacek
>>> 
>> 

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Benedict]

A burn test is a randomised test targeting broad coverage of a single system, subsystem or utility, that may be long-running and that could be run indefinitely, each run providing incrementally more assurance of quality of the system.A long test is a unit test that sometimes takes a long time to run, no more no less. I’m not sure any of these offer all that much value anymore, and perhaps we could look to deprecate them.On 30 Nov 2023, at 17:20, Josh McKenzie  wrote:Strongly agree. I started working on a declarative refactor out of our CI configuration so circle, ASFCI, and other systems could inherit from it (for instance, see pre-commit pipeline declaration here); I had to set that down while I finished up implementing an internal CI system since the code in neither the ASF CI structure nor circle structure (.sh embedded in .yml /cry) was re-usable in their current form.Having a jvm.options and cassandra.yaml file per suite and referencing them from a declarative job definition would make things a lot easier to wrap our heads around and maintain I think.As for what qualifies as burn vs. long... /shrug couldn't tell you. Would have to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone else on-list knows.On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:Hi,I'm getting a bit lost - what are the exact differences between those test scenarios? What are the criteria for qualifying a test to be part of a certain scenario?I'm working a little bit with tests and build scripts and the number of different configurations for which we have a separate target in the build starts to be problematic, I cannot imagine how problematic it is for a new contributor.It is not urgent, but we should at least have a plan on how to simplify and unify things.I'm in favour of reducing the number of test targets to the minimum - for different configurations I think we should provide a parameter pointing to jvm options file and maybe to cassandra.yaml. I know that we currently do some super hacky things with cassandra yaml for different configs - like concatenting parts of it. I presume it is not necessary - we can have a default test config yaml and a directory with overriding yamls; while building we could have a tool which is able to load the default configuration, apply the override and save the resulting yaml somewhere in the build/test/configs for example. That would allows us to easily use those yamls in IDE as well - currently it is impossible.What do you think?Thank you and my apologize for bothering about lower priority stuff while we have a 5.0 release headache...Jacek

Re: Removal of deprecations added in Cassandra 3.x

[Josh McKenzie]

> Personally, I think the removal of the deprecated code which was marked like 
> that in 3.x is quite safe to do in 5.x but I have to ask broader audience to 
> have a consensus.
Safe for us, sure. Safe for our users, not so much. No amount of including it 
in release notes guarantees they'll see it, and to Mick's point:

> Anything that is public (user-facing) and is isolated code having little cost 
> to it should just be left.
Strong +1 to this sentiment.

On Thu, Nov 30, 2023, at 10:33 AM, Mick Semb Wever wrote:
>> Personally, I think the removal of the deprecated code which was marked like 
>> that in 3.x is quite safe to do in 5.x but I have to ask broader audience to 
>> have a consensus.
> 
> 
> Strawman:
> Evaluate the cost and risk to us by having to keep the code.
> Weigh that against the effort it takes for users to adjust their prod 
> systems, and assume they are many orders of magnitude more than us.
> 
> Anything that is public (user-facing) and is isolated code having little cost 
> to it should just be left.
>   
>>  I think that what is "private" might go away in 5.x easily.
> 
> 
> Yes.
> 
> 
> 

Re: Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Josh McKenzie]

Strongly agree. I started working on a declarative refactor out of our CI 
configuration so circle, ASFCI, and other systems could inherit from it (for 
instance, see pre-commit pipeline declaration here 
);
 I had to set that down while I finished up implementing an internal CI system 
since the code in neither the ASF CI structure nor circle structure (.sh 
embedded in .yml /cry) was re-usable in their current form.

Having a jvm.options and cassandra.yaml file per suite and referencing them 
from a declarative job definition 

 would make things a lot easier to wrap our heads around and maintain I think.

As for what qualifies as burn vs. long... /shrug couldn't tell you. Would have 
to go down the git blame + dev ML + JIRA rabbit hole. :) Maybe someone else 
on-list knows.

On Thu, Nov 30, 2023, at 4:25 AM, Jacek Lewandowski wrote:
> Hi,
> 
> I'm getting a bit lost - what are the exact differences between those test 
> scenarios? What are the criteria for qualifying a test to be part of a 
> certain scenario?
> 
> I'm working a little bit with tests and build scripts and the number of 
> different configurations for which we have a separate target in the build 
> starts to be problematic, I cannot imagine how problematic it is for a new 
> contributor.
> 
> It is not urgent, but we should at least have a plan on how to simplify and 
> unify things.
> 
> I'm in favour of reducing the number of test targets to the minimum - for 
> different configurations I think we should provide a parameter pointing to 
> jvm options file and maybe to cassandra.yaml. I know that we currently do 
> some super hacky things with cassandra yaml for different configs - like 
> concatenting parts of it. I presume it is not necessary - we can have a 
> default test config yaml and a directory with overriding yamls; while 
> building we could have a tool which is able to load the default 
> configuration, apply the override and save the resulting yaml somewhere in 
> the build/test/configs for example. That would allows us to easily use those 
> yamls in IDE as well - currently it is impossible.
> 
> What do you think?
> 
> Thank you and my apologize for bothering about lower priority stuff while we 
> have a 5.0 release headache...
> 
> Jacek
> 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Patrick McFadin]

Congratulations and welcome, Francisco!

On Thu, Nov 30, 2023 at 2:45 AM Maxim Muzafarov  wrote:

> My congratulations, Francisco! :-)
>
> On Wed, 29 Nov 2023 at 13:30, Andrés de la Peña 
> wrote:
> >
> > Congrats Francisco!
> >
> > On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer  wrote:
> >>
> >> Congratulations!!! Well deserved!
> >>
> >> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi 
> a écrit :
> >>>
> >>> 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 <
> sc...@paradoxica.net> 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: Removal of deprecations added in Cassandra 3.x

[Mick Semb Wever]

>
> Personally, I think the removal of the deprecated code which was marked
> like that in 3.x is quite safe to do in 5.x but I have to ask broader
> audience to have a consensus.



Strawman:
Evaluate the cost and risk to us by having to keep the code.
Weigh that against the effort it takes for users to adjust their prod
systems, and assume they are many orders of magnitude more than us.

Anything that is public (user-facing) and is isolated code having little
cost to it should just be left.



>  I think that what is "private" might go away in 5.x easily.
>


Yes.

Re: [VOTE] Release Harry 0.0.2

[Alex Petrov]

With 7 +1s (5 of which PMC), the vote passes.

Thanks everyone!

On Wed, Nov 29, 2023, at 6:40 PM, Francisco Guerrero wrote:
> +1
> 
> On 2023/11/29 11:14:29 Alex Petrov wrote:
> > Even though we would like to bring harry in-tree, this is not an immediate 
> > priority. Meanwhile, we need to unblock RPM builds for trunk, which means 
> > no custom jars. We will have at least one more Harry release with 
> > outstanding features to avoid any blocking. 
> > 
> > Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> > purposes.
> > 
> > Repository:
> > https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> > 
> > Candidate SHA:
> > https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> > tagged with 0.0.2
> > 
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1320
> > 
> > Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> > 
> > Prominent changes:
> > 
> > [CASSANDRA-18768] Improvements / changes required for Transactional 
> > Metadata testing:
> >   * Add an ability to run sequential r/w for more deterministic 
> > results
> >   * Implement Network Topology Strategy
> >   * Add all pds iterator to ops selector
> >   * Make sure to log when detecting that a run starts against a 
> > dirty table
> >   * Fix a concurrency issue with reorder buffer
> >   * Add some safety wheels / debugging instruments
> >   * Add a pd selector symmetry test
> >   * Make it simpler to write and log
> >   * Rename sequential rw to write before read
> >   * Avoid starving writers by readers and vice versa
> >   * Add a minimal guide for debugging falsifications
> >   * Fix select peers query for local state checker
> >   * Add examples for programmatic configuration
> > 
> > [CASSANDRA-18318] Implement parsing schema provider
> > [CASSANDRA-18315] Trigger exception if we run out of partitions
> > [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> > [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> > [CASSANDRA-17603] Make it possible to run multiple Harry runners 
> > concurrently against the same keyspace
> > [CASSANDRA-17603] Implement concurrent quiescent checker
> > [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> > dependency
> > [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a 
> > common shared library
> > 
> > The vote will be open for 24 hours. 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.
> 

Re: Removal of deprecations added in Cassandra 3.x

[Miklosovic, Stefan via dev]

Hi,

I want to refresh this thread. I know people are busy with 5.0 etc. but I would 
really like to have this resolved.

This might be removed in trunk (1). JMX methods / beans to remove are (2)

Mick had a point in (1) that even it is possible to remove it all, do we really 
want to? We should not break things unnecessarily so people do not have hard 
time to keep up with what we ship, there might be some legacy integrations 
which might depend on this, even on stuff as old as 3.x. Some custom tooling 
might call these methods etc. Even it is deprecated, that code is pretty much 
"maintenance-less". It does not need any special care so we might not look at 
it as its removal is something critical.

Personally, I think the removal of the deprecated code which was marked like 
that in 3.x is quite safe to do in 5.x but I have to ask broader audience to 
have a consensus.

We might be extra careful and drop it in 6.0 instead of 5.x so I would have to 
wait for 6.0 branch to be created. Supporting deprecated code for 2 majors 
sounds pretty safe to me.

This is all written for cases when the code is public-facing - JMX methods etc. 
I think that what is "private" might go away in 5.x easily.

Anyway, It is a good question was is considered to be a public API, I think 
that Josh was talking about this in some other thread already. I would like to 
start to map the codebase and annotate interfaces / extension points etc with 
something like "@PublicApi" or even "@Stable" / "@Unstable" and similar so we 
can reason about what is public or not more explicitly but this is not the 
topic I want to go into here.

(1) https://issues.apache.org/jira/browse/CASSANDRA-18975
(2) 
https://github.com/apache/cassandra/pull/2853/files#diff-4e5b9f6d0d76ab9ace1bd805efe5788bb5d23c84c25ccf75b9896f20b46a1879

Thanks and regards


From: Miklosovic, Stefan via dev 
Sent: Monday, October 30, 2023 23:07
To: dev@cassandra.apache.org
Cc: Miklosovic, Stefan
Subject: Re: Removal of deprecations added in Cassandra 3.x

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.




Sure we can do that just for trunk. No problem with that. Hence, I am parking 
this effort for a while.


From: Mick Semb Wever 
Sent: Monday, October 30, 2023 22:56
To: dev@cassandra.apache.org
Subject: Re: Removal of deprecations added in Cassandra 3.x

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.




> similarly as for Cassandra 1.x and 2.x deprecations removal done in 
> CASSANDRA-18959, you are welcome to comment on the removal of all stuff 
> deprecated in 3.x (1).
>
> If nobody objects after couple days I would like to proceed to the actual 
> removal. Please tell me if you want something to keep around.
>


I have concerns, but I won't block.

I would like to propose we focus on getting to a 5.0-beta1 release.
To do that we should be stopping all work on cassandra-5.0 that isn't
about stabilisation.

Can this land in trunk instead ?
How much work is in front of us to get to 5.0-beta1 ?  (Please add
fixVersion 5.0-beta for stabilisation work.)

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Maxim Muzafarov]

I'm gonna take a moment to outline the question. Here we have a point
in time where a time-driven release process clashes with the
alpha/beta release naming convention: we want to have a beta ready
_before_ the Summit.

Here's the Cassandra release lifecycle document [1] that I found
(still under discussion I think) and according to the 'beta'
definition we should have a green CI and no regressions for a beta
release.  This means that there may be known bugs in the new features
we are trying to ship. Unless I'm not missing something, 5.0 currently
meets the 'beta' criteria and the definition itself sounds clear to
me.

So, the question is - should we find a better place for the [1] page
and move it somewhere under the 'officially accepted'? :-)

[1] https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

On Thu, 30 Nov 2023 at 07:39, Jacek Lewandowski
 wrote:
>>
>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>> will signal to the community that we’re prioritizing stability and it could 
>> be a good opportunity to get people to test the beta or RC before we stamp 
>> it as production ready.
>
>
> I agree with Paulo's comment
>
> czw., 30 lis 2023 o 04:44 Paulo Motta  napisał(a):
>>
>> > if any contributor has an opinion which is not technically refuted it will 
>> > usually be backed by a PMC via a binding -1
>>
>> clarifying a bit my personal view: if any contributor has an opinion against 
>> a proposal (in this case this release proposal) that is not refuted it will 
>> usually be backed by a PMC via binding -1
>>
>> Opinions supporting the proposal are also valuable, provided there are no 
>> valid claims against a proposal.
>>
>> On Wed, 29 Nov 2023 at 22:27 Paulo Motta  wrote:
>>>
>>> To me, the goal of a beta is to find unknown bugs. If no new bugs are found 
>>> during a beta release, then it can be automatically promoted to RC via 
>>> re-tagging. Likewise, if no new bugs are found during a RC after X time, 
>>> then it can be promoted to final.
>>>
>>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it 
>>> will signal to the community that we’re prioritizing stability and it could 
>>> be a good opportunity to get people to test the beta or RC before we stamp 
>>> it as production ready.
>>>
>>> WDYT?
>>>
>>> >  Aaron (and anybody who takes the time to follow this list, really), your 
>>> > opinion matters, that's why we discuss it here.
>>>
>>> +1, PMC are just officers who endorse community decisions, so if any 
>>> contributor has an opinion which is not technically refuted it will usually 
>>> be backed by a PMC via a binding -1 (as seen on this thread)
>>>
>>> On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:



 On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko  
 wrote:
>
> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now, 
> but I’m not sure there is significant value to be had from it. Merge the 
> fixes for outstanding issues listed above, then cut beta1.

 

 Agree with Aleksey. -1 on a beta we know has issues with a top-line new 
 feature.

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Maxim Muzafarov]

My congratulations, Francisco! :-)

On Wed, 29 Nov 2023 at 13:30, Andrés de la Peña  wrote:
>
> Congrats Francisco!
>
> On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer  wrote:
>>
>> Congratulations!!! Well deserved!
>>
>> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi  a 
>> écrit :
>>>
>>> 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
>

Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?

[Jacek Lewandowski]

Hi,

I'm getting a bit lost - what are the exact differences between those
test scenarios? What are the criteria for qualifying a test to be part of a
certain scenario?

I'm working a little bit with tests and build scripts and the number of
different configurations for which we have a separate target in the build
starts to be problematic, I cannot imagine how problematic it is for a new
contributor.

It is not urgent, but we should at least have a plan on how to simplify and
unify things.

I'm in favour of reducing the number of test targets to the minimum - for
different configurations I think we should provide a parameter pointing to
jvm options file and maybe to cassandra.yaml. I know that we currently do
some super hacky things with cassandra yaml for different configs - like
concatenting parts of it. I presume it is not necessary - we can have a
default test config yaml and a directory with overriding yamls; while
building we could have a tool which is able to load the default
configuration, apply the override and save the resulting yaml somewhere in
the build/test/configs for example. That would allows us to easily use
those yamls in IDE as well - currently it is impossible.

What do you think?

Thank you and my apologize for bothering about lower priority stuff while
we have a 5.0 release headache...

Jacek