Re: [VOTE] Release Apache Cassandra 4.0.2

[Mick Semb Wever]

>
> Where we said:
> "All releases by default are expected to have a green test run on
> ci-cassandra.apache.org Jenkins. In exceptional circumstances (security
> incidents, data loss, etc requiring hotfix), members with binding votes
> on a release may choose to approve a release with known failing tests.”
>


CI results:
https://ci-cassandra.apache.org/job/Cassandra-4.0/328/
https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-4.0/328/

https://nightlies.apache.org/cassandra/Cassandra-4.0/328/

Re: [VOTE] Release Apache Cassandra 3.11.12

[Mick Semb Wever]

CI Results:
https://ci-cassandra.apache.org/job/Cassandra-3.11/318/
https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-3.11/318/index.html

https://nightlies.apache.org/cassandra/Cassandra-3.11/318/

Re: [VOTE] Release Apache Cassandra 4.0.2

[Tommy Stendahl]

+1 nb

On Mon, 2022-02-07 at 15:14 +0100, Mick Semb Wever wrote:
Proposing the test build of Cassandra 4.0.2 for release.

sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

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

Re: [VOTE] Release Apache Cassandra 3.11.12

[Tommy Stendahl]

+1 nb

On Mon, 2022-02-07 at 15:14 +0100, Mick Semb Wever wrote:
Proposing the test build of Cassandra 3.11.12 for release.

sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa

Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative

Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

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

Re: [VOTE] Release Apache Cassandra 3.0.26

[Mick Semb Wever]

CI results:
https://ci-cassandra.apache.org/job/Cassandra-3.0/245/
https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-3.0/245/

https://nightlies.apache.org/cassandra/Cassandra-3.0/245/

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

[Branimir Lambov]

