Re: [DISCUSS] CEP 33 - CIDR filtering authorizer

[Shailaja Koppu]

Hi Team,

If no one has comments/questions regarding this feature, I would like to start 
voting thread on Monday.


Thanks,
Shailaja


> On Jun 15, 2023, at 4:49 PM, Shailaja Koppu  wrote:
> 
> Adding [DISCUSS] to the subject. I request everyone here to please share your 
> thoughts/comments on this CEP.
> 
> Thank you @Nate.
> 
> 
>> On Jun 15, 2023, at 12:48 AM, Nate McCall > > wrote:
>> 
>> Hi Shailaja,
>> This looks super interesting. I particularly like the MONITOR switch. This 
>> is a huge pain-point for a lot of cluster migrations. 
>> 
>> Cheers,
>> -Nate
>> 
>> On Thu, Jun 15, 2023 at 6:43 AM Shailaja Koppu > > wrote:
>> Hi Team,
>> 
>> I have created CEP 33 - CIDR filtering authorizer 
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-33%3A+CIDR+filtering+authorizer
>>  
>> .
>> 
>> Purpose of this feature is to add the ability to restrict users accesses 
>> based on the client’s IP (or region). We can map set of CIDRs to CIDR groups 
>> (aka, regions), and then enable or disable roles to access from certain CIDR 
>> groups. CEP page details why are we doing this and how. Please go through 
>> it, comment here on the discussion thread and vote. 
>> 
>> For your reference, code for this feature is at 
>> https://github.com/apache/cassandra/pull/2414 
>> . PR description contains an 
>> example usage.
>> 
>> 
>> Thanks,
>> Shailaja
> 

[DISCUSS] Using ACCP or tc-native by default

[Jordan West]

Hi,

I’m wondering if there is appetite to change the default SSL provider for
Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
deployment as well as others I’m aware of make this change in their fork
and it can lead to significant performance improvement. When recently
qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies
were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and
also requires some amount of customization. I think it could be great for
the wider community to adopt it.

The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed.
Anything else I am missing before opening a JIRA and submitting a patch?

Jordan


[1]
https://github.com/corretto/amazon-corretto-crypto-provider

Re: [DISCUSS] Using ACCP or tc-native by default

[Jeff Jirsa]

Either would be better than today.

On Thu, Jun 22, 2023 at 1:57 PM Jordan West  wrote:

> Hi,
>
> I’m wondering if there is appetite to change the default SSL provider for
> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
> deployment as well as others I’m aware of make this change in their fork
> and it can lead to significant performance improvement. When recently
> qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies
> were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and
> also requires some amount of customization. I think it could be great for
> the wider community to adopt it.
>
> The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed.
> Anything else I am missing before opening a JIRA and submitting a patch?
>
> Jordan
>
>
> [1]
> https://github.com/corretto/amazon-corretto-crypto-provider
>

[DISCUSS] Being specific about JDK versions and python lib versions in CI

[Josh McKenzie]

Been working with Mick on CI and it dawned on me that we don't specify a 
specific required JDK version (major.minor.patch) for CI nor do we actually 
specify required python lib versions for many of the requirements in our dtests 
. We 
might implicitly enforce those via coordination between circle and the ASF env 
currently, but "Repeatable ci-cassandra.a.o" in CASSANDRA-18137 
 opens this up to being 
a potential drift point for tests.

So my questions:
1. Does anyone protest the idea of "If you run CI in your own environment 
 to validate a commit, 
here's the specific JDK version you need to use"?
2. Anyone concerned about us being specific about versions in requirements.txt 
in the dtest repo?

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Brandon Williams]

On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie  wrote:
>
> 2. Anyone concerned about us being specific about versions in 
> requirements.txt in the dtest repo?

My concern with this is atrophy; we'll set the version once and when
finally forced to update, find that a lot of other things must also be
updated in order to do so.  I think our current approach of only
setting them on things we require at a certain version like thrift has
been successful thus far, and I don't think having different versions
would be very common, but also not really affect repeatability if
encountered.  You can see what versions are used from the logs though
and could adjust them to be the same if necessary.

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Ekaterina Dimitrova]

Wouldn’t we recommend people to use the test images the project CI use?
Thus using in testing the versions we use? I would assume the repeatable CI
will still expect test images the way we have now?
(I hope I did not misunderstand the question)

