Re: Code freeze starts 1st May. Anything to be addressed?

[Stefan Miklosovic]

16456 is crucial for me to get in. We are at the end. Should be all
resolved by end of this week.

On Mon, 25 Apr 2022 at 18:33, Paulo Motta  wrote:
>
> Hi Ekaterina,
>
> Thanks for bringing this up.
>
> I'm hoping to complete the following tickets before the freeze before May 1st:
>
> -  List snapshots of 
> dropped tables
> which will unblock:
> -  Add 
> auto_snapshot_ttl configuration
>
> In addition to the following from Stefan which I'm involved as reviewer:
> -  Implement startup 
> check to prevent Cassandra start to spread zombie data
>
> Cheers,
>
> Paulo
>
> Em seg., 25 de abr. de 2022 às 12:18, Ekaterina Dimitrova 
>  escreveu:
>>
>> Hi everyone,
>>
>> Kind reminder that 1st May is around the corner. What does this mean? Our 
>> code freeze starts on 1st May and my understanding is that only bug fixing 
>> can go into the 4.1 branch.
>> If anyone has anything to raise, now is a good time. On my end I saw a few 
>> things for this week that we should probably put to completion:
>> - CASSANDRA-17571 - I have to close this one, it is in progress; new types 
>> in Config is good to be in before the freeze I guess, even if It is not yaml 
>> change
>> - CASSANDRA-17557 - we need to take care of the parameters so we don't have 
>> to deprecate and  support anything not actually needed; I think it is 
>> probably more or less done
>> - CASSANDRA-17379 - adds a new flag around config; I think it is more or 
>> less done, depends on final CI and second reviewer maybe needed?
>> - JMX intercept Cassandra exceptions, I think David mentioned a rebase was 
>> needed
>> - CASSANDRA-17212 - The config property minimum_keyspace_rf and their 
>> nodetool getter and setter commands are new to 4.1. They are suitable to be 
>> ported to guardrails, and if we do this port in 4.1 we won't need to 
>> deprecate that property and nodetool commands in the next release, just one 
>> release after their introduction.
>>
>> I guess the failing tests we see could be fixed after the freeze but no API 
>> changes.
>>
>> Thanks everyone for all the hard work. Please don’t hesitate to raise the 
>> flag with questions, concerns or any help needed.
>>
>> Best regards,
>> Ekaterina

Pluggability improvements in 4.1

[Henrik Ingo]

Hi all

As one would expect, I've been involved in several discussions lately on
what is going to make it into 4.1, versus what patches unfortunately won't.

In particular debating this with Patrick McFaddin we realized that a big
theme in 4.1 appears to be a huge number of pluggability improvements. So
the intent of this email is to take an inventory of all new plugin APIs I'm
aware of, and invite the community to add to the list where I'm not aware
of some work.


CEP-9

Pluggable SSLContext. Allows to store SSL certs and secrets elsewhere than
in files. Supplies an example implementation for storing as Kubernetes
Secret.


*CEP-10*

SimpleCondition, Semaphore, CountDownLatch, BlockingQueue, etc
Executors, futures, starting threads, etc - including important
improvements to consistency of approach in the codebase
The use of currentTimeMillis and nanoTime
The replacement of java.io.File with a wrapper on java.nio.files.Path
providing an ergonomic API, and some improvements to consistency of file
handling
Support for alternative streaming implementations
Improvements to the dtest API to support necessary functionality

Commentary: Of the above at least the Path and alternative streaming
implementations seem like significant APIs that can be used for much more
than just fault injection. In fact, I believe java.nio.files.Path is what
we use in Astra Serverless to send files to S3 instead of local filesystem.


*CEP-11*

Pluggable memtable

Commentary: While we won't have any new memtable implementations in 4.1, it
is a goal to merge the memtable API this week. Notably, since this is
designed to support also persistent memtables (ie memtable on persistent
memory), this new API could essentially be seen as a full blown storage
engine API.


*CASSANDRA-17044* 
Pluggable schema management

I hear rumors someone may be working on a new schema management
implementation?


(Just for completeness, CASSANDRA-17058
 pluggable cluster
membership is not merged.)

CEP-16

While client side, worth mentioning: Pluggable auth for CQLSH



If there are more that I don't know about, please reply and add to the list.

henrik

-- 

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

Re: Pluggability improvements in 4.1

[Andrés de la Peña]

Hi,

Although it's not yet officially supported and it might still change in a
minor release, guardrails config is also pluggable (CEP-3). It is possible
to provide a custom implementation supplying guardrail properties different
to those defined in cassandra.yaml, so the thresholds, flags, etc. can be
based on things like, for example, who is running the guarded query.

On Tue, 26 Apr 2022 at 21:12, Henrik Ingo  wrote:

> Hi all
>
> As one would expect, I've been involved in several discussions lately on
> what is going to make it into 4.1, versus what patches unfortunately won't.
>
> In particular debating this with Patrick McFaddin we realized that a big
> theme in 4.1 appears to be a huge number of pluggability improvements. So
> the intent of this email is to take an inventory of all new plugin APIs I'm
> aware of, and invite the community to add to the list where I'm not aware
> of some work.
>
>
> CEP-9
> 
> Pluggable SSLContext. Allows to store SSL certs and secrets elsewhere than
> in files. Supplies an example implementation for storing as Kubernetes
> Secret.
>
>
> *CEP-10*
> 
> SimpleCondition, Semaphore, CountDownLatch, BlockingQueue, etc
> Executors, futures, starting threads, etc - including important
> improvements to consistency of approach in the codebase
> The use of currentTimeMillis and nanoTime
> The replacement of java.io.File with a wrapper on java.nio.files.Path
> providing an ergonomic API, and some improvements to consistency of file
> handling
> Support for alternative streaming implementations
> Improvements to the dtest API to support necessary functionality
>
> Commentary: Of the above at least the Path and alternative streaming
> implementations seem like significant APIs that can be used for much more
> than just fault injection. In fact, I believe java.nio.files.Path is what
> we use in Astra Serverless to send files to S3 instead of local filesystem.
>
>
> *CEP-11*
> 
> Pluggable memtable
>
> Commentary: While we won't have any new memtable implementations in 4.1,
> it is a goal to merge the memtable API this week. Notably, since this is
> designed to support also persistent memtables (ie memtable on persistent
> memory), this new API could essentially be seen as a full blown storage
> engine API.
>
>
> *CASSANDRA-17044* 
> Pluggable schema management
>
> I hear rumors someone may be working on a new schema management
> implementation?
>
>
> (Just for completeness, CASSANDRA-17058
>  pluggable cluster
> membership is not merged.)
>
> CEP-16
> 
> While client side, worth mentioning: Pluggable auth for CQLSH
>
>
>
> If there are more that I don't know about, please reply and add to the
> list.
>
> henrik
>
> --
>
> 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.]
> 
>