Let us continue the configuration discussion in the CEP-11 JIRA (
https://issues.apache.org/jira/browse/CASSANDRA-17034).

Any further comments on the alternate memtable? Are we ready for a vote?

Regards,
Branimir


On Wed, Feb 9, 2022 at 12:13 PM Bowen Song  wrote:

> TBH, I don't have an opinion on the configuration. I just want to say that
> if at the end we decide the configuration in the YAML should override the
> table schema, I would like to recommend that we specifying a list of
> whitelisted (or blacklisted) "templates" in the YAML file, and the template
> chosen by the table schema is used if it's enabled, otherwise fallback to a
> default template, which could be the first element in the whitelist if
> that's used, or a separate configuration entry if a blacklist is used. The
> list should be optional in the YAML, and an empty list or the absent of it
> means everything is enabled.
>
> Advantage of this:
>
> 1. it doesn't require the operator to configure this, as an empty or
> absent list by default enables all templates and should work fine in most
> cases.
>
> 2. it allows the operator to whitelist / blacklist any template if ever
> needed (e.g. due to a bug), and also allow them to choose a fallback option.
>
> 3. the table schema has priority as long as the chosen template is not
> explicitly disabled by the YAML.
>
> 4. it allows the operator to selectively disable some templates without
> forcing all tables to use the same template specified by the YAML.
>
>
> On 09/02/2022 09:43, bened...@apache.org wrote:
>
> Why not have some default templates that can be specified by the schema
> without touching the yaml, but overridden in the yaml as necessary?
>
>
>
> *From: *Branimir Lambov  
> *Date: *Wednesday, 9 February 2022 at 09:35
> *To: *dev@cassandra.apache.org 
> 
> *Subject: *Re: [DISCUSS] CEP-19: Trie memtable implementation
>
> If I understand this correctly, you prefer _not_ to have an option to give
> the configuration explicitly in the schema. I.e. force the configurations
> ("templates" in current terms) to be specified in the yaml, and only allow
> tables to specify which one to use among them?
>
>
>
> This does sound at least as good to me, and I'll happily change the API.
>
>
>
> Regards,
>
> Branimir
>
>
>
> On Tue, Feb 8, 2022 at 10:40 PM Dinesh Joshi  wrote:
>
> My quick reading of the code suggests that schema will override the
> operator's default preference in the YAML. In the event of a bug in the new
> implementation, there could be situation where the operator might need to
> override this via the YAML.
>
>
>
> On Feb 8, 2022, at 12:29 PM, Jeremiah D Jordan 
> wrote:
>
>
>
> I don’t really see most users touching the default implementation.  I
> would expect the main reason someone would change would be
>
> 1. They run into some bug that is only in one of the implementations.
>
> 2. They have persistent memory and so want to use
> https://issues.apache.org/jira/browse/CASSANDRA-13981
>
>
>
> Given that I doubt most people will touch it, I think it is good to give
> advanced operators the ability to have more control over switching to
> things that have new performance characteristics.  So I like the idea that
> the proposed configuration approach which allows someone to change to a new
> implementation one node at a time and only for specific tables.
>
>
>
> On Feb 8, 2022, at 2:21 PM, Dinesh Joshi  wrote:
>
>
>
> Thank you for sharing the perf test results.
>
>
>
> Going back to the schema vs yaml configuration. I am concerned users may
> pick the wrong implementation for their use-case. Is there any chance for
> us to automatically pick a MemTable implementation based on heuristics? Do
> we foresee users ever picking the existing SkipList implementation over the
> Trie Given the performance tests, it seems the Trie implementation is the
> clear winner.
>
>
>
> To be clear, I am not suggesting we remove the existing implementation. I
> am for maintaining a pluggable API for various components.
>
>
>
> Dinesh
>
>
>
> On Feb 7, 2022, at 8:39 AM, Branimir Lambov  wrote:
>
>
>
> Added some performance results to the ticket:
> https://issues.apache.org/jira/browse/CASSANDRA-17240
>
>
>
> Regards,
>
> Branimir
>
>
>
> On Sat, Feb 5, 2022 at 10:59 PM Dinesh Joshi  wrote:
>
> This is excellent. Thanks for opening up this CEP. It would be great to
> get some stats around GC allocation rate / memory pressure, read & write
> latencies, etc. compared to existing implementation.
>
>
>
> Dinesh
>
>
>
> On Jan 18, 2022, at 2:13 AM, Branimir Lambov  wrote:
>
>
>
> The memtable pluggability API (CEP-11) is per-table to enable memtable
> selection that suits specific workflows. It also makes full sense to permit
> per-node configuration, both to be able to modify the configuration to suit
> heterogeneous deployments better, as well as to test changes for
> improvements such as this one.
>
> Recognizing this, the patch comes with a modification to the API
> 

Re: [VOTE] Release Apache Cassandra 4.0.2

[Ekaterina Dimitrova]

+0nb
I am not sure I am getting enough information from our CI to vote for
either +1 or -1. I was chasing CI issues two days, being worried did I
break something with CCM change I introduced over the weekend as CI started
hanging in a weird way. (If I knew there will be a release I wouldn’t have
committed change to ccm…) At the end I reproduced some of the issues
causing the CI to hang with the CCM version prior my changes in Circle CI.
On the bright side, I tested all branches one more time in Circle CI the
other day and I got confirmation on the current state.

Release or not I think anyway we have material to think/work on as a
community

On Thu, 10 Feb 2022 at 4:07, Tommy Stendahl 
wrote:

> +1 nb
>
> On Mon, 2022-02-07 at 15:14 +0100, Mick Semb Wever wrote:
>
> Proposing the test build of Cassandra 4.0.2 for release.
>
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>
>

Re: [VOTE] Release Apache Cassandra 4.0.2

[Yifan Cai]

+1 on the release

On Thu, Feb 10, 2022 at 7:23 AM Ekaterina Dimitrova 
wrote:

> +0nb
> I am not sure I am getting enough information from our CI to vote for
> either +1 or -1. I was chasing CI issues two days, being worried did I
> break something with CCM change I introduced over the weekend as CI started
> hanging in a weird way. (If I knew there will be a release I wouldn’t have
> committed change to ccm…) At the end I reproduced some of the issues
> causing the CI to hang with the CCM version prior my changes in Circle CI.
> On the bright side, I tested all branches one more time in Circle CI the
> other day and I got confirmation on the current state.
>
> Release or not I think anyway we have material to think/work on as a
> community
>
> On Thu, 10 Feb 2022 at 4:07, Tommy Stendahl 
> wrote:
>
>> +1 nb
>>
>> On Mon, 2022-02-07 at 15:14 +0100, Mick Semb Wever wrote:
>>
>> Proposing the test build of Cassandra 4.0.2 for release.
>>
>> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
>>
>> Git:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
>>
>> Maven Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
>>
>> The Source and Build Artifacts, and the Debian and RPM packages and
>> repositories, are available here:
>> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
>>
>> The vote will be open for 72 hours (longer if needed). Everyone who has
>> tested the build is invited to vote. Votes by PMC members are considered
>> binding. A vote passes if there are at least three binding +1s and no -1's.
>>
>> [1]: CHANGES.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
>> [2]: NEWS.txt:
>> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative
>>
>>

Re: [DISCUSS] CEP-7 Storage Attached Index

[Mike Adamson]

> 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 mailto:henrik.i...@datastax.com>>
> 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 
> 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 current 
> implementation is by no means perfect as a general purpose OR support, the 
> focus all the time was on implementing OR support in SAI. I'll leave it to 
> others to enumerate exactly the limitations of the current implementation.
>  
> Seeing that also Benedict supports your point of view, I would steer the 
> conversation more into a project management perspective:
> * How can we advance CEP-7 so that the bulk of the SAI code can still be 
> added to Cassandra, so that  users can benefit from this new index type, 
> albeit without OR?
> * This is also an important question from the point of view that this is a 
> large block of code that will inevitably diverged if it's not in trunk. Also, 
> merging it to trunk will allow future enhancements, including the OR syntax 
> btw, to happen against trunk (aka upstream first).
> * Since OR support nevertheless is a feature of SAI, it needs to be at least 
> unit tested, but ideally even would be exposed so that it is possible to test 
> on the CQL level. Is there some mechanism such as experimental flags, which 
> would allow the SAI-only OR support to be merged into trunk, while a separate 
> CEP is focused on implementing "proper" general purpose OR support? I should 
> note

Re: [VOTE] Release Apache Cassandra 3.0.26

[Mick Semb Wever]

CI results:
https://ci-cassandra.apache.org/job/Cassandra-3.0/245/
https://nightlies.apache.org/cassandra/ci-cassandra.apache.org/job/Cassandra-3.0/245/

https://nightlies.apache.org/cassandra/Cassandra-3.0/245/

Dynamic Table TTL

[Paulo Motta]

Hi,

Just a heads up that I created CASSANDRA-17372 to explore supporting
dynamic table TTL and would like to hear your feedback (on the idea) before
moving forward with a design. Please add any potential comments to the
ticket.

Cheers,

Paulo

[1] - https://issues.apache.org/jira/browse/CASSANDRA-17372

[RESULT][VOTE] Release Apache Cassandra 3.0.26

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


Vote passes.
Four +1 binding.
One +1 non-binding.
Two -1 non-binding.

[RESULT][VOTE] Release Apache Cassandra 3.11.12

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



Vote passes.
Four +1 binding.
One +1 non-binding.
Two -1 non-binding.

[RESULT]VOTE] Release Apache Cassandra 4.0.2

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



Vote passes.
Five +1 binding.
Two +1 non-binding.
One +0 non-binding.
Two -1 non-binding.