I also share similar worries with Brandon

On Thu, 22 Jun 2023 at 17:48, Brandon Williams  wrote:

> On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie 
> wrote:
> >
> > 2. Anyone concerned about us being specific about versions in
> requirements.txt in the dtest repo?
>
> My concern with this is atrophy; we'll set the version once and when
> finally forced to update, find that a lot of other things must also be
> updated in order to do so.  I think our current approach of only
> setting them on things we require at a certain version like thrift has
> been successful thus far, and I don't think having different versions
> would be very common, but also not really affect repeatability if
> encountered.  You can see what versions are used from the logs though
> and could adjust them to be the same if necessary.
>

Re: [DISCUSS] Using ACCP or tc-native by default

[C. Scott Andreas]

+1 for ACCP and can attest to its results. ACCP also optimizes for a range of hash 
functions and other cryptographic primitives beyond TLS acceleration for Netty.On Jun 22, 
2023, at 2:07 PM, Jeff Jirsa  wrote:Either would be better than 
today. On Thu, Jun 22, 2023 at 1:57 PM Jordan West  wrote:Hi,I’m 
wondering if there is appetite to change the default SSL provider for Cassandra going 
forward to either ACCP [1] or tc-native in Netty? Our deployment as well as others I’m 
aware of make this change in their fork and it can lead to significant performance 
improvement. When recently qualifying 4.1 without using ACCP (by accident) we noticed p99 
latencies were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and also 
requires some amount of customization. I think it could be great for the wider community to 
adopt it. The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. 
Anything else I am missing before opening a JIRA and submitting a patch?Jordan [1] 
https://github.com/corretto/amazon-corretto-crypto-provider

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Jeremiah Jordan]

 Yes.  -1 on forcing the patch release version, and possibly minor version,
for anything that is not absolutely necessary to do so.  Especially for
things like Java or Python version, I would hope we just install the latest
Java 8, Java 11, or Java 17 JDK for the platform the image is built from
and run under them.  Otherwise we don’t find out until it’s too late when
some JDK update breaks things.  I know I always tell users to run the
latest JDK patch release, so we should do the same.

If we want to pin the major version of something, then I have no problem
there.

-Jeremiah

On Jun 22, 2023 at 5:00:36 PM, Ekaterina Dimitrova 
wrote:

> Wouldn’t we recommend people to use the test images the project CI use?
> Thus using in testing the versions we use? I would assume the repeatable CI
> will still expect test images the way we have now?
> (I hope I did not misunderstand the question)
>
> I also share similar worries with Brandon
>
> On Thu, 22 Jun 2023 at 17:48, Brandon Williams  wrote:
>
>> On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie 
>> wrote:
>> >
>> > 2. Anyone concerned about us being specific about versions in
>> requirements.txt in the dtest repo?
>>
>> My concern with this is atrophy; we'll set the version once and when
>> finally forced to update, find that a lot of other things must also be
>> updated in order to do so.  I think our current approach of only
>> setting them on things we require at a certain version like thrift has
>> been successful thus far, and I don't think having different versions
>> would be very common, but also not really affect repeatability if
>> encountered.  You can see what versions are used from the logs though
>> and could adjust them to be the same if necessary.
>>
>

Re: [DISCUSS] Being specific about JDK versions and python lib versions in CI

[Jeremy Hanna]

I like having the latest patch release always brought in for testing and CI for the JDK versions explicitly supported. So for this release, 11/17.On Jun 22, 2023, at 5:42 PM, Jeremiah Jordan  wrote:
Yes.  -1 on forcing the patch release version, and possibly minor version, for anything that is not absolutely necessary to do so.  Especially for things like Java or Python version, I would hope we just install the latest Java 8, Java 11, or Java 17 JDK for the platform the image is built from and run under them.  Otherwise we don’t find out until it’s too late when some JDK update breaks things.  I know I always tell users to run the latest JDK patch release, so we should do the same.If we want to pin the major version of something, then I have no problem there.-Jeremiah


On Jun 22, 2023 at 5:00:36 PM, Ekaterina Dimitrova  wrote:

