[RELEASE] Apache Cassandra 3.0.26 released

[Mick Semb Wever]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: CHANGES.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.0.26
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.0.26
[3]: https://issues.apache.org/jira/browse/CASSANDRA

[RELEASE] Apache Cassandra 3.11.12 released

[Mick Semb Wever]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: CHANGES.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-3.11.12
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-3.11.12

[RELEASE] Apache Cassandra 4.0.2 released

[Mick Semb Wever]

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

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

 http://cassandra.apache.org/

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

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

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

Enjoy!

[1]: CHANGES.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0.2
[2]: NEWS.txt 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.2
[3]: https://issues.apache.org/jira/browse/CASSANDRA

CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Marcus Eriksson]

Severity: high

Description:

When running Apache Cassandra with the following configuration:

enable_user_defined_functions: true
enable_scripted_user_defined_functions: true
enable_user_defined_functions_threads: false 

it is possible for an attacker to execute arbitrary code on the host. The 
attacker would need to have enough permissions to create user defined functions 
in the cluster to be able to exploit this. Note that this configuration is 
documented as unsafe, and will continue to be considered unsafe after this CVE.

This issue is being tracked as CASSANDRA-17352

Mitigation:

Set `enable_user_defined_functions_threads: true` (this is default)
or
3.0 users should upgrade to 3.0.26
3.11 users should upgrade to 3.11.12
4.0 users should upgrade to 4.0.2

Credit:

This issue was discovered by Omer Kaspi of the JFrog Security vulnerability 
research team.

Re: [DISCUSS] Non Coding Committers

[Sharan Foga]

Hi All

Thanks very much to everyone who took the time to provide feedback and share 
their views on this topic. It seems to me like there is a general consensus 
around it and it's great to hear that the PMC is aware and actively working on 
it.

A community is an evolving thing and so adapting to change is part of the 
journey. I am really happy to see this open dialogue happening and even though 
some current problems have been highlighted - the focus is on resolving them! 

Happy to be involved and part of this community :-)

Thanks
Sharan

On 2022/02/09 09:12:56 Benjamin Lerer wrote:
> Thanks a lot Sharan, Patrick and Lorina.
> It is a perfectly valid point that the PMC members have recognized for some
> time already and are actively working on.
> 😊
> 
> Le mar. 8 févr. 2022 à 23:07, Lorina Poland  a écrit :
> 
> > +1 to this conversation, from a Docs wonk. :-)
> >
> > On Tue, Feb 8, 2022 at 1:40 PM Patrick McFadin  wrote:
> >
> >> Sharan has done a good job shining a spotlight on something that has
> >> created a weird bottleneck in the project. Docs and the Cassandra website
> >> are all in-tree, but it takes somebody who probably isn't even working on
> >> those things to commit any changes. Dinesh nailed it. It's silly. I'm sure
> >> the PMC can come up with a reasonable solution that can be done quickly.
> >> There are a lot of us that love this project that contribute in ways that
> >> don't get compiled into a jar file. This is something that needs to be
> >> solved for the sake of project velocity.
> >>
> >> Patrick
> >>
> >> On Sun, Feb 6, 2022 at 10:28 PM Mick Semb Wever  wrote:
> >>
> >>>
> >>> Thank you Sharan for sharing.
> >>>
> >>>
>  So here in Apache Cassandra I see there is a whole lot of activity
>  happening around the website, marketing, project promotion, blogs, social
>  media - these activities are all contributions to the project. If there 
>  are
>  contributions happening in the project that need a committer to action,
>  then it could make sense to consider having committers that are focussed
>  around the 'non coding' parts.
> 
> 
> 
> >>>
> >>> This is so true for us. We are spending a lot of extra time getting
> >>> these non-code contributions across the finish line. The context switching
> >>> and wait time involved in just one more handover, and often across time
> >>> zones, is hurting. And regardless, totally agree we should be formally
> >>> recognising the ongoing work that goes into these non-coding 
> >>> contributions.
> >>>
> >>>
> 

