[VOTE] CEP-19: Trie memtable implementation

[Branimir Lambov]

Hi everyone,

I'd like to propose CEP-19 for approval.

Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty

The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thank you,
Branimir

Re: [VOTE] CEP-19: Trie memtable implementation

[bened...@apache.org]

+1

From: Branimir Lambov 
Date: Wednesday, 16 February 2022 at 08:58
To: dev@cassandra.apache.org 
Subject: [VOTE] CEP-19: Trie memtable implementation
Hi everyone,

I'd like to propose CEP-19 for approval.

Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty

The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thank you,
Branimir

Re: [DISCUSS] CEP-7 Storage Attached Index

[Mike Adamson]

I have updated the CEP to reflect the recent discussions.

OR support has moved out of version 1 support. Index versioning and virtual 
table support are now covered in the Addenda.

MikeA

> On 14 Feb 2022, at 15:35, Caleb Rackliffe  wrote:
> 
> Agreed there’s no reason to pull it out. I was just wondering what state it 
> was in, given I didn’t see it mentioned in the CEP.
> 
>> On Feb 14, 2022, at 8:12 AM, Mike Adamson  wrote:
>> 
>> > 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?
>> 
>> I’m not sure why we would want to pull the versioning code only to have to 
>> put it back in as soon as we need to change the on-disk format. We also need 
>> to consider whether the legacy format used by DSE is supported in OSS. I’m 
>> not sure of the policy on this although I strongly suspect that the answer 
>> is that it won’t be supported. Either way, it would seem to be a lot of work 
>> to pull the versioning code out at this point since it formed part of a 
>> major refactor of the SAI framework and plumbing.
>> 
>> MikeA
>> 
>>> On 11 Feb 2022, at 18:47, Caleb Rackliffe >> > wrote:
>>> 
>>> 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  
 mailto: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 ta

Apache Cassandra fuzz testing

[Alex Petrov]

Hi everyone,

As you may know, we've been actively working on fuzz testing Apache Cassandra 
for the past several years and made quite a large progress on that front.

Re: Apache Cassandra fuzz testing

[Alex Petrov]

(apologies for sending an incomplete email) 

Hi everyone,

As you may know, we’ve been actively working on fuzz testing Apache Cassandra 
for the past several years and made quite a large progress on that front.

We’ve cut a 0.0.1 release of Harry [1], a fuzz testing tool for apache 
Cassandra and merged CASSANDRA-16262 [2].

I’d recommend us as a community to take the next logical step and demand fuzz / 
property-based tests for all marjor patches, and start migrating/updating 
existing tests to be property-based rather than using hardoced values.

Harry can be used to generate data, and then check that a sequence of events 
corresponds to Cassandra resolution rules. We will continue expanding Harry 
coverage and writing new models and checkers, too.

If you would like to learn more about Harry, you can refer to a recent blog 
post [3]. I will also be happy to answer any questions you may have about Harry 
and assist you in writing your tests, and helping to extend Harry in case 
there’s a feature you may need to accomplish it.

Thank you,
—Alex