Wouldn’t we recommend people to use the test images the project CI use? Thus using in testing the versions we use? I would assume the repeatable CI will still expect test images the way we have now? (I hope I did not misunderstand the question)I also share similar worries with BrandonOn Thu, 22 Jun 2023 at 17:48, Brandon Williams  wrote:On Thu, Jun 22, 2023 at 4:23 PM Josh McKenzie  wrote:
>
> 2. Anyone concerned about us being specific about versions in requirements.txt in the dtest repo?

My concern with this is atrophy; we'll set the version once and when
finally forced to update, find that a lot of other things must also be
updated in order to do so.  I think our current approach of only
setting them on things we require at a certain version like thrift has
been successful thus far, and I don't think having different versions
would be very common, but also not really affect repeatability if
encountered.  You can see what versions are used from the logs though
and could adjust them to be the same if necessary.

Re: [DISCUSS] Using ACCP or tc-native by default

[David Capwell]

+1 to ACCP

> On Jun 22, 2023, at 3:05 PM, C. Scott Andreas  wrote:
> 
> +1 for ACCP and can attest to its results. ACCP also optimizes for a range of 
> hash functions and other cryptographic primitives beyond TLS acceleration for 
> Netty.
> 
>> On Jun 22, 2023, at 2:07 PM, Jeff Jirsa  wrote:
>> 
>> 
>> Either would be better than today. 
>> 
>> On Thu, Jun 22, 2023 at 1:57 PM Jordan West > > wrote:
>>> Hi,
>>> 
>>> I’m wondering if there is appetite to change the default SSL provider for 
>>> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our 
>>> deployment as well as others I’m aware of make this change in their fork 
>>> and it can lead to significant performance improvement. When recently 
>>> qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies 
>>> were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and 
>>> also requires some amount of customization. I think it could be great for 
>>> the wider community to adopt it. 
>>> 
>>> The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. 
>>> Anything else I am missing before opening a JIRA and submitting a patch?
>>> 
>>> Jordan 
>>> 
>>> 
>>> [1] 
>>> https://github.com/corretto/amazon-corretto-crypto-provider
> 
> 

Re: [DISCUSS] Using ACCP or tc-native by default

[Fleming, Jackson]

We run ACCP in production on 1000s of nodes across Cassandra 3.11 and 4 with 
great results.

Would love to see it baked into Cassandra.

Jackson

From: David Capwell 
Date: Friday, 23 June 2023 at 9:22 am
To: dev 
Subject: Re: [DISCUSS] Using ACCP or tc-native by default
NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.


+1 to ACCP


On Jun 22, 2023, at 3:05 PM, C. Scott Andreas  wrote:

+1 for ACCP and can attest to its results. ACCP also optimizes for a range of 
hash functions and other cryptographic primitives beyond TLS acceleration for 
Netty.

On Jun 22, 2023, at 2:07 PM, Jeff Jirsa  wrote:


Either would be better than today.

On Thu, Jun 22, 2023 at 1:57 PM Jordan West 
mailto:jw...@apache.org>> wrote:
Hi,

I’m wondering if there is appetite to change the default SSL provider for 
Cassandra going forward to either ACCP [1] or tc-native in Netty? Our 
deployment as well as others I’m aware of make this change in their fork and it 
can lead to significant performance improvement. When recently qualifying 4.1 
without using ACCP (by accident) we noticed p99 latencies were 2x higher than 
3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and also requires some 
amount of customization. I think it could be great for the wider community to 
adopt it.

The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. 
Anything else I am missing before opening a JIRA and submitting a patch?

Jordan


[1]
https://github.com/corretto/amazon-corretto-crypto-provider

Re: [DISCUSS] Using ACCP or tc-native by default

[Jordan West]

Glad to see there is support for this! I think ACCP would be a good choice
since there seems to be a lot of experience deploying it. I’ve opened
https://issues.apache.org/jira/browse/CASSANDRA-18624. I should have some
time to work on the patch soon and I will try to provide some graphs that
show the performance benefit from a recent benchmark.

Jordan


On Thu, Jun 22, 2023 at 19:28 Fleming, Jackson 
wrote:

> We run ACCP in production on 1000s of nodes across Cassandra 3.11 and 4
> with great results.
>
>
>
> Would love to see it baked into Cassandra.
>
>
>
> Jackson
>
>
>
> *From: *David Capwell 
> *Date: *Friday, 23 June 2023 at 9:22 am
> *To: *dev 
> *Subject: *Re: [DISCUSS] Using ACCP or tc-native by default
>
> *NetApp Security WARNING*: This is an external email. Do not click links
> or open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> +1 to ACCP
>
>
>
> On Jun 22, 2023, at 3:05 PM, C. Scott Andreas 
> wrote:
>
>
>
> +1 for ACCP and can attest to its results. ACCP also optimizes for a range
> of hash functions and other cryptographic primitives beyond TLS
> acceleration for Netty.
>
>
>
> On Jun 22, 2023, at 2:07 PM, Jeff Jirsa  wrote:
>
>
>
>
>
> Either would be better than today.
>
>
>
> On Thu, Jun 22, 2023 at 1:57 PM Jordan West  wrote:
>
> Hi,
>
>
>
> I’m wondering if there is appetite to change the default SSL provider for
> Cassandra going forward to either ACCP [1] or tc-native in Netty? Our
> deployment as well as others I’m aware of make this change in their fork
> and it can lead to significant performance improvement. When recently
> qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies
> were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and
> also requires some amount of customization. I think it could be great for
> the wider community to adopt it.
>
>
>
> The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed.
> Anything else I am missing before opening a JIRA and submitting a patch?
>
>
>
> Jordan
>
>
>
>
>
> [1]
>
> https://github.com/corretto/amazon-corretto-crypto-provider
>
>
>
>
>

Re: [DISCUSS] Using ACCP or tc-native by default

[Dinesh Joshi]

This would be a good addition and would make Cassandra more performant out of the box.DineshOn Jun 22, 2023, at 9:45 PM, Jordan West  wrote:Glad to see there is support for this! I think ACCP would be a good choice since there seems to be a lot of experience deploying it. I’ve opened https://issues.apache.org/jira/browse/CASSANDRA-18624. I should have some time to work on the patch soon and I will try to provide some graphs that show the performance benefit from a recent benchmark.  JordanOn Thu, Jun 22, 2023 at 19:28 Fleming, Jackson  wrote:







We run ACCP in production on 1000s of nodes across Cassandra 3.11 and 4 with great results.
 
Would love to see it baked into Cassandra.

 
Jackson

 



From:
David Capwell 
Date: Friday, 23 June 2023 at 9:22 am
To: dev 
Subject: Re: [DISCUSS] Using ACCP or tc-native by default






NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and
 know the content is safe. 








+1 to ACCP






On Jun 22, 2023, at 3:05 PM, C. Scott Andreas  wrote:

 




+1 for ACCP and can attest to its results. ACCP also optimizes for a range of hash functions and other cryptographic primitives beyond TLS acceleration for Netty.


 



On Jun 22, 2023, at 2:07 PM, Jeff Jirsa  wrote:


 


 



Either would be better than today. 


 



On Thu, Jun 22, 2023 at 1:57 PM Jordan West  wrote:



Hi,


 


I’m wondering if there is appetite to change the default SSL provider for Cassandra going forward to either ACCP [1] or tc-native in Netty? Our deployment as well as others I’m aware of make this change in
 their fork and it can lead to significant performance improvement. When recently qualifying 4.1 without using ACCP (by accident) we noticed p99 latencies were 2x higher than 3.0 w/ ACCP. Wiring up ACCP can be a bit of a pain and also requires some amount of
 customization. I think it could be great for the wider community to adopt it. 


 


The biggest hurdle I foresee is licensing but ACCP is Apache 2.0 licensed. Anything else I am missing before opening a JIRA and submitting a patch?


 


Jordan 


 


 



[1] 


https://github.com/corretto/amazon-corretto-crypto-provider








 





 

Improved DeletionTime serialization to reduce disk size

[Berenguer Blasi]

Hi all,

DeletionTime.markedForDeleteAt is a long useconds since Unix Epoch. But 
I noticed that with 7 bytes we can already encode ~2284 years. We can 
either shed the 8th byte, for reduced IO and disk, or can encode some 
sentinel values (such as LIVE) as flags there. That would mean reading 
and writing 1 byte instead of 12 (8 mfda long + 4 ldts int). Yes we 
already avoid serializing DeletionTime (DT) in sstables at _row_ level 
entirely but not at _partition_ level and it is also serialized at 
index, metadata, etc.