Re: [GSOC] Call for Mentors

[Henrik Ingo]

Hi Paulo

Just checking, am I using Jira right:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20labels%20%3D%20gsoc%20and%20statusCategory%20!%3D%20Done%20

It looks like we ended up with no gsoc projects submitted? Or am I querying
wrong?

henrik

On Thu, Feb 3, 2022 at 12:26 AM Paulo Motta 
wrote:

> Hi Henrik,
>
> I am happy to give feedback to project ideas - but they ultimately need to
> be registered by prospective mentors on JIRA with the "gsoc" tag to be
> considered a "subscribed idea".
>
> The project idea JIRA should have a "high level" overview of what the
> project is:
> - What is the problem statement?
> - Rough plan on how to approach the problem.
> - What are the main milestones/deliverables? (ie.
> code/benchmark/framework/blog post etc)
> - What prior knowledge is required to complete the task?
> - What warm-up tasks can the candidate do to ramp up for the project?
>
> The mentor will work with potential participants to refine the high level
> description into smaller subtasks at a later stage (during candidate
> application period).
>
> Cheers,
>
> Paulo
>
> Em qua., 2 de fev. de 2022 às 19:02, Henrik Ingo 
> escreveu:
>
>> Hi Paulo
>>
>> I think Shaunak and Aleks V already pinged you on Slack about their
>> ideas. When you say we don't have any subscribed ideas, what is missing?
>>
>> henrik
>>
>> On Wed, Feb 2, 2022 at 4:03 PM Paulo Motta 
>> wrote:
>>
>>> Hi everyone,
>>>
>>> We need to tell ASF how many slots we will need for GSoC (if any) by
>>> February 20. So far we don't have any subscribed project ideas.
>>>
>>> If you are interested in being a GSoC mentor, just ping me on slack and
>>> I will be happy to give you feedback on the project idea proposal. Please
>>> do so by no later than February 10 to allow sufficient time for follow-ups.
>>>
>>> Cheers,
>>>
>>> Paulo
>>>
>>> Em qua., 19 de jan. de 2022 às 10:54, Paulo Motta 
>>> escreveu:
>>>
 Hi everyone,

 Following up from the initial GSoC Kick-off thread [1] I would like to
 invite contributors to submit GSoC project ideas. In order to submit a
 project idea, just tag a JIRA ticket with the "gsoc" label and add yourself
 to the "Mentor" field to indicate you're willing to mentor this project.

 Existing JIRA tickets can be repurposed as GSoC projects or new tickets
 can be created with new features or improvements specifically for GSoC. The
 best GSoC project ideas are those which are self-contained: have a well
 defined scope, discrete milestones and definition of done. Generally the
 areas which are easier for GSoC contributors to get started are:
 - UX improvements
 - Tools
 - Benchmarking
 - Refactoring and Modularization

 Non-committers are more than welcome to submit project ideas and mentor
 projects, as long as a committer is willing to co-mentor the project. As a
 matter of fact I was a GSoC mentor before becoming a committer, so I can
 say this is a great way to pave your way to committership. ;)

 Mentor tasks involve having 1 or 2 weekly meetings with the GSoC
 participant to track the project status and give guidance to the
 participant towards the completion of the project, as well as reviewing
 code submissions.

 This year, GSoC is open to any participant over 18 years of age, no
 longer focusing solely on university students. GSoC projects can be of ~175
 hour (medium) and 350 hour (large), and can range from 12 to 22 weeks
 starting in July.

 We have little less than 2 months until the start of the GSoC
 application period on March 7, but ideally we want to have an "Ideas List"
 ready before that so prospective participants can start engaging with the
 project and working with mentors to refine the project before submitting an
 application.

 This year I will not be able to participate as a primary mentor but I
 would be happy to co-mentor other projects as well as help with questions
 and guidance.

 Kind regards,

 Paulo

 [1] https://lists.apache.org/thread/58v2bvfzwtfgqdx90qmm4tmyoqzsgtn4