[1] [GitHub - apache/cassandra-harry: Apache Cassandra - 
Harry](https://github.com/apache/cassandra-harry)
[2] [CASSANDRA-16262 4.0 Quality: Coordination & Replication Fuzz Testing - ASF 
JIRA](https://issues.apache.org/jira/browse/CASSANDRA-16262)
[3] [Apache Cassandra | Apache Cassandra 
Documentation](https://cassandra.apache.org/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html)

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Erick Ramirez]

Thanks everyone! I'm grateful for the support over the years. I keep saying
that it's a real honour to have the trust of the community on such an
important project. Cheers! 🍻

>

Re: Client password hashing

[Bowen Song]

To me this doesn't sound very useful. Here's a few threat model I can 
think of that may be related to this proposal, and why is this not 
addressing the issues & what should be done instead.


1. passwords are send over network in plaintext allows passive packet 
sniffier to learn about the password


When the user logging in and authenticating themselves, they will have 
to send both the username and password to the server in plaintext anyway.


Securing the connection with TLS should address this concern.

2. malicious intermediaries (external loadbancer, middleware, etc.) are 
able learn about the password


The admin user must login against the intermediary before 
creating/altering other users, this exposes the admin user's credentials 
to the malicious intermediary.


Only use trusted intermediaries, and use TLS between the client & 
Cassandra server wherever possible (e.g. don't terminate TLS at the 
loadbalancer).


3. accidentally logging the password to an insecure log file

Logging a hashed password to an insecure log file is still very bad

The logger module should correctly redact the data


If this proposal helps mitigating a different threat model that you have 
in mind, please kindly share it with us.



On 16/02/2022 07:44, Berenguer Blasi wrote:

Hi all,

I would like to propose to add support for client password hashing 
(https://issues.apache.org/jira/browse/CASSANDRA-17334). If anybody 
has any concerns or question with this functionality I will be happy 
to discuss them.


Thx in advance.

Re: [VOTE] CEP-19: Trie memtable implementation

[Brandon Williams]

+1

On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov  wrote:
>
> Hi everyone,
>
> I'd like to propose CEP-19 for approval.
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
>
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding vetoes.
>
> Thank you,
> Branimir

Re: [VOTE] CEP-19: Trie memtable implementation

[Ekaterina Dimitrova]

+1nb

On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:

> +1
>
> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov 
> wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose CEP-19 for approval.
> >
> > Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> > Discussion:
> https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
> >
> > The vote will be open for 72 hours.
> > Votes by committers are considered binding.
> > A vote passes if there are at least three binding +1s and no binding
> vetoes.
> >
> > Thank you,
> > Branimir
>

Re: [VOTE] CEP-19: Trie memtable implementation

[Josh McKenzie]

+1

On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
> +1nb
> 
> On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
>> +1
>> 
>> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov  wrote:
>> >
>> > Hi everyone,
>> >
>> > I'd like to propose CEP-19 for approval.
>> >
>> > Proposal: 
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>> > Discussion: 
>> > https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
>> >
>> > The vote will be open for 72 hours.
>> > Votes by committers are considered binding.
>> > A vote passes if there are at least three binding +1s and no binding 
>> > vetoes.
>> >
>> > Thank you,
>> > Branimir

Re: Client password hashing

[J. D. Jordan]

Can we have the discussion on the ticket?

Thanks
-Jeremiah

> On Feb 16, 2022, at 6:23 AM, Bowen Song  wrote:
> 
> To me this doesn't sound very useful. Here's a few threat model I can think 
> of that may be related to this proposal, and why is this not addressing the 
> issues & what should be done instead.
> 
> 1. passwords are send over network in plaintext allows passive packet 
> sniffier to learn about the password
> 
> When the user logging in and authenticating themselves, they will have to 
> send both the username and password to the server in plaintext anyway.
> 
> Securing the connection with TLS should address this concern.
> 
> 2. malicious intermediaries (external loadbancer, middleware, etc.) are able 
> learn about the password
> 
> The admin user must login against the intermediary before creating/altering 
> other users, this exposes the admin user's credentials to the malicious 
> intermediary.
> 
> Only use trusted intermediaries, and use TLS between the client & Cassandra 
> server wherever possible (e.g. don't terminate TLS at the loadbalancer).
> 
> 3. accidentally logging the password to an insecure log file
> 
> Logging a hashed password to an insecure log file is still very bad
> 
> The logger module should correctly redact the data
> 
> 
> If this proposal helps mitigating a different threat model that you have in 
> mind, please kindly share it with us.
> 
> 
>> On 16/02/2022 07:44, Berenguer Blasi wrote:
>> Hi all,
>> 
>> I would like to propose to add support for client password hashing 
>> (https://issues.apache.org/jira/browse/CASSANDRA-17334). If anybody has any 
>> concerns or question with this functionality I will be happy to discuss them.
>> 
>> Thx in advance.
>> 

Re: [VOTE] CEP-19: Trie memtable implementation

[J. D. Jordan]

+1 nb

> On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
> 
> 
> +1
> 
>> On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
>> +1nb
>> 
>> On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
>> +1
>> 
>> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov  wrote:
>> >
>> > Hi everyone,
>> >
>> > I'd like to propose CEP-19 for approval.
>> >
>> > Proposal: 
>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>> > Discussion: 
>> > https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
>> >
>> > The vote will be open for 72 hours.
>> > Votes by committers are considered binding.
>> > A vote passes if there are at least three binding +1s and no binding 
>> > vetoes.
>> >
>> > Thank you,
>> > Branimir

Re: [VOTE] CEP-19: Trie memtable implementation

[Jeremy Hanna]

+1 nb.  Thanks for all of the great work on this Branimir.  Excited to see this 
moving forward.

> On Feb 16, 2022, at 7:56 AM, J. D. Jordan  wrote:
> 
> +1 nb
> 
>> On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
>> 
>> 
>> +1
>> 
>> On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
>>> +1nb
>>> 
>>> On Wed, 16 Feb 2022 at 7:30, Brandon Williams >> > wrote:
>>> +1
>>> 
>>> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov >> > wrote:
>>> >
>>> > Hi everyone,
>>> >
>>> > I'd like to propose CEP-19 for approval.
>>> >
>>> > Proposal: 
>>> > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>>> >  
>>> > 
>>> > Discussion: 
>>> > https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty 
>>> > 
>>> >
>>> > The vote will be open for 72 hours.
>>> > Votes by committers are considered binding.
>>> > A vote passes if there are at least three binding +1s and no binding 
>>> > vetoes.
>>> >
>>> > Thank you,
>>> > Branimir

Re: Client password hashing

[Berenguer Blasi]

Yeah that sounds great also imo. I'll move Bowen's comment to the ticket 
and we can continue there. Thx


On 16/2/22 14:55, J. D. Jordan wrote:

Can we have the discussion on the ticket?

Thanks
-Jeremiah


On Feb 16, 2022, at 6:23 AM, Bowen Song  wrote:

To me this doesn't sound very useful. Here's a few threat model I can think of 
that may be related to this proposal, and why is this not addressing the issues 
& what should be done instead.

1. passwords are send over network in plaintext allows passive packet sniffier 
to learn about the password

When the user logging in and authenticating themselves, they will have to send 
both the username and password to the server in plaintext anyway.

Securing the connection with TLS should address this concern.

2. malicious intermediaries (external loadbancer, middleware, etc.) are able 
learn about the password

The admin user must login against the intermediary before creating/altering 
other users, this exposes the admin user's credentials to the malicious 
intermediary.

Only use trusted intermediaries, and use TLS between the client & Cassandra 
server wherever possible (e.g. don't terminate TLS at the loadbalancer).

3. accidentally logging the password to an insecure log file

Logging a hashed password to an insecure log file is still very bad

The logger module should correctly redact the data


If this proposal helps mitigating a different threat model that you have in 
mind, please kindly share it with us.



On 16/02/2022 07:44, Berenguer Blasi wrote:
Hi all,

I would like to propose to add support for client password hashing 
(https://issues.apache.org/jira/browse/CASSANDRA-17334). If anybody has any 
concerns or question with this functionality I will be happy to discuss them.

Thx in advance.

Re: [VOTE] CEP-19: Trie memtable implementation

[Sam Tunnicliffe]

+1

> On 16 Feb 2022, at 08:57, Branimir Lambov  wrote:
> 
> Hi everyone,
> 
> I'd like to propose CEP-19 for approval.
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>  
> 
> Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty 
> 
> 
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding vetoes.
> 
> Thank you,
> Branimir

Re: Apache Cassandra fuzz testing

[bened...@apache.org]

+1

The Simulator is hopefully going to be another powerful tool for this kind of 
work, and we should be encouraging the use of both for large or complex pieces 
of work.


From: Alex Petrov 
Date: Wednesday, 16 February 2022 at 11:56
To: dev@cassandra.apache.org 
Subject: Re: Apache Cassandra fuzz testing
(apologies for sending an incomplete email)

Hi everyone,

As you may know, we’ve been actively working on fuzz testing Apache Cassandra 
for the past several years and made quite a large progress on that front.

We’ve cut a 0.0.1 release of Harry [1], a fuzz testing tool for apache 
Cassandra and merged CASSANDRA-16262 [2].

I’d recommend us as a community to take the next logical step and demand fuzz / 
property-based tests for all marjor patches, and start migrating/updating 
existing tests to be property-based rather than using hardoced values.

Harry can be used to generate data, and then check that a sequence of events 
corresponds to Cassandra resolution rules. We will continue expanding Harry 
coverage and writing new models and checkers, too.

If you would like to learn more about Harry, you can refer to a recent blog 
post [3]. I will also be happy to answer any questions you may have about Harry 
and assist you in writing your tests, and helping to extend Harry in case 
there’s a feature you may need to accomplish it.

Thank you,
—Alex

[1] [GitHub - apache/cassandra-harry: Apache Cassandra - 
Harry](https://github.com/apache/cassandra-harry)
[2] [CASSANDRA-16262 4.0 Quality: Coordination & Replication Fuzz Testing - ASF 
JIRA](https://issues.apache.org/jira/browse/CASSANDRA-16262)
[3] [Apache Cassandra | Apache Cassandra 
Documentation](https://cassandra.apache.org/_/blog/Harry-an-Open-Source-Fuzz-Testing-and-Verification-Tool-for-Apache-Cassandra.html)

Re: [VOTE] CEP-19: Trie memtable implementation

[C. Scott Andreas]

+1nb

> On Feb 16, 2022, at 5:59 AM, Jeremy Hanna  wrote:
> 
> +1 nb.  Thanks for all of the great work on this Branimir.  Excited to see 
> this moving forward.
> 
>> On Feb 16, 2022, at 7:56 AM, J. D. Jordan  wrote:
>> 
>> +1 nb
>> 
 On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
 
>>> 
>>> +1
>>> 
 On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
 +1nb
 
 On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
 +1
 
 On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov  wrote:
 >
 > Hi everyone,
 >
 > I'd like to propose CEP-19 for approval.
 >
 > Proposal: 
 > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
 > Discussion: 
 > https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
 >
 > The vote will be open for 72 hours.
 > Votes by committers are considered binding.
 > A vote passes if there are at least three binding +1s and no binding 
 > vetoes.
 >
 > Thank you,
 > Branimir
> 

Re: [DISCUSS] CEP-7 Storage Attached Index

[Caleb Rackliffe]

Thanks, Mike.

Are there any other concerns we should address before we move to a vote?

On Wed, Feb 16, 2022 at 5:25 AM Mike Adamson  wrote:

> I have updated the CEP to reflect the recent discussions.
>
> OR support has moved out of version 1 support. Index versioning and
> virtual table support are now covered in the Addenda.
>
> MikeA
>
> On 14 Feb 2022, at 15:35, Caleb Rackliffe 
> wrote:
>
> Agreed there’s no reason to pull it out. I was just wondering what state
> it was in, given I didn’t see it mentioned in the CEP.
>
> On Feb 14, 2022, at 8:12 AM, Mike Adamson  wrote:
>
> > 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?
>
> I’m not sure why we would want to pull the versioning code only to have to
> put it back in as soon as we need to change the on-disk format. We also
> need to consider whether the legacy format used by DSE is supported in OSS.
> I’m not sure of the policy on this although I strongly suspect that the
> answer is that it won’t be supported. Either way, it would seem to be a lot
> of work to pull the versioning code out at this point since it formed part
> of a major refactor of the SAI framework and plumbing.
>
> MikeA
>
> On 11 Feb 2022, at 18:47, Caleb Rackliffe 
> wrote:
>
> 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 

Re: [VOTE] CEP-19: Trie memtable implementation

[Andrés de la Peña]

+1nb

On Wed, 16 Feb 2022 at 15:57, C. Scott Andreas  wrote:

> +1nb
>
> On Feb 16, 2022, at 5:59 AM, Jeremy Hanna 
> wrote:
>
> +1 nb.  Thanks for all of the great work on this Branimir.  Excited to
> see this moving forward.
>
> On Feb 16, 2022, at 7:56 AM, J. D. Jordan 
> wrote:
>
> +1 nb
>
> On Feb 16, 2022, at 7:30 AM, Josh McKenzie  wrote:
>
> 
> +1
>
> On Wed, Feb 16, 2022, at 7:33 AM, Ekaterina Dimitrova wrote:
>
> +1nb
>
> On Wed, 16 Feb 2022 at 7:30, Brandon Williams  wrote:
>
> +1
>
> On Wed, Feb 16, 2022 at 3:00 AM Branimir Lambov 
> wrote:
> >
> > Hi everyone,
> >
> > I'd like to propose CEP-19 for approval.
> >
> > Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> > Discussion:
> https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
> >
> > The vote will be open for 72 hours.
> > Votes by committers are considered binding.
> > A vote passes if there are at least three binding +1s and no binding
> vetoes.
> >
> > Thank you,
> > Branimir
>
>
>

Re: [VOTE] CEP-19: Trie memtable implementation

[Michael Shuler]

+1

On 2/16/22 02:57, Branimir Lambov wrote:

Hi everyone,

I'd like to propose CEP-19 for approval.

Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation 

Discussion: 
https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty 



The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thank you,
Branimir

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Sharan Foga]

Congratulations Lorina, Erick and Anthony! Well done

And also kudos to the PMC for making this happen!

Thanks
Sharan

On 2022/02/15 18:12:46 Benjamin Lerer wrote:
>  The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez
> and Lorina Poland have accepted the invitation to become committers.
> 
> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on
> the website and documentation.
> 
> Congratulations and welcome
> 
> The Apache Cassandra PMC members
> 

[RESULT][VOTE] Release Apache Cassandra 4.0.3

[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.
>


The vote passes with four binding +1s

Re: Welcome Anthony Grasso, Erick Ramirez and Lorina Poland as Cassandra committers

[Joseph Lynch]

Woo

Congratulations to the new committers and I am so excited to see the
project recognizing these contributions!

-Joey


On Tue, Feb 15, 2022 at 10:13 AM Benjamin Lerer  wrote:
>
> The PMC members are pleased to announce that Anthony Grasso, Erick Ramirez 
> and Lorina Poland have accepted the invitation to become committers.
>
> Thanks a lot, Anthony, Erick and Lorina for all the work you have done on the 
> website and documentation.
>
> Congratulations and welcome
>
> The Apache Cassandra PMC members

Re: [VOTE] CEP-19: Trie memtable implementation

[Joseph Lynch]

+1 nb

Really excited for this, Thank you Branimir!

-Joey

On Wed, Feb 16, 2022 at 12:58 AM Branimir Lambov  wrote:
>
> Hi everyone,
>
> I'd like to propose CEP-19 for approval.
>
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
> Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
>
> The vote will be open for 72 hours.
> Votes by committers are considered binding.
> A vote passes if there are at least three binding +1s and no binding vetoes.
>
> Thank you,
> Branimir

Re: [VOTE] CEP-19: Trie memtable implementation

[Berenguer Blasi]

+1

On 16/2/22 23:50, Joseph Lynch wrote:

+1 nb

Really excited for this, Thank you Branimir!

-Joey

On Wed, Feb 16, 2022 at 12:58 AM Branimir Lambov  wrote:

Hi everyone,

I'd like to propose CEP-19 for approval.

Proposal: 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty

The vote will be open for 72 hours.
Votes by committers are considered binding.
A vote passes if there are at least three binding +1s and no binding vetoes.

Thank you,
Branimir

Re: [VOTE] CEP-19: Trie memtable implementation

[Dinesh Joshi]

+1

On 2/16/22 21:45, Berenguer Blasi wrote:
> +1
> 
> On 16/2/22 23:50, Joseph Lynch wrote:
>> +1 nb
>>
>> Really excited for this, Thank you Branimir!
>>
>> -Joey
>>
>> On Wed, Feb 16, 2022 at 12:58 AM Branimir Lambov 
>> wrote:
>>> Hi everyone,
>>>
>>> I'd like to propose CEP-19 for approval.
>>>
>>> Proposal:
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
>>>
>>> Discussion:
>>> https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
>>>
>>> The vote will be open for 72 hours.
>>> Votes by committers are considered binding.
>>> A vote passes if there are at least three binding +1s and no binding
>>> vetoes.
>>>
>>> Thank you,
>>> Branimir

[RELEASE] Apache Cassandra 4.0.3 released

[Mick Semb Wever]

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

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.3
[2]: NEWS.txt
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/cassandra-4.0.3
[3]: https://issues.apache.org/jira/browse/CASSANDRA