So here's a POC: 
https://github.com/bereng/cassandra/commits/ldtdeser-trunk and some jmh 
(1) to evaluate the impact of the new alg (2). It's tested here against 
a 70% and a 30% LIVE DTs  to see how we perform:


 [java] Benchmark (liveDTPcParam)  (sstableParam)  Mode  Cnt  
Score   Error  Units
 [java] DeletionTimeDeSerBench.testRawAlgReads 
70PcLive  NC  avgt   15  0.331 ± 0.001  ns/op
 [java] DeletionTimeDeSerBench.testRawAlgReads 
70PcLive  OA  avgt   15  0.335 ± 0.004  ns/op
 [java] DeletionTimeDeSerBench.testRawAlgReads 
30PcLive  NC  avgt   15  0.334 ± 0.002  ns/op
 [java] DeletionTimeDeSerBench.testRawAlgReads 
30PcLive  OA  avgt   15  0.340 ± 0.008  ns/op
 [java] DeletionTimeDeSerBench.testNewAlgWrites 
70PcLive  NC  avgt   15  0.337 ± 0.006  ns/op
 [java] DeletionTimeDeSerBench.testNewAlgWrites 
70PcLive  OA  avgt   15  0.340 ± 0.004  ns/op
 [java] DeletionTimeDeSerBench.testNewAlgWrites 
30PcLive  NC  avgt   15  0.339 ± 0.004  ns/op
 [java] DeletionTimeDeSerBench.testNewAlgWrites 
30PcLive  OA  avgt   15  0.343 ± 0.016  ns/op


That was ByteBuffer backed to test the extra bit level operations 
impact. But what would be the impact of an end to end test against disk?


 [java] Benchmark (diskRAMParam)  (liveDTPcParam)  (sstableParam)  
Mode  Cnt Score    Error  Units
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 
70PcLive  NC  avgt   15   605236.515 ± 19929.058  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 
70PcLive  OA  avgt   15   586477.039 ± 7384.632  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 
30PcLive  NC  avgt   15   937580.311 ± 30669.647  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT RAM 
30PcLive  OA  avgt   15   914097.770 ± 9865.070  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT   Disk 
70PcLive  NC  avgt   15  1314417.207 ± 37879.012  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT  
Disk 70PcLive  OA  avgt   15 805256.345 ±  
15471.587  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT     
Disk 30PcLive  NC  avgt   15 1583239.011 ±  
50104.245  ns/op
 [java] DeletionTimeDeSerBench.testE2EDeSerializeDT    
Disk 30PcLive  OA  avgt   15 1439605.006 ±  
64342.510  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT  
RAM 70PcLive  NC  avgt   15 295711.217 ±   5432.507  
ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT    
RAM 70PcLive  OA  avgt   15 305282.827 ±   1906.841  
ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT  RAM 
30PcLive  NC  avgt   15   446029.899 ±   4038.938  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT    RAM 
30PcLive  OA  avgt   15   479085.875 ± 10032.804  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT     Disk 
70PcLive  NC  avgt   15  1789434.838 ± 206455.771  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT   
Disk 70PcLive  OA  avgt   15 589752.861 ±  
31676.265  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT    
Disk 30PcLive  NC  avgt   15 1754862.122 ± 
164903.051  ns/op
 [java] DeletionTimeDeSerBench.testE2ESerializeDT     Disk 
30PcLive  OA  avgt   15  1252162.253 ± 121626.818  ns/o


We can see big improvements when backed with the disk and little impact 
from the new alg.


Given we're already introducing a new sstable format (OA) in 5.0 I would 
like to try to get this in before the freeze. The point being that 
sstables with lots of small partitions would benefit from a smaller DT 
at partition level. My tests show a 3%-4% size reduction on disk.


Before proceeding though I'd like to bounce the idea against the 
community for all the corner cases and scenarios I might have missed 
where this could be a problem?


Thx in advance!


(1) 
https://github.com/bereng/cassandra/blob/ldtdeser-trunk/test/microbench/org/apache/cassandra/test/microbench/DeletionTimeDeSerBench.java


(2) 
https://github.com/bereng/cassandra/blob/ldtdeser-trunk