>>>
>>
>> --
>>
>> Henrik Ingo
>>
>> +358 40 569 7354 <358405697354>
>>
>> [image: Visit us online.]   [image: Visit us
>> on Twitter.]   [image: Visit us on
>> YouTube.]
>> 
>>   [image: Visit my LinkedIn profile.]
>> 
>>
>

-- 

Henrik Ingo

+358 40 569 7354 <358405697354>

[image: Visit us onlin

Re: [DISCUSS] CEP-7 Storage Attached Index

[Caleb Rackliffe]

Just finished reading the latest version of the CEP. Here are my thoughts:

- We've already talked about OR queries, so I won't rehash that, but
tokenization support seems like it might be another one of those places
where we can cut scope if we want to get V1 out the door. It shouldn't be
that hard to detangle from the rest of the code.
- We mention the JMX metric ecosystem in the CEP, but not the related
virtual tables. This isn't a big issue, and doesn't mean we need to change
the CEP, but it might be helpful for those not familiar with the existing
prototype to know they exist :)
- It's probably below the line for CEP discussion, but the text and numeric
index formats will probably change over time. We don't need a whole "codec
framework" for V1, but we're still embedding some versioning information in
the column index on-disk structures, right?

To offset my obvious partiality around this CEP, I've already made an
effort to raise some of the issues that may come up to challenge us from a
macro perspective. It seems like the prevailing opinion here is that they
are either surmountable or simply basic conceptual difficulties w/
distributed secondary indexing.

tl;dr I'm +1 on bringing this to a vote and starting to put together all
the pieces for CASSANDRA-16052
 :)

On Thu, Feb 10, 2022 at 11:26 AM Mike Adamson  wrote:

> > I'd be interested to hear from Mike/Jason on the OR support topic, of
> course.
>
> The support for OR within SAI is fairly minimal and will not work without
> the non-SAI changes needed. Since the non-SAI OR changes are extensive it
> would be better to bring those in under their own CEP.
>
> I’d leave the decision of whether to put the rest of SAI behind an
> experimental flag to others. My preference would be to not do so because
> the non-OR implementation has been tested and used on production for over a
> year now.
>
> MikeA
>
> On 9 Feb 2022, at 13:06, bened...@apache.org wrote:
>
> > Is there some mechanism such as experimental flags, which would allow
> the SAI-only OR support to be merged into trunk
>
> FWIW, I’m OK with this merging to trunk, either hidden behind a CI-only
> flag or exposed to the user via some experimental flag (and a suitable
> NEWS.txt). We’ve discussed the need to periodically merge feature branches
> with trunk before they are complete. If the work is logically complete for
> SAI, and we’re only pending work to make OR consistent between SAI and
> non-SAI queries, I think that more than meets this criterion.
>
>
>
> *From: *Henrik Ingo 
> *Date: *Monday, 7 February 2022 at 12:03
> *To: *dev@cassandra.apache.org 
> *Subject: *Re: [DISCUSS] CEP-7 Storage Attached Index
> Thanks Benjamin for reviewing and raising this.
>
> While I don't speak for the CEP authors, just some thoughts from me:
>
> On Mon, Feb 7, 2022 at 11:18 AM Benjamin Lerer  wrote:
>
> I would like to raise 2 points regarding the current CEP proposal:
>
> 1. There are mention of some target versions and of the removal of SASI
>
> At this point, we have not agreed on any version numbers and I do not feel
> that removing SASI should be part of the proposal for now.
> It seems to me that we should see first the adoption surrounding SAI
> before talking about deprecating other solutions.
>
>
>
> This seems rather uncontroversial. I think the CEP template and previous
> CEPs invite  the discussion on whether the new feature will or may replace
> an existing feature. But at the same time that's of course out of scope for
> the work at hand. I have no opinion one way or the other myself.
>
>
>
> 2. OR queries
>
> It is unclear to me if the proposal is about adding OR support only for
> SAI index or for other types of queries too.
> In the past, we had the nasty habit for CQL to provide only partialially
> implemented features which resulted in a bad user experience.
> Some examples are:
> * LIKE restrictions which were introduced for the need of SASI and were
> not never supported for other type of queries
> * IS NOT NULL restrictions for MATERIALIZED VIEWS that are not supported
> elsewhere
> * != operator only supported for conditional inserts or updates
> And there are unfortunately many more.
>
> We are currenlty slowly trying to fix those issue and make CQL a more
> mature language. By consequence, I would like that we change our way of
> doing things. If we introduce support for OR it should also cover all the
> other type of queries and be fully tested.
> I also believe that it is a feature that due to its complexity fully
> deserves its own CEP.
>
>
>
> The current code that would be submitted for review after the CEP is
> adopted, contains OR support beyond just SAI indexes. An initial
> implementation first targeted only such queries where all columns in a
> WHERE clause using OR needed to be backed by an SAI index. This was since
> extended to also support ALLOW FILTERING mode as well as OR with clustering
> key columns. The cur

Re: [GSOC] Call for Mentors

[Paulo Motta]

Unfortunately we didn't, so far.

Em sex., 11 de fev. de 2022 às 15:32, Henrik Ingo 
escreveu:

> Hi Paulo
>
> Just checking, am I using Jira right:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20CASSANDRA%20AND%20labels%20%3D%20gsoc%20and%20statusCategory%20!%3D%20Done%20
>
> It looks like we ended up with no gsoc projects submitted? Or am I
> querying wrong?
>
> henrik
>
> On Thu, Feb 3, 2022 at 12:26 AM Paulo Motta 
> wrote:
>
>> Hi Henrik,
>>
>> I am happy to give feedback to project ideas - but they ultimately need
>> to be registered by prospective mentors on JIRA with the "gsoc" tag to be
>> considered a "subscribed idea".
>>
>> The project idea JIRA should have a "high level" overview of what the
>> project is:
>> - What is the problem statement?
>> - Rough plan on how to approach the problem.
>> - What are the main milestones/deliverables? (ie.
>> code/benchmark/framework/blog post etc)
>> - What prior knowledge is required to complete the task?
>> - What warm-up tasks can the candidate do to ramp up for the project?
>>
>> The mentor will work with potential participants to refine the high level
>> description into smaller subtasks at a later stage (during candidate
>> application period).
>>
>> Cheers,
>>
>> Paulo
>>
>> Em qua., 2 de fev. de 2022 às 19:02, Henrik Ingo <
>> henrik.i...@datastax.com> escreveu:
>>
>>> Hi Paulo
>>>
>>> I think Shaunak and Aleks V already pinged you on Slack about their
>>> ideas. When you say we don't have any subscribed ideas, what is missing?
>>>
>>> henrik
>>>
>>> On Wed, Feb 2, 2022 at 4:03 PM Paulo Motta 
>>> wrote:
>>>
 Hi everyone,

 We need to tell ASF how many slots we will need for GSoC (if any) by
 February 20. So far we don't have any subscribed project ideas.

 If you are interested in being a GSoC mentor, just ping me on slack and
 I will be happy to give you feedback on the project idea proposal. Please
 do so by no later than February 10 to allow sufficient time for follow-ups.

 Cheers,

 Paulo

 Em qua., 19 de jan. de 2022 às 10:54, Paulo Motta 
 escreveu:

> Hi everyone,
>
> Following up from the initial GSoC Kick-off thread [1] I would like to
> invite contributors to submit GSoC project ideas. In order to submit a
> project idea, just tag a JIRA ticket with the "gsoc" label and add 
> yourself
> to the "Mentor" field to indicate you're willing to mentor this project.
>
> Existing JIRA tickets can be repurposed as GSoC projects or new
> tickets can be created with new features or improvements specifically for
> GSoC. The best GSoC project ideas are those which are self-contained: have
> a well defined scope, discrete milestones and definition of done. 
> Generally
> the areas which are easier for GSoC contributors to get started are:
> - UX improvements
> - Tools
> - Benchmarking
> - Refactoring and Modularization
>
> Non-committers are more than welcome to submit project ideas and
> mentor projects, as long as a committer is willing to co-mentor the
> project. As a matter of fact I was a GSoC mentor before becoming a
> committer, so I can say this is a great way to pave your way to
> committership. ;)
>
> Mentor tasks involve having 1 or 2 weekly meetings with the GSoC
> participant to track the project status and give guidance to the
> participant towards the completion of the project, as well as reviewing
> code submissions.
>
> This year, GSoC is open to any participant over 18 years of age, no
> longer focusing solely on university students. GSoC projects can be of 
> ~175
> hour (medium) and 350 hour (large), and can range from 12 to 22 weeks
> starting in July.
>
> We have little less than 2 months until the start of the GSoC
> application period on March 7, but ideally we want to have an "Ideas List"
> ready before that so prospective participants can start engaging with the
> project and working with mentors to refine the project before submitting 
> an
> application.
>
> This year I will not be able to participate as a primary mentor but I
> would be happy to co-mentor other projects as well as help with questions
> and guidance.
>
> Kind regards,
>
> Paulo
>
> [1] https://lists.apache.org/thread/58v2bvfzwtfgqdx90qmm4tmyoqzsgtn4
>

>>>
>>> --
>>>
>>> Henrik Ingo
>>>
>>> +358 40 569 7354 <358405697354>
>>>
>>> [image: Visit us online.]   [image: Visit us
>>> on Twitter.]   [image: Visit us on
>>> YouTube.]
>>> 
>>>   [

Re: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Dorian ROSSE]

Hello,


Does this issue exist on the packaged Apache Cassandra 40X ?

I ask because I don't find any version line of command and it miss the manual 
line of command for Cassandra,

Thanks you in advance for your answer,

Have a nice evening from the France it is twenty to twelve and the sky is 
fallen,

Regards.


Dorian Rosse.

From: Marcus Eriksson 
Sent: Friday, February 11, 2022 11:01:38 AM
To: annou...@apache.org ; dev@cassandra.apache.org 

Subject: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted 
UDFs

Severity: high

Description:

When running Apache Cassandra with the following configuration:

enable_user_defined_functions: true
enable_scripted_user_defined_functions: true
enable_user_defined_functions_threads: false

it is possible for an attacker to execute arbitrary code on the host. The 
attacker would need to have enough permissions to create user defined functions 
in the cluster to be able to exploit this. Note that this configuration is 
documented as unsafe, and will continue to be considered unsafe after this CVE.

This issue is being tracked as CASSANDRA-17352

Mitigation:

Set `enable_user_defined_functions_threads: true` (this is default)
or
3.0 users should upgrade to 3.0.26
3.11 users should upgrade to 3.11.12
4.0 users should upgrade to 4.0.2

Credit:

This issue was discovered by Omer Kaspi of the JFrog Security vulnerability 
research team.

Re: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Erick Ramirez]

>
> Does this issue exist on the packaged Apache Cassandra 40X ?
>

Yes, it does. Cheers!

RE : CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Dorian ROSSE]

No it isn’t good to have issue…

Are you a black hacker ?

Regards.


Dorian ROSSE.

Envoyé à partir de Courrier 
pour Windows

De : Erick Ramirez
Envoyé le :vendredi 11 février 2022 23:02
À : dev@cassandra.apache.org
Objet :Re: CVE-2021-44521: Apache Cassandra: Remote code execution for scripted 
UDFs

Does this issue exist on the packaged Apache Cassandra 40X ?

Yes, it does. Cheers!

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Jeff Jirsa]

Accidentally dropped dev@, so adding back in the dev list, with the hopes
that someone on the dev list helps address this.

On Fri, Feb 11, 2022 at 2:22 PM Jeff Jirsa  wrote:

> That looks like https://issues.apache.org/jira/browse/CASSANDRA-17132 +
> https://github.com/apache/cassandra/commit/b6f61e850c8cfb1f0763e0f15721cde8893814b5
>
> I suspect this needs to be reverted, at least in 4.0.x, and it definitely
> deserved a NEWS.txt entry (and ideally some period of deprecation/warning).
>
>
>
> On Fri, Feb 11, 2022 at 2:09 PM James Brown  wrote:
>
>> It looks like the otc_coalescing_strategy config key is no longer
>> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
>> anywhere in CHANGES.txt or NEWS.txt.
>>
>> Attempting to upgrade a test cluster from 4.0.1 to 4.0.2 failed with 
>> *"Invalid
>> yaml. Please remove properties [otc_coalescing_strategy] from your
>> cassandra.yaml*"
>>
>> Is this change intentional?
>>
>> On Fri, Feb 11, 2022 at 1:40 AM Mick Semb Wever  wrote:
>>
>>> The Cassandra team is pleased to announce the release of Apache
>>> Cassandra version 4.0.2.
>>>
>>> Apache Cassandra is a fully distributed database. It is the right
>>> choice when you need scalability and high availability without
>>> compromising performance.
>>>
>>>  http://cassandra.apache.org/
>>>
>>> Downloads of source and binary distributions are listed in our download
>>> section:
>>>
>>>  http://cassandra.apache.org/download/
>>>
>>> This version is a bug fix release[1] on the 4.0 series. As always,
>>> please pay attention to the release notes[2] and Let us know[3] if you
>>> were to encounter any problem.
>>>
>>> Enjoy!
>>>
>>> [1]: CHANGES.txt
>>>
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/cassandra-4.0.2
>>> [2]: NEWS.txt
>>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.2
>>> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>>>
>>
>>
>> --
>> James Brown
>> Engineer
>>
>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Erick Ramirez]

(moved dev@ to BCC)


> It looks like the otc_coalescing_strategy config key is no longer
> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
> anywhere in CHANGES.txt or NEWS.txt.
>

James, you're right -- it was removed by CASSANDRA-17132
 in 4.0.2 and 4.1.

I agree that the CHANGES.txt entry should be clearer and we'll improve it
plus add detailed info in NEWS.txt. I'll get this done soon in
CASSANDRA-17135 .
Thanks for the feedback. Cheers!

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Ekaterina Dimitrova]

This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to
fix a bug that gives impression those work. Confirmed with Benedict on the
ticket.

I agree I absolutely had to document it better, a ticket for documentation
was opened but it slipped from my mind with this emergency release this
week. It is unfortunate it is still in our backlog after the ADOC migration.

Note taken. I truly apologize and I am going to prioritize CASSANDRA-17135.
Let me know if there is anything else I can/should do at this point.

On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
wrote:

> (moved dev@ to BCC)
>
>
>> It looks like the otc_coalescing_strategy config key is no longer
>> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
>> anywhere in CHANGES.txt or NEWS.txt.
>>
>
> James, you're right -- it was removed by CASSANDRA-17132
>  in 4.0.2 and 4.1.
>
> I agree that the CHANGES.txt entry should be clearer and we'll improve it
> plus add detailed info in NEWS.txt. I'll get this done soon in
> CASSANDRA-17135 .
> Thanks for the feedback. Cheers!
>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Brandon Williams]

I don't think that's enough.  We noop'd this in 3.11:
https://github.com/apache/cassandra/blob/cassandra-3.11/NEWS.txt#L310
but never mentioned it again or did a proper deprecation notice, so
dropping them in a minor is especially not nice.

On Fri, Feb 11, 2022 at 4:26 PM Erick Ramirez
 wrote:
>
> (moved dev@ to BCC)
>
>>
>> It looks like the otc_coalescing_strategy config key is no longer supported 
>> in cassandra.yaml in 4.0.2, despite this not being mentioned anywhere in 
>> CHANGES.txt or NEWS.txt.
>
>
> James, you're right -- it was removed by CASSANDRA-17132 in 4.0.2 and 4.1.
>
> I agree that the CHANGES.txt entry should be clearer and we'll improve it 
> plus add detailed info in NEWS.txt. I'll get this done soon in 
> CASSANDRA-17135. Thanks for the feedback. Cheers!

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Jeff Jirsa]

We don't HAVE TO remove the Config.java entry - we can mark it as
deprecated and ignored and remove it in a future version (and you could
update Config.java to log a message about having a deprecated config
option). It's a much better operator experience: log for a major version,
then remove in the next.

On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova 
wrote:

> This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to
> fix a bug that gives impression those work. Confirmed with Benedict on the
> ticket.
>
> I agree I absolutely had to document it better, a ticket for documentation
> was opened but it slipped from my mind with this emergency release this
> week. It is unfortunate it is still in our backlog after the ADOC migration.
>
> Note taken. I truly apologize and I am going to prioritize
> CASSANDRA-17135. Let me know if there is anything else I can/should do at
> this point.
>
> On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
> wrote:
>
>> (moved dev@ to BCC)
>>
>>
>>> It looks like the otc_coalescing_strategy config key is no longer
>>> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
>>> anywhere in CHANGES.txt or NEWS.txt.
>>>
>>
>> James, you're right -- it was removed by CASSANDRA-17132
>>  in 4.0.2 and 4.1.
>>
>> I agree that the CHANGES.txt entry should be clearer and we'll improve it
>> plus add detailed info in NEWS.txt. I'll get this done soon in
>> CASSANDRA-17135 .
>> Thanks for the feedback. Cheers!
>>
>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Ekaterina Dimitrova]

Note taken, I had to document only in 4.0.x that those are placeholder. I
just opened ticket to fix that - CASSANDRA-17377. I am going to submit a
patch soon

On Fri, 11 Feb 2022 at 17:44, Jeff Jirsa  wrote:

> We don't HAVE TO remove the Config.java entry - we can mark it as
> deprecated and ignored and remove it in a future version (and you could
> update Config.java to log a message about having a deprecated config
> option). It's a much better operator experience: log for a major version,
> then remove in the next.
>
> On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova 
> wrote:
>
>> This had to be removed in 4.0 but it wasn’t. The patch mentioned did it
>> to fix a bug that gives impression those work. Confirmed with Benedict on
>> the ticket.
>>
>> I agree I absolutely had to document it better, a ticket for
>> documentation was opened but it slipped from my mind with this emergency
>> release this week. It is unfortunate it is still in our backlog after the
>> ADOC migration.
>>
>> Note taken. I truly apologize and I am going to prioritize
>> CASSANDRA-17135. Let me know if there is anything else I can/should do at
>> this point.
>>
>> On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
>> wrote:
>>
>>> (moved dev@ to BCC)
>>>
>>>
 It looks like the otc_coalescing_strategy config key is no longer
 supported in cassandra.yaml in 4.0.2, despite this not being mentioned
 anywhere in CHANGES.txt or NEWS.txt.

>>>
>>> James, you're right -- it was removed by CASSANDRA-17132
>>>  in 4.0.2 and
>>> 4.1.
>>>
>>> I agree that the CHANGES.txt entry should be clearer and we'll improve
>>> it plus add detailed info in NEWS.txt. I'll get this done soon in
>>> CASSANDRA-17135 .
>>> Thanks for the feedback. Cheers!
>>>
>>

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Dinesh Joshi]

We should also have deprecation guidance in Config.java. This will help when 
anybody is making changes in the future.

> On Feb 11, 2022, at 3:07 PM, Ekaterina Dimitrova  
> wrote:
> 
> Note taken, I had to document only in 4.0.x that those are placeholder. I 
> just opened ticket to fix that - CASSANDRA-17377. I am going to submit a 
> patch soon
> 
> On Fri, 11 Feb 2022 at 17:44, Jeff Jirsa  > wrote:
> We don't HAVE TO remove the Config.java entry - we can mark it as deprecated 
> and ignored and remove it in a future version (and you could update 
> Config.java to log a message about having a deprecated config option). It's a 
> much better operator experience: log for a major version, then remove in the 
> next.
> 
> On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova  > wrote:
> This had to be removed in 4.0 but it wasn’t. The patch mentioned did it to 
> fix a bug that gives impression those work. Confirmed with Benedict on the 
> ticket.
> 
> I agree I absolutely had to document it better, a ticket for documentation 
> was opened but it slipped from my mind with this emergency release this week. 
> It is unfortunate it is still in our backlog after the ADOC migration.
> 
> Note taken. I truly apologize and I am going to prioritize CASSANDRA-17135. 
> Let me know if there is anything else I can/should do at this point. 
> 
> On Fri, 11 Feb 2022 at 17:26, Erick Ramirez  > wrote:
> (moved dev@ to BCC)
>  
> It looks like the otc_coalescing_strategy config key is no longer supported 
> in cassandra.yaml in 4.0.2, despite this not being mentioned anywhere in 
> CHANGES.txt or NEWS.txt.
> 
> James, you're right -- it was removed by CASSANDRA-17132 
>  in 4.0.2 and 4.1.
> 
> I agree that the CHANGES.txt entry should be clearer and we'll improve it 
> plus add detailed info in NEWS.txt. I'll get this done soon in 
> CASSANDRA-17135 . 
> Thanks for the feedback. Cheers!

Re: [RELEASE] Apache Cassandra 4.0.2 released

[Ekaterina Dimitrova]

Patch submitted for review.
I will also add explicit point on deprecation to the config docs I am
writing now too.

On Fri, 11 Feb 2022 at 19:10, Dinesh Joshi  wrote:

> We should also have deprecation guidance in Config.java. This will help
> when anybody is making changes in the future.
>
> On Feb 11, 2022, at 3:07 PM, Ekaterina Dimitrova 
> wrote:
>
> Note taken, I had to document only in 4.0.x that those are placeholder. I
> just opened ticket to fix that - CASSANDRA-17377. I am going to submit a
> patch soon
>
> On Fri, 11 Feb 2022 at 17:44, Jeff Jirsa  wrote:
>
>> We don't HAVE TO remove the Config.java entry - we can mark it as
>> deprecated and ignored and remove it in a future version (and you could
>> update Config.java to log a message about having a deprecated config
>> option). It's a much better operator experience: log for a major version,
>> then remove in the next.
>>
>> On Fri, Feb 11, 2022 at 2:41 PM Ekaterina Dimitrova <
>> e.dimitr...@gmail.com> wrote:
>>
>>> This had to be removed in 4.0 but it wasn’t. The patch mentioned did it
>>> to fix a bug that gives impression those work. Confirmed with Benedict on
>>> the ticket.
>>>
>>> I agree I absolutely had to document it better, a ticket for
>>> documentation was opened but it slipped from my mind with this emergency
>>> release this week. It is unfortunate it is still in our backlog after the
>>> ADOC migration.
>>>
>>> Note taken. I truly apologize and I am going to prioritize
>>> CASSANDRA-17135. Let me know if there is anything else I can/should do at
>>> this point.
>>>
>>> On Fri, 11 Feb 2022 at 17:26, Erick Ramirez 
>>> wrote:
>>>
 (moved dev@ to BCC)


> It looks like the otc_coalescing_strategy config key is no longer
> supported in cassandra.yaml in 4.0.2, despite this not being mentioned
> anywhere in CHANGES.txt or NEWS.txt.
>

 James, you're right -- it was removed by CASSANDRA-17132
  in 4.0.2 and
 4.1.

 I agree that the CHANGES.txt entry should be clearer and we'll improve
 it plus add detailed info in NEWS.txt. I'll get this done soon in
 CASSANDRA-17135 .
 Thanks for the feedback. Cheers!

>>>
>