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

[Dinesh Joshi]

enable it by default.
>>> 
>>> 
>>> – Scott
>>> 
>>>> On Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" 
>>>> mailto:stefan.mikloso...@netapp.com>> wrote:
>>>> 
>>>> 
>>>> We can make it opt-in, wait one major to see what bugs pop up and we might 
>>>> do that opt-out eventually. We do not need to hurry up with this. I 
>>>> understand everybody's expectations and excitement but it really boils 
>>>> down to one line change in yaml. People who are so much after the 
>>>> performance will be definitely aware of this knob to turn on to squeeze 
>>>> even more perf ...
>>>> 
>>>> I look around dtests Jeremiah mentioned but I would just moved on and make 
>>>> it opt-in if we are not 100% persuaded about it _yet_.
>>>> 
>>>> 
>>>> From: Mick Semb Wever mailto:m...@apache.org>>
>>>> Sent: Wednesday, July 26, 2023 20:48
>>>> To: dev@cassandra.apache.org <mailto:dev@cassandra.apache.org>
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> What comes to mind is how we brought down people clusters and made 
>>>> sstables unreadable with the introduction of the chunk_length 
>>>> configuration in 1.0. It wasn't about how tested the compression libraries 
>>>> were, but about the new configuration itself. Introducing silent defaults 
>>>> has more surface area for bugs than introducing explicit defaults that 
>>>> only apply to new clusters and are so opt-in for existing clusters.
>>>> 
>>>> 
>>>> 
>>>> On Wed, 26 Jul 2023 at 20:13, J. D. Jordan >>> <mailto:jeremiah.jor...@gmail.com><mailto:jeremiah.jor...@gmail.com 
>>>> <mailto:jeremiah.jor...@gmail.com>>> wrote:
>>>> Enabling ssl for the upgrade dtests would cover this use case. If those 
>>>> don’t currently exist I see no reason it won’t work so I would be fine for 
>>>> someone to figure it out post merge if there is a concern. What JCE 
>>>> provider you use should have no upgrade concerns.
>>>> 
>>>> -Jeremiah
>>>> 
>>>>> On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan 
>>>>> >>>> <mailto:stefan.mikloso...@netapp.com><mailto:stefan.mikloso...@netapp.com 
>>>>> <mailto:stefan.mikloso...@netapp.com>>> wrote:
>>>>> 
>>>>> Am I understanding it correctly that tests you are talking about are 
>>>>> only required in case we make ACCP to be default provider?
>>>>> 
>>>>> I can live with not making it default and still deliver it if tests are 
>>>>> not required. I do not think that these kind of tests were required 
>>>>> couple mails ago when opt-in was on the table.
>>>>> 
>>>>> While I tend to agree with people here who seem to consider testing this 
>>>>> scenario to be unnecessary exercise, I am afraid that I will not be able 
>>>>> to deliver that as testing something like this is quite complicated 
>>>>> matter. There is a lot of aspects which could be tested I can not even 
>>>>> enumerate right now ... so I try to meet you somewhere in the middle.
>>>>> 
>>>>> 
>>>>> From: Mick Semb Wever >>>> <mailto:m...@apache.org><mailto:m...@apache.org <mailto:m...@apache.org>>>
>>>>> Sent: Wednesday, July 26, 2023 17:34
>>>>> To: dev@cassandra.apache.org 
>>>>> <mailto:dev@cassandra.apache.org><mailto:dev@cassandra.apache.org 
>>>>> <mailto:dev@cassandra.apache.org>>
>>>>> 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.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Can you say more about the shape of your concern?
>>>>> 
>>>>> 
>>>>> Integration testing where some nodes are running JCE and others accp, and 
>>>>> various configurations that are and are not accp compatible/native.
>>>>> 
>>>>> I'm not referring to (re-) unit testing accp or jce themselves, or matrix 
>>>>> testing over them, but our commitment to always-on upgrades against all 
>>>>> possible configurations that integrate. We've history with config changes 
>>>>> breaking upgrades, for as simple as they are.

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

[Josh McKenzie]

+1 to the "on by default" camp.

> What comes to mind is how we brought down people clusters and made sstables 
> unreadable with the introduction of the chunk_length configuration in 1.0
I think a key difference here is that changing chunk length is something that 
materially changes behavior and expectations w/a coupled system, whereas 
switching crypto providers has the much smaller failure mode of "the 
implementations aren't binary compatible even though they're supposed to be, 
and are very heavily tested TO be".

Totally agree that a "surprise! it didn't load so now your nodes won't start" 
approach would be a Very Bad Experience for users. Falling back from ACCP and 
squawking about the lack might actually be nice to help folks where it doesn't 
load / work / etc know to look into it. It really makes a material difference.

On Wed, Jul 26, 2023, at 4:02 PM, Jordan West wrote:
> It sounds like some of the concerns have shifted then. I would like to better 
> understand the YAML one. Like Jeremiah said it may be a better topic for the 
> ticket. Would appreciate an example exception or error people are concerned 
> about. 
> 
> If the issue is the “fail fast” on start I’m sure we can find a solution 
> everyone accepts and move forward. 
> 
> If we are agreed “on by default” is the way to go that’s awesome! 
> 
> Jordan 
> 
> On Wed, Jul 26, 2023 at 12:59 Jeremiah Jordan  
> wrote:
>> I had a discussion with Mick on slack.  His concern is not with enabling 
>> ACCP.  His concern is around the testing of the new C* yaml config code 
>> which is included in the patch that is used to decide if ACCP should be 
>> enabled or not, and if startup should fail if it can’t be enabled.
>> 
>> I agree.  We should make sure that the new C* yaml config code is solid 
>> before we commit this patch, especially when it has the possibility of cause 
>> node startup to fail on purpose.  But that should be a discussion for the 
>> ticket I think, not for this thread.
>> 
>> So I think we are back to the original question.  Should ACCP be used by 
>> default in trunk.  From what I have seen I do not see anyone who is against 
>> that?
>> 
>> -Jeremiah
>> 
>> 
>> On Jul 26, 2023 at 2:53:02 PM, Jordan West  wrote:
>>> +1 Scott. And agreed all involved are looking out for the best interests of 
>>> C* users. And I appreciate those with concerns contributing to addressing 
>>> them. 
>>> 
>>> I’m all for making upgrades smooth bc I do them so often. A huge portion of 
>>> our 4.1 qualification is “will it break on upgrade”? Because of that I’m 
>>> confident in this patch and concerned about many other areas. I think it’s 
>>> commedable to want to reach a point where teams have the trust in the 
>>> community to have done that for them but that starts w better test coverage 
>>> and concrete evidence. 
>>> 
>>> Given all that, I think we should move forward w Ayushi’s proposal to make 
>>> it on by default. 
>>> 
>>> Jordan 
>>> 
>>> On Wed, Jul 26, 2023 at 12:14 C. Scott Andreas  wrote:
>>>> I think these concerns are well-intended, but they feel rooted in 
>>>> uncertainty rather than in factual examples of areas where risk is 
>>>> present. I would appreciate elaboration on the specific areas of risk that 
>>>> folks imagine.
>>>> 
>>>> I would encourage those who express skepticism to try the patch, and I 
>>>> endorse Ayushi's proposal to enable it by default.
>>>> 
>>>> 
>>>> – Scott
>>>> 
>>>>> On Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> We can make it opt-in, wait one major to see what bugs pop up and we 
>>>>> might do that opt-out eventually. We do not need to hurry up with this. I 
>>>>> understand everybody's expectations and excitement but it really boils 
>>>>> down to one line change in yaml. People who are so much after the 
>>>>> performance will be definitely aware of this knob to turn on to squeeze 
>>>>> even more perf ...
>>>>> 
>>>>> I look around dtests Jeremiah mentioned but I would just moved on and 
>>>>> make it opt-in if we are not 100% persuaded about it _yet_.
>>>>> 
>>>>> 
>>>>> From: Mick Semb Wever 
>>>>> Sent: Wednesday, July 26, 2023 20:48
>>>>> To: dev@cassa

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

[Jordan West]

It sounds like some of the concerns have shifted then. I would like to
better understand the YAML one. Like Jeremiah said it may be a better topic
for the ticket. Would appreciate an example exception or error people are
concerned about.

If the issue is the “fail fast” on start I’m sure we can find a solution
everyone accepts and move forward.

If we are agreed “on by default” is the way to go that’s awesome!

Jordan

On Wed, Jul 26, 2023 at 12:59 Jeremiah Jordan 
wrote:

> I had a discussion with Mick on slack.  His concern is not with enabling
> ACCP.  His concern is around the testing of the new C* yaml config code
> which is included in the patch that is used to decide if ACCP should be
> enabled or not, and if startup should fail if it can’t be enabled.
>
> I agree.  We should make sure that the new C* yaml config code is solid
> before we commit this patch, especially when it has the possibility of
> cause node startup to fail on purpose.  But that should be a discussion for
> the ticket I think, not for this thread.
>
> So I think we are back to the original question.  Should ACCP be used by
> default in trunk.  From what I have seen I do not see anyone who is against
> that?
>
> -Jeremiah
>
>
> On Jul 26, 2023 at 2:53:02 PM, Jordan West  wrote:
>
>> +1 Scott. And agreed all involved are looking out for the best interests
>> of C* users. And I appreciate those with concerns contributing to
>> addressing them.
>>
>> I’m all for making upgrades smooth bc I do them so often. A huge portion
>> of our 4.1 qualification is “will it break on upgrade”? Because of that I’m
>> confident in this patch and concerned about many other areas. I think it’s
>> commedable to want to reach a point where teams have the trust in the
>> community to have done that for them but that starts w better test coverage
>> and concrete evidence.
>>
>> Given all that, I think we should move forward w Ayushi’s proposal to
>> make it on by default.
>>
>> Jordan
>>
>> On Wed, Jul 26, 2023 at 12:14 C. Scott Andreas 
>> wrote:
>>
>>> I think these concerns are well-intended, but they feel rooted in
>>> uncertainty rather than in factual examples of areas where risk is present.
>>> I would appreciate elaboration on the specific areas of risk that folks
>>> imagine.
>>>
>>> I would encourage those who express skepticism to try the patch, and I
>>> endorse Ayushi's proposal to enable it by default.
>>>
>>>
>>> – Scott
>>>
>>> On Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" <
>>> stefan.mikloso...@netapp.com> wrote:
>>>
>>>
>>> We can make it opt-in, wait one major to see what bugs pop up and we
>>> might do that opt-out eventually. We do not need to hurry up with this. I
>>> understand everybody's expectations and excitement but it really boils down
>>> to one line change in yaml. People who are so much after the performance
>>> will be definitely aware of this knob to turn on to squeeze even more perf
>>> ...
>>>
>>> I look around dtests Jeremiah mentioned but I would just moved on and
>>> make it opt-in if we are not 100% persuaded about it _yet_.
>>>
>>> 
>>> From: Mick Semb Wever 
>>> Sent: Wednesday, July 26, 2023 20:48
>>> To: dev@cassandra.apache.org
>>> 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.
>>>
>>>
>>>
>>>
>>> What comes to mind is how we brought down people clusters and made
>>> sstables unreadable with the introduction of the chunk_length configuration
>>> in 1.0. It wasn't about how tested the compression libraries were, but
>>> about the new configuration itself. Introducing silent defaults has more
>>> surface area for bugs than introducing explicit defaults that only apply to
>>> new clusters and are so opt-in for existing clusters.
>>>
>>>
>>>
>>> On Wed, 26 Jul 2023 at 20:13, J. D. Jordan >> <mailto:jeremiah.jor...@gmail.com>> wrote:
>>> Enabling ssl for the upgrade dtests would cover this use case. If those
>>> don’t currently exist I see no reason it won’t work so I would be fine for
>>> someone to figure it out post merge if there is a concern. What JCE
>>> provider you use should have no upgrade concerns.
>>>
>>

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

[Jeremiah Jordan]

I had a discussion with Mick on slack.  His concern is not with enabling
ACCP.  His concern is around the testing of the new C* yaml config code
which is included in the patch that is used to decide if ACCP should be
enabled or not, and if startup should fail if it can’t be enabled.

I agree.  We should make sure that the new C* yaml config code is solid
before we commit this patch, especially when it has the possibility of
cause node startup to fail on purpose.  But that should be a discussion for
the ticket I think, not for this thread.

So I think we are back to the original question.  Should ACCP be used by
default in trunk.  From what I have seen I do not see anyone who is against
that?

-Jeremiah


On Jul 26, 2023 at 2:53:02 PM, Jordan West  wrote:

> +1 Scott. And agreed all involved are looking out for the best interests
> of C* users. And I appreciate those with concerns contributing to
> addressing them.
>
> I’m all for making upgrades smooth bc I do them so often. A huge portion
> of our 4.1 qualification is “will it break on upgrade”? Because of that I’m
> confident in this patch and concerned about many other areas. I think it’s
> commedable to want to reach a point where teams have the trust in the
> community to have done that for them but that starts w better test coverage
> and concrete evidence.
>
> Given all that, I think we should move forward w Ayushi’s proposal to make
> it on by default.
>
> Jordan
>
> On Wed, Jul 26, 2023 at 12:14 C. Scott Andreas 
> wrote:
>
>> I think these concerns are well-intended, but they feel rooted in
>> uncertainty rather than in factual examples of areas where risk is present.
>> I would appreciate elaboration on the specific areas of risk that folks
>> imagine.
>>
>> I would encourage those who express skepticism to try the patch, and I
>> endorse Ayushi's proposal to enable it by default.
>>
>>
>> – Scott
>>
>> On Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" <
>> stefan.mikloso...@netapp.com> wrote:
>>
>>
>> We can make it opt-in, wait one major to see what bugs pop up and we
>> might do that opt-out eventually. We do not need to hurry up with this. I
>> understand everybody's expectations and excitement but it really boils down
>> to one line change in yaml. People who are so much after the performance
>> will be definitely aware of this knob to turn on to squeeze even more perf
>> ...
>>
>> I look around dtests Jeremiah mentioned but I would just moved on and
>> make it opt-in if we are not 100% persuaded about it _yet_.
>>
>> 
>> From: Mick Semb Wever 
>> Sent: Wednesday, July 26, 2023 20:48
>> To: dev@cassandra.apache.org
>> 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.
>>
>>
>>
>>
>> What comes to mind is how we brought down people clusters and made
>> sstables unreadable with the introduction of the chunk_length configuration
>> in 1.0. It wasn't about how tested the compression libraries were, but
>> about the new configuration itself. Introducing silent defaults has more
>> surface area for bugs than introducing explicit defaults that only apply to
>> new clusters and are so opt-in for existing clusters.
>>
>>
>>
>> On Wed, 26 Jul 2023 at 20:13, J. D. Jordan > <mailto:jeremiah.jor...@gmail.com>> wrote:
>> Enabling ssl for the upgrade dtests would cover this use case. If those
>> don’t currently exist I see no reason it won’t work so I would be fine for
>> someone to figure it out post merge if there is a concern. What JCE
>> provider you use should have no upgrade concerns.
>>
>> -Jeremiah
>>
>> On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan <
>> stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote:
>>
>> Am I understanding it correctly that tests you are talking about are
>> only required in case we make ACCP to be default provider?
>>
>> I can live with not making it default and still deliver it if tests are
>> not required. I do not think that these kind of tests were required couple
>> mails ago when opt-in was on the table.
>>
>> While I tend to agree with people here who seem to consider testing this
>> scenario to be unnecessary exercise, I am afraid that I will not be able to
>> deliver that as testing something like this is quite complicated matter.
>> There is a lot of aspects which could be

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

[Jordan West]

+1 Scott. And agreed all involved are looking out for the best interests of
C* users. And I appreciate those with concerns contributing to addressing
them.

I’m all for making upgrades smooth bc I do them so often. A huge portion of
our 4.1 qualification is “will it break on upgrade”? Because of that I’m
confident in this patch and concerned about many other areas. I think it’s
commedable to want to reach a point where teams have the trust in the
community to have done that for them but that starts w better test coverage
and concrete evidence.

Given all that, I think we should move forward w Ayushi’s proposal to make
it on by default.

Jordan

On Wed, Jul 26, 2023 at 12:14 C. Scott Andreas  wrote:

> I think these concerns are well-intended, but they feel rooted in
> uncertainty rather than in factual examples of areas where risk is present.
> I would appreciate elaboration on the specific areas of risk that folks
> imagine.
>
> I would encourage those who express skepticism to try the patch, and I
> endorse Ayushi's proposal to enable it by default.
>
>
> – Scott
>
> On Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" <
> stefan.mikloso...@netapp.com> wrote:
>
>
> We can make it opt-in, wait one major to see what bugs pop up and we might
> do that opt-out eventually. We do not need to hurry up with this. I
> understand everybody's expectations and excitement but it really boils down
> to one line change in yaml. People who are so much after the performance
> will be definitely aware of this knob to turn on to squeeze even more perf
> ...
>
> I look around dtests Jeremiah mentioned but I would just moved on and make
> it opt-in if we are not 100% persuaded about it _yet_.
>
> 
> From: Mick Semb Wever 
> Sent: Wednesday, July 26, 2023 20:48
> To: dev@cassandra.apache.org
> 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.
>
>
>
>
> What comes to mind is how we brought down people clusters and made
> sstables unreadable with the introduction of the chunk_length configuration
> in 1.0. It wasn't about how tested the compression libraries were, but
> about the new configuration itself. Introducing silent defaults has more
> surface area for bugs than introducing explicit defaults that only apply to
> new clusters and are so opt-in for existing clusters.
>
>
>
> On Wed, 26 Jul 2023 at 20:13, J. D. Jordan  <mailto:jeremiah.jor...@gmail.com>> wrote:
> Enabling ssl for the upgrade dtests would cover this use case. If those
> don’t currently exist I see no reason it won’t work so I would be fine for
> someone to figure it out post merge if there is a concern. What JCE
> provider you use should have no upgrade concerns.
>
> -Jeremiah
>
> On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com<mailto:stefan.mikloso...@netapp.com>> wrote:
>
> Am I understanding it correctly that tests you are talking about are only
> required in case we make ACCP to be default provider?
>
> I can live with not making it default and still deliver it if tests are
> not required. I do not think that these kind of tests were required couple
> mails ago when opt-in was on the table.
>
> While I tend to agree with people here who seem to consider testing this
> scenario to be unnecessary exercise, I am afraid that I will not be able to
> deliver that as testing something like this is quite complicated matter.
> There is a lot of aspects which could be tested I can not even enumerate
> right now ... so I try to meet you somewhere in the middle.
>
> 
> From: Mick Semb Wever mailto:m...@apache.org>>
> Sent: Wednesday, July 26, 2023 17:34
> To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>
> 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.
>
>
>
>
>
> Can you say more about the shape of your concern?
>
>
> Integration testing where some nodes are running JCE and others accp, and
> various configurations that are and are not accp compatible/native.
>
> I'm not referring to (re-) unit testing accp or jce themselves, or matrix
> testing over them, but our commitment to always-on upgrades against all
> possible configurations that integrate. We've history with config changes
> breaking upgrades, for as simple as they are.
>
>
>
>

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

[C. Scott Andreas]

I think these concerns are well-intended, but they feel rooted in uncertainty rather than in factual examples of areas where risk is present. I 
would appreciate elaboration on the specific areas of risk that folks imagine.I would encourage those who express skepticism to try the patch, 
and I endorse Ayushi's proposal to enable it by default.– ScottOn Jul 26, 2023, at 12:03 PM, "Miklosovic, Stefan" 
 wrote:We can make it opt-in, wait one major to see what bugs pop up and we might do that opt-out 
eventually. We do not need to hurry up with this. I understand everybody's expectations and excitement but it really boils down to one line 
change in yaml. People who are so much after the performance will be definitely aware of this knob to turn on to squeeze even more perf ...I 
look around dtests Jeremiah mentioned but I would just moved on and make it opt-in if we are not 100% persuaded about it 
_yet_.From: Mick Semb Wever Sent: Wednesday, July 26, 2023 20:48To: 
dev@cassandra.apache.orgSubject: Re: [DISCUSS] Using ACCP or tc-native by defaultNetApp 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.What comes to mind is how we brought down people 
clusters and made sstables unreadable with the introduction of the chunk_length configuration in 1.0.  It wasn't about how tested the 
compression libraries were, but about the new configuration itself.  Introducing silent defaults has more surface area for bugs than 
introducing explicit defaults that only apply to new clusters and are so opt-in for existing clusters.On Wed, 26 Jul 2023 at 20:13, J. D. 
Jordan mailto:jeremiah.jor...@gmail.com>> wrote:Enabling ssl for the upgrade dtests would cover this use 
case. If those don’t currently exist I see no reason it won’t work so I would be fine for someone to figure it out post merge if there is a 
concern.  What JCE provider you use should have no upgrade concerns.-JeremiahOn Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan 
mailto:stefan.mikloso...@netapp.com>> wrote:Am I understanding it correctly that tests you are 
talking about are only required in case we make ACCP to be default provider?I can live with not making it default and still deliver it if tests 
are not required. I do not think that these kind of tests were required couple mails ago when opt-in was on the table.While I tend to agree 
with people here who seem to consider testing this scenario to be unnecessary exercise, I am afraid that I will not be able to deliver that as 
testing something like this is quite complicated matter. There is a lot of aspects which could be tested I can not even enumerate right now ... 
so I try to meet you somewhere in the middle.From: Mick Semb Wever 
mailto:m...@apache.org>>Sent: Wednesday, July 26, 2023 17:34To: 
dev@cassandra.apache.orgSubject: Re: [DISCUSS] Using ACCP or tc-native by defaultNetApp 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.Can you 
say more about the shape of your concern?Integration testing where some nodes are running JCE and others accp, and various configurations that 
are and are not accp compatible/native.I'm not referring to (re-) unit testing accp or jce themselves, or matrix testing over them, but our 
commitment to always-on upgrades against all possible configurations that integrate.  We've history with config changes breaking upgrades, for 
as simple as they are.

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

[Miklosovic, Stefan]

We can make it opt-in, wait one major to see what bugs pop up and we might do 
that opt-out eventually. We do not need to hurry up with this. I understand 
everybody's expectations and excitement but it really boils down to one line 
change in yaml. People who are so much after the performance will be definitely 
aware of this knob to turn on to squeeze even more perf ...

I look around dtests Jeremiah mentioned but I would just moved on and make it 
opt-in if we are not 100% persuaded about it _yet_.


From: Mick Semb Wever 
Sent: Wednesday, July 26, 2023 20:48
To: dev@cassandra.apache.org
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.




What comes to mind is how we brought down people clusters and made sstables 
unreadable with the introduction of the chunk_length configuration in 1.0.  It 
wasn't about how tested the compression libraries were, but about the new 
configuration itself.  Introducing silent defaults has more surface area for 
bugs than introducing explicit defaults that only apply to new clusters and are 
so opt-in for existing clusters.



On Wed, 26 Jul 2023 at 20:13, J. D. Jordan 
mailto:jeremiah.jor...@gmail.com>> wrote:
Enabling ssl for the upgrade dtests would cover this use case. If those don’t 
currently exist I see no reason it won’t work so I would be fine for someone to 
figure it out post merge if there is a concern.  What JCE provider you use 
should have no upgrade concerns.

-Jeremiah

> On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan 
> mailto:stefan.mikloso...@netapp.com>> wrote:
>
> Am I understanding it correctly that tests you are talking about are only 
> required in case we make ACCP to be default provider?
>
> I can live with not making it default and still deliver it if tests are not 
> required. I do not think that these kind of tests were required couple mails 
> ago when opt-in was on the table.
>
> While I tend to agree with people here who seem to consider testing this 
> scenario to be unnecessary exercise, I am afraid that I will not be able to 
> deliver that as testing something like this is quite complicated matter. 
> There is a lot of aspects which could be tested I can not even enumerate 
> right now ... so I try to meet you somewhere in the middle.
>
> 
> From: Mick Semb Wever mailto:m...@apache.org>>
> Sent: Wednesday, July 26, 2023 17:34
> To: dev@cassandra.apache.org<mailto:dev@cassandra.apache.org>
> 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.
>
>
>
>
>
> Can you say more about the shape of your concern?
>
>
> Integration testing where some nodes are running JCE and others accp, and 
> various configurations that are and are not accp compatible/native.
>
> I'm not referring to (re-) unit testing accp or jce themselves, or matrix 
> testing over them, but our commitment to always-on upgrades against all 
> possible configurations that integrate.  We've history with config changes 
> breaking upgrades, for as simple as they are.

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

[Mick Semb Wever]

What comes to mind is how we brought down people clusters and made sstables
unreadable with the introduction of the chunk_length configuration in 1.0.
It wasn't about how tested the compression libraries were, but about the
new configuration itself.  Introducing silent defaults has more surface
area for bugs than introducing explicit defaults that only apply to new
clusters and are so opt-in for existing clusters.



On Wed, 26 Jul 2023 at 20:13, J. D. Jordan 
wrote:

> Enabling ssl for the upgrade dtests would cover this use case. If those
> don’t currently exist I see no reason it won’t work so I would be fine for
> someone to figure it out post merge if there is a concern.  What JCE
> provider you use should have no upgrade concerns.
>
> -Jeremiah
>
> > On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan <
> stefan.mikloso...@netapp.com> wrote:
> >
> > Am I understanding it correctly that tests you are talking about are
> only required in case we make ACCP to be default provider?
> >
> > I can live with not making it default and still deliver it if tests are
> not required. I do not think that these kind of tests were required couple
> mails ago when opt-in was on the table.
> >
> > While I tend to agree with people here who seem to consider testing this
> scenario to be unnecessary exercise, I am afraid that I will not be able to
> deliver that as testing something like this is quite complicated matter.
> There is a lot of aspects which could be tested I can not even enumerate
> right now ... so I try to meet you somewhere in the middle.
> >
> > 
> > From: Mick Semb Wever 
> > Sent: Wednesday, July 26, 2023 17:34
> > To: dev@cassandra.apache.org
> > 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.
> >
> >
> >
> >
> >
> > Can you say more about the shape of your concern?
> >
> >
> > Integration testing where some nodes are running JCE and others accp,
> and various configurations that are and are not accp compatible/native.
> >
> > I'm not referring to (re-) unit testing accp or jce themselves, or
> matrix testing over them, but our commitment to always-on upgrades against
> all possible configurations that integrate.  We've history with config
> changes breaking upgrades, for as simple as they are.
>

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

[J. D. Jordan]

Enabling ssl for the upgrade dtests would cover this use case. If those don’t 
currently exist I see no reason it won’t work so I would be fine for someone to 
figure it out post merge if there is a concern.  What JCE provider you use 
should have no upgrade concerns.

-Jeremiah

> On Jul 26, 2023, at 1:07 PM, Miklosovic, Stefan 
>  wrote:
> 
> Am I understanding it correctly that tests you are talking about are only 
> required in case we make ACCP to be default provider?
> 
> I can live with not making it default and still deliver it if tests are not 
> required. I do not think that these kind of tests were required couple mails 
> ago when opt-in was on the table.
> 
> While I tend to agree with people here who seem to consider testing this 
> scenario to be unnecessary exercise, I am afraid that I will not be able to 
> deliver that as testing something like this is quite complicated matter. 
> There is a lot of aspects which could be tested I can not even enumerate 
> right now ... so I try to meet you somewhere in the middle.
> 
> 
> From: Mick Semb Wever 
> Sent: Wednesday, July 26, 2023 17:34
> To: dev@cassandra.apache.org
> 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.
> 
> 
> 
> 
> 
> Can you say more about the shape of your concern?
> 
> 
> Integration testing where some nodes are running JCE and others accp, and 
> various configurations that are and are not accp compatible/native.
> 
> I'm not referring to (re-) unit testing accp or jce themselves, or matrix 
> testing over them, but our commitment to always-on upgrades against all 
> possible configurations that integrate.  We've history with config changes 
> breaking upgrades, for as simple as they are.

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

[Miklosovic, Stefan]

Am I understanding it correctly that tests you are talking about are only 
required in case we make ACCP to be default provider?

I can live with not making it default and still deliver it if tests are not 
required. I do not think that these kind of tests were required couple mails 
ago when opt-in was on the table.

While I tend to agree with people here who seem to consider testing this 
scenario to be unnecessary exercise, I am afraid that I will not be able to 
deliver that as testing something like this is quite complicated matter. There 
is a lot of aspects which could be tested I can not even enumerate right now 
... so I try to meet you somewhere in the middle.


From: Mick Semb Wever 
Sent: Wednesday, July 26, 2023 17:34
To: dev@cassandra.apache.org
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.





Can you say more about the shape of your concern?


Integration testing where some nodes are running JCE and others accp, and 
various configurations that are and are not accp compatible/native.

I'm not referring to (re-) unit testing accp or jce themselves, or matrix 
testing over them, but our commitment to always-on upgrades against all 
possible configurations that integrate.  We've history with config changes 
breaking upgrades, for as simple as they are.

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

[Jordan West]

We do and I’m sensitive to that 100% but there is no reason ACCP should
break upgrades afaik. The algorithms it implements are identical and for
the ones it doesn’t the JRE implementation is used — ACCP is the higher
priority implementation. Do we have any examples of it breaking anything?
Or that it’s problematic?

We recently did a 4.1 upgrade that was mixed JRE / ACCP and it worked fine.
It’s how we figured out ACCP was missing because 4.1 was noticeably slower
(graph in JIRA) and the JRE crypto library dominated the flamegraph (can
try to dig up a screenshot maybe).

Jordan

On Wed, Jul 26, 2023 at 08:35 Mick Semb Wever  wrote:

>
>
> Can you say more about the shape of your concern?
>>
>
>
> Integration testing where some nodes are running JCE and others accp, and
> various configurations that are and are not accp compatible/native.
>
> I'm not referring to (re-) unit testing accp or jce themselves, or matrix
> testing over them, but our commitment to always-on upgrades against all
> possible configurations that integrate.  We've history with config changes
> breaking upgrades, for as simple as they are.
>

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

[Mick Semb Wever]

Can you say more about the shape of your concern?
>


Integration testing where some nodes are running JCE and others accp, and
various configurations that are and are not accp compatible/native.

I'm not referring to (re-) unit testing accp or jce themselves, or matrix
testing over them, but our commitment to always-on upgrades against all
possible configurations that integrate.  We've history with config changes
breaking upgrades, for as simple as they are.

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

[Jordan West]

I left my comments on the JIRA itself but generally they mirror Scott and
Joeys thoughts.

Jordan

On Wed, Jul 26, 2023 at 07:26 C. Scott Andreas  wrote:

> Peter, thanks for your message.
>
> You are receiving these emails because your address is subscribed to the
> Apache Cassandra "dev@" developer mailing list. You can unsubscribe from
> this list by sending an email to dev-unsubscr...@cassandra.apache.org.
> Subscribers to the mailing list are not able to take this action on others'
> behalf.
>
> More information on the project's mailing lists and how to join/leave them
> is here: https://cassandra.apache.org/_/community.html
>
> Cheers,
>
> – Scott
>
> On Jul 26, 2023, at 7:11 AM, C. Scott Andreas 
> wrote:
>
>
> Can you say more about the shape of your concern?
>
> JCA/JCE conformance and correctness of the functions implemented are a
> responsibility of the ACCP/Corretto test suite (link
> ).
> These are thoroughly exercised by Amazon and bundled into the Corretto JDK
> distribution Amazon ships as well.
>
> With regard to Cassandra, the hash and cryptographic functions utilized in
> ACCP are also thoroughly exercised by Cassandra’s unit and in-JVM dtest
> suite.
>
> I wouldn’t propose fragmenting our build into a matrix of JDK x arch x
> ACCP/no, in the same way that we wouldn’t for tcnative vs. not.
>
> - Scott
>
> On Jul 26, 2023, at 6:48 AM, Mick Semb Wever  wrote:
>
> 
>
>> So if a service is not there it will just search where it is next. I
>> completely forgot this aspect of it ... Folks from Corretto forgot to
>> mention this behavior as well, interesting. It is not as we are going to
>> use this _as the only provider_.
>>
>
>
> I'm still uncomfortable assuming upgrades work without having the
> appropriate tests in place.  That's the crux for me.  Existing JCE tests
> (with and without accp) should cover this?
>
>
>

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

[C. Scott Andreas]

Peter, thanks for your message.You are receiving these emails because your address is subscribed to 
the Apache Cassandra "dev@" developer mailing list. You can unsubscribe from this list by 
sending an email to dev-unsubscr...@cassandra.apache.org. Subscribers to the mailing list are not 
able to take this action on others' behalf.More information on the project's mailing lists and how to 
join/leave them is here: https://cassandra.apache.org/_/community.htmlCheers,– ScottOn Jul 26, 2023, 
at 7:11 AM, C. Scott Andreas  wrote:Can you say more about the shape of 
your concern?JCA/JCE conformance and correctness of the functions implemented are a responsibility of 
the ACCP/Corretto test suite (link). These are thoroughly exercised by Amazon and bundled into the 
Corretto JDK distribution Amazon ships as well.With regard to Cassandra, the hash and cryptographic 
functions utilized in ACCP are also thoroughly exercised by Cassandra’s unit and in-JVM dtest suite.I 
wouldn’t propose fragmenting our build into a matrix of JDK x arch x ACCP/no, in the same way that we 
wouldn’t for tcnative vs. not.- ScottOn Jul 26, 2023, at 6:48 AM, Mick Semb Wever 
 wrote:So if a service is not there it will just search where it is next. I 
completely forgot this aspect of it ... Folks from Corretto forgot to mention this behavior as well, 
interesting. It is not as we are going to use this _as the only provider_.I'm still uncomfortable 
assuming upgrades work without having the appropriate tests in place.  That's the crux for me.  
Existing JCE tests (with and without accp) should cover this?

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

[C. Scott Andreas]

Can you say more about the shape of your concern?JCA/JCE conformance and correctness of the functions implemented are a responsibility of the ACCP/Corretto test suite (link). These are thoroughly exercised by Amazon and bundled into the Corretto JDK distribution Amazon ships as well.With regard to Cassandra, the hash and cryptographic functions utilized in ACCP are also thoroughly exercised by Cassandra’s unit and in-JVM dtest suite.I wouldn’t propose fragmenting our build into a matrix of JDK x arch x ACCP/no, in the same way that we wouldn’t for tcnative vs. not.- ScottOn Jul 26, 2023, at 6:48 AM, Mick Semb Wever  wrote:So if a service is not there it will just search where it is next. I completely forgot this aspect of it ... Folks from Corretto forgot to mention this behavior as well, interesting. It is not as we are going to use this _as the only provider_.I'm still uncomfortable assuming upgrades work without having the appropriate tests in place.  That's the crux for me.  Existing JCE tests (with and without accp) should cover this?

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

[Mick Semb Wever]

>
> So if a service is not there it will just search where it is next. I
> completely forgot this aspect of it ... Folks from Corretto forgot to
> mention this behavior as well, interesting. It is not as we are going to
> use this _as the only provider_.
>


I'm still uncomfortable assuming upgrades work without having the
appropriate tests in place.  That's the crux for me.  Existing JCE tests
(with and without accp) should cover this?

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

[Miklosovic, Stefan]

Yes, you are right. I know the providers have their preference and we are 
installing Corretto as the first one.

So if a service is not there it will just search where it is next. I completely 
forgot this aspect of it ... Folks from Corretto forgot to mention this 
behavior as well, interesting. It is not as we are going to use this _as the 
only provider_.

In that case I think we can set it as default.

We just need to be cautious to not use e.g Cipher.getInstance("algorithm", 
"provider") - provider being "AmazonCorrettoCryptoProvider" or anything like 
that. In other words, as long as we are not specifying a concrete provider to 
get an instance from, we should be safe. I looked over the codebase and we are 
not using it anywhere.


From: J. D. Jordan 
Sent: Wednesday, July 26, 2023 14:32
To: dev@cassandra.apache.org
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.



I thought the crypto providers were supposed to “ask the next one down the 
line” if something is not supported?  Have you tried some unsupported thing and 
seen it break?  My understanding of the providers being an ordered list was 
that isn’t supposed to happen.

-Jeremiah

On Jul 26, 2023, at 3:23 AM, Mick Semb Wever  wrote:






That means that if somebody is on 4.0 and they upgrade to 5.0, if they use some 
ciphers / protocols / algorithms which are not in Corretto, it might break 
their upgrade.



If there's any risk of breaking upgrades we have to go with (2).  We support a 
variation of JCE configurations, and I don't see we have the test coverage in 
place to de-risk it other than going with (2).

Once the yaml configuration is in place we can then change the default in the 
next major version 6.0.

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

[Peter George]

PLEASE REMOVE ME FROM THIS EMAIL



From: "C. Scott Andreas" 
Reply-To: "dev@cassandra.apache.org" 
Date: Wednesday, July 26, 2023 at 6:19 AM
To: "dev@cassandra.apache.org" 
Subject: Re: [DISCUSS] Using ACCP or tc-native by default

Jeremiah, that’s my understanding as well. ACCP accelerates a subset of 
functions and delegates the rest.

In years of using ACCP with Cassandra, I have yet to see an issue - or any case 
in which adopting ACCP was anything other than a strict benefit.

- Scott


On Jul 26, 2023, at 5:33 AM, J. D. Jordan  wrote:
I thought the crypto providers were supposed to “ask the next one down the 
line” if something is not supported?  Have you tried some unsupported thing and 
seen it break?  My understanding of the providers being an ordered list was 
that isn’t supposed to happen.

-Jeremiah


On Jul 26, 2023, at 3:23 AM, Mick Semb Wever  wrote:




That means that if somebody is on 4.0 and they upgrade to 5.0, if they use some 
ciphers / protocols / algorithms which are not in Corretto, it might break 
their upgrade.



If there's any risk of breaking upgrades we have to go with (2).  We support a 
variation of JCE configurations, and I don't see we have the test coverage in 
place to de-risk it other than going with (2).

Once the yaml configuration is in place we can then change the default in the 
next major version 6.0.

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

[C. Scott Andreas]

Jeremiah, that’s my understanding as well. ACCP accelerates a subset of 
functions and delegates the rest.

In years of using ACCP with Cassandra, I have yet to see an issue - or any case 
in which adopting ACCP was anything other than a strict benefit.

- Scott

> On Jul 26, 2023, at 5:33 AM, J. D. Jordan  wrote:
> 
> 
> I thought the crypto providers were supposed to “ask the next one down the 
> line” if something is not supported?  Have you tried some unsupported thing 
> and seen it break?  My understanding of the providers being an ordered list 
> was that isn’t supposed to happen.
> 
> -Jeremiah
> 
>>> On Jul 26, 2023, at 3:23 AM, Mick Semb Wever  wrote:
>>> 
>> 
>> 
>> 
>>  
>> 
>>> That means that if somebody is on 4.0 and they upgrade to 5.0, if they use 
>>> some ciphers / protocols / algorithms which are not in Corretto, it might 
>>> break their upgrade.
>> 
>> 
>> 
>> If there's any risk of breaking upgrades we have to go with (2).  We support 
>> a variation of JCE configurations, and I don't see we have the test coverage 
>> in place to de-risk it other than going with (2).  
>> 
>> Once the yaml configuration is in place we can then change the default in 
>> the next major version 6.0.
>> 
>> 

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

[J. D. Jordan]

I thought the crypto providers were supposed to “ask the next one down the 
line” if something is not supported?  Have you tried some unsupported thing and 
seen it break?  My understanding of the providers being an ordered list was 
that isn’t supposed to happen.

-Jeremiah

> On Jul 26, 2023, at 3:23 AM, Mick Semb Wever  wrote:
> 
> 
> 
> 
>  
> 
>> That means that if somebody is on 4.0 and they upgrade to 5.0, if they use 
>> some ciphers / protocols / algorithms which are not in Corretto, it might 
>> break their upgrade.
> 
> 
> 
> If there's any risk of breaking upgrades we have to go with (2).  We support 
> a variation of JCE configurations, and I don't see we have the test coverage 
> in place to de-risk it other than going with (2).  
> 
> Once the yaml configuration is in place we can then change the default in the 
> next major version 6.0.
> 
> 

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

[Mick Semb Wever]

That means that if somebody is on 4.0 and they upgrade to 5.0, if they use
> some ciphers / protocols / algorithms which are not in Corretto, it might
> break their upgrade.
>



If there's any risk of breaking upgrades we have to go with (2).  We
support a variation of JCE configurations, and I don't see we have the test
coverage in place to de-risk it other than going with (2).

Once the yaml configuration is in place we can then change the default in
the next major version 6.0.

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

[Miklosovic, Stefan]

Hi,

we need to be on the same page here and this is crucial to get right.

We evaluated that Corretto is a subset of what is in SunJCE provider (bundled 
in JRE). It is not true that Corretto is just "a drop-in replacement". That 
means that if somebody is on 4.0 and they upgrade to 5.0, if they use some 
ciphers / protocols / algorithms which are not in Corretto, it might break 
their upgrade.

I asked Corretto team here (1) and they told that is truly a subset of what is 
in JCE and the diff is relatively large. There is also enumeration of all 
services in Corretto and default provider so we can see the difference.

On the other hand, they say that services which are considered "weak" are not 
there so by moving to Corretto, we are actually making Cassandra safer but as I 
mentioned the cost is that we will drop the support of all other stuff and we 
might break things.

So, with all this information we have two choices:

1) to make Corretto default and make it opt-out
2) to not make Corretto default and make it opt-in

Jordan's opinion is added as the last comment in (2)

What is the preference of the community? We need to be sure we are aligned here.

(1) https://github.com/corretto/amazon-corretto-crypto-provider/issues/315
(2) https://issues.apache.org/jira/browse/CASSANDRA-18624


From: Miklosovic, Stefan 
Sent: Friday, July 21, 2023 18:17
To: dev@cassandra.apache.org
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.




We gave it the second look and I came up with this (1)

In a nutshell, we download both arch libs to libs/corretto and then 
cassandra.in.sh will dynamically resolve the architecture and OS. Based on 
that, it will add respective jar to the class path. If it went wrong and it is 
not added to CP, we just skip the installation / healthchecks as if nothing 
happened (by default).

We are also adding the dependency to Maven's pom.xml based on the architecture 
the build is invoked on so there is a possibility to create 
architecture-specific artifact. This is achieved by Maven profiles which are 
activated based on what architecture it is run.

Hence, we covered both aspects, Maven build / dependencies as well as runtime 
library resolution.

There is also flag added, "fail_on_missing_provider", which is by default 
false, if set to true, in case it was not on CP or if we by mistake installed 
different architecture, it will fail the startup.

We could definitely use some review here, especially from people who run on ARM 
so we are sure that it works there as well as intended.

(1) https://github.com/apache/cassandra/pull/2505/files


From: Mick Semb Wever 
Sent: Friday, July 21, 2023 7:18
To: dev@cassandra.apache.org
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.



As I am on x86 and I wanted to simulate what would happen to users on ARM, I 
just did it other way around - I introduced the dependency with classifier 
linux-aarch_64.

…
Surprisingly, the installation step succeeded on x86 even the dependency was 
for aarch. However, the startup check went to else branch (2) and I saw that 
the provider was not Corretto provider but the default - SunJCE. So that tells 
me that it basically falls back to the default which is what we want.


I raised concerns about this because we have no other dependencies that use the 
classifier in the pom file to bind us to a particular arch.  The loading of the 
native code isn't my concern.

I'm uneasy (without further investigation) with publishing cassandra pom files 
that classify us to " x86_64".  For example, how the jar files differ between 
classifiers for this project.

I'm also curious if there's a way to bundle the native files for all arch, like 
we do for other libraries, with runtime just loading what's correct.

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

[Miklosovic, Stefan]

We gave it the second look and I came up with this (1)

In a nutshell, we download both arch libs to libs/corretto and then 
cassandra.in.sh will dynamically resolve the architecture and OS. Based on 
that, it will add respective jar to the class path. If it went wrong and it is 
not added to CP, we just skip the installation / healthchecks as if nothing 
happened (by default).

We are also adding the dependency to Maven's pom.xml based on the architecture 
the build is invoked on so there is a possibility to create 
architecture-specific artifact. This is achieved by Maven profiles which are 
activated based on what architecture it is run.

Hence, we covered both aspects, Maven build / dependencies as well as runtime 
library resolution.

There is also flag added, "fail_on_missing_provider", which is by default 
false, if set to true, in case it was not on CP or if we by mistake installed 
different architecture, it will fail the startup.

We could definitely use some review here, especially from people who run on ARM 
so we are sure that it works there as well as intended.

(1) https://github.com/apache/cassandra/pull/2505/files


From: Mick Semb Wever 
Sent: Friday, July 21, 2023 7:18
To: dev@cassandra.apache.org
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.



As I am on x86 and I wanted to simulate what would happen to users on ARM, I 
just did it other way around - I introduced the dependency with classifier 
linux-aarch_64.

…
Surprisingly, the installation step succeeded on x86 even the dependency was 
for aarch. However, the startup check went to else branch (2) and I saw that 
the provider was not Corretto provider but the default - SunJCE. So that tells 
me that it basically falls back to the default which is what we want.


I raised concerns about this because we have no other dependencies that use the 
classifier in the pom file to bind us to a particular arch.  The loading of the 
native code isn't my concern.

I'm uneasy (without further investigation) with publishing cassandra pom files 
that classify us to " x86_64".  For example, how the jar files differ between 
classifiers for this project.

I'm also curious if there's a way to bundle the native files for all arch, like 
we do for other libraries, with runtime just loading what's correct.

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

[Mick Semb Wever]

>
> As I am on x86 and I wanted to simulate what would happen to users on ARM,
> I just did it other way around - I introduced the dependency with
> classifier linux-aarch_64.
>
> …
> Surprisingly, the installation step succeeded on x86 even the dependency
> was for aarch. However, the startup check went to else branch (2) and I saw
> that the provider was not Corretto provider but the default - SunJCE. So
> that tells me that it basically falls back to the default which is what we
> want.
>


I raised concerns about this because we have no other dependencies that use
the classifier in the pom file to bind us to a particular arch.  The
loading of the native code isn't my concern.

I'm uneasy (without further investigation) with publishing cassandra pom
files that classify us to " x86_64".  For example, how the jar files differ
between classifiers for this project.

I'm also curious if there's a way to bundle the native files for all arch,
like we do for other libraries, with runtime just loading what's correct.

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

[Nate McCall]

On Fri, Jul 21, 2023 at 10:56 AM Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:
...

> I think this might work, if it is available, it will use it, if not, we
> emit a big fat warning.
>
...

I agree with this approach. It lets operators trap a log statement or
similar while defaulting to the fastest most-common path when available.

-Nate

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

[Miklosovic, Stefan]

Thank you all for your opinions. Very appreciated.

I finally got some time to play with the patch of Ayushi Singh.

As I am on x86 and I wanted to simulate what would happen to users on ARM, I 
just did it other way around - I introduced the dependency with classifier 
linux-aarch_64.

The whole setup of that crypto provider consists of two steps. The first is the 
"installation". The second the is the "verification / check" that it is 
installed correctly by performing a "health check".

Surprisingly, the installation step succeeded on x86 even the dependency was 
for aarch. However, the startup check went to else branch (2) and I saw that 
the provider was not Corretto provider but the default - SunJCE. So that tells 
me that it basically falls back to the default which is what we want.

I think this might work, if it is available, it will use it, if not, we emit a 
big fat warning.

We could introduce a flag into crypto_provider's "parameters" (as it is 
configured by ParameterizedClass) which would fail the startup if it is not 
installed and by default it would be turned off so for people on ARM it would 
just emit warning.

1) 
https://github.com/apache/cassandra/blob/9b0b0f03f97f0bb1d7c0295cdfa3b3da80d1c3b8/src/java/org/apache/cassandra/security/DefaultCryptoProvider.java
2) 
https://github.com/apache/cassandra/blob/9b0b0f03f97f0bb1d7c0295cdfa3b3da80d1c3b8/src/java/org/apache/cassandra/security/DefaultCryptoProvider.java#L64-L70


From: Abe Ratnofsky 
Sent: Thursday, July 20, 2023 23:59
To: dev@cassandra.apache.org
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.




This feels analogous to other past discussions around prioritizing a config 
that enables new users to clone + build + run as easily as possible, vs. having 
better prod recommendations out of the box.

Both are important. I personally think we should default configuration to make 
it just work for new users, and have a config to allow power users to fail if 
ACCP is not present, and warn once on startup if we tolerate missing ACCP but 
detect it is absent.

> On Jul 20, 2023, at 14:51, Brandon Williams  wrote:
>
> I think we could special-case and default to 'auto' but allow other
> more explicit options.
>
> Kind Regards,
> Brandon
>
>> On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev
>>  wrote:
>>
>> In general I agree with Joey -- but I would prefer if this behavior is 
>> configurable, e.g. there is an option to get a startup failure if the 
>> configured fastest provider can't run for any reason to avoid a "silent" 
>> performance degradation as Jordan was experiencing.
>>
>> Thanks,
>> German
>>
>> ________________
>> From: Joseph Lynch 
>> Sent: Thursday, July 20, 2023 7:38 AM
>> To: dev@cassandra.apache.org 
>> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
>>
>> Having native dependencies shouldn't make the project x86 only, it
>> should just accelerate the performance on x86 when available. Can't we
>> just try to load the fastest available provider (so arm will use
>> native java but x86 will use proper hardware acceleration) and failing
>> that fall-back to the default? If I recall correctly from the
>> messaging service patches (and zstd/lz4) it's reasonably
>> straightforward to try to load native code and then fail-back if you
>> fail.
>>
>> -Joey
>>
>>> On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  
>>> wrote:
>>>
>>> Maybe we could start providing Dockerfile’s and/or make arch specific 
>>> rpm/deb packages that have everything setup correctly per architecture?
>>> We could also download them all and have the startup scripts put stuff in 
>>> the right places depending on the arch of the machine running them?
>>> I feel like there are probably multiple ways we could solve this without 
>>> requiring users to jump through a bunch of hoops?
>>> But I do agree we can’t make the project x86 only.
>>>
>>> -Jeremiah
>>>
>>>> On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
>>>>  wrote:
>>>>
>>>> Hi,
>>>>
>>>> as I was reviewing the patch for this feature (1), we realized that it is 
>>>> not quite easy to bundle this directly into Cassandra.
>>>>
>>>> The problem is that this was supposed to be introduced as a new dependency:
>>>>
>>>> 
>>>>   software.amazon.cryptool

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

[Abe Ratnofsky]

This feels analogous to other past discussions around prioritizing a config 
that enables new users to clone + build + run as easily as possible, vs. having 
better prod recommendations out of the box.

Both are important. I personally think we should default configuration to make 
it just work for new users, and have a config to allow power users to fail if 
ACCP is not present, and warn once on startup if we tolerate missing ACCP but 
detect it is absent.

> On Jul 20, 2023, at 14:51, Brandon Williams  wrote:
> 
> I think we could special-case and default to 'auto' but allow other
> more explicit options.
> 
> Kind Regards,
> Brandon
> 
>> On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev
>>  wrote:
>> 
>> In general I agree with Joey -- but I would prefer if this behavior is 
>> configurable, e.g. there is an option to get a startup failure if the 
>> configured fastest provider can't run for any reason to avoid a "silent" 
>> performance degradation as Jordan was experiencing.
>> 
>> Thanks,
>> German
>> 
>> 
>> From: Joseph Lynch 
>> Sent: Thursday, July 20, 2023 7:38 AM
>> To: dev@cassandra.apache.org 
>> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
>> 
>> Having native dependencies shouldn't make the project x86 only, it
>> should just accelerate the performance on x86 when available. Can't we
>> just try to load the fastest available provider (so arm will use
>> native java but x86 will use proper hardware acceleration) and failing
>> that fall-back to the default? If I recall correctly from the
>> messaging service patches (and zstd/lz4) it's reasonably
>> straightforward to try to load native code and then fail-back if you
>> fail.
>> 
>> -Joey
>> 
>>> On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  
>>> wrote:
>>> 
>>> Maybe we could start providing Dockerfile’s and/or make arch specific 
>>> rpm/deb packages that have everything setup correctly per architecture?
>>> We could also download them all and have the startup scripts put stuff in 
>>> the right places depending on the arch of the machine running them?
>>> I feel like there are probably multiple ways we could solve this without 
>>> requiring users to jump through a bunch of hoops?
>>> But I do agree we can’t make the project x86 only.
>>> 
>>> -Jeremiah
>>> 
>>>> On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
>>>>  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> as I was reviewing the patch for this feature (1), we realized that it is 
>>>> not quite easy to bundle this directly into Cassandra.
>>>> 
>>>> The problem is that this was supposed to be introduced as a new dependency:
>>>> 
>>>> 
>>>>   software.amazon.cryptools
>>>>   AmazonCorrettoCryptoProvider
>>>>   2.2.0
>>>>   linux-x86_64
>>>> 
>>>> 
>>>> Notice "classifier". That means that if we introduced this dependency into 
>>>> the project, what about ARM users? (there is corresponding aarch 
>>>> classifier as well). ACCP is platform-specific but we have to ship 
>>>> Cassandra platform-agnostic. It just needs to run OOTB everywhere. If we 
>>>> shipped that with x86 and a user runs Cassandra on ARM, I guess that would 
>>>> break things, right?
>>>> 
>>>> We also can not just add both dependencies (both x86 and aarch) because 
>>>> how would we differentiate between them in runtime? That all is just too 
>>>> tricky / error prone.
>>>> 
>>>> So, the approach we want to take is this:
>>>> 
>>>> 1) nothing will be bundled in Cassandra by default
>>>> 2) a user is supposed to download the library and put it to the class path
>>>> 3) a user is supposed to put the implementation of ICryptoProvider 
>>>> interface Cassandra exposes to the class path
>>>> 3) a user is supposed to configure cassandra.yaml and its section 
>>>> "crypto_provider" to reference the implementation he wants
>>>> 
>>>> That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
>>>> versa.
>>>> 
>>>> By default, NoOpProvider will be used, that means that the default crypto 
>>>> provider from JRE will be used.
>>>> 
>>>> It can seem like we have not done too much p

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

[Brandon Williams]

I think we could special-case and default to 'auto' but allow other
more explicit options.

Kind Regards,
Brandon

On Thu, Jul 20, 2023 at 4:18 PM German Eichberger via dev
 wrote:
>
> In general I agree with Joey -- but I would prefer if this behavior is 
> configurable, e.g. there is an option to get a startup failure if the 
> configured fastest provider can't run for any reason to avoid a "silent" 
> performance degradation as Jordan was experiencing.
>
> Thanks,
> German
>
> 
> From: Joseph Lynch 
> Sent: Thursday, July 20, 2023 7:38 AM
> To: dev@cassandra.apache.org 
> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
>
> Having native dependencies shouldn't make the project x86 only, it
> should just accelerate the performance on x86 when available. Can't we
> just try to load the fastest available provider (so arm will use
> native java but x86 will use proper hardware acceleration) and failing
> that fall-back to the default? If I recall correctly from the
> messaging service patches (and zstd/lz4) it's reasonably
> straightforward to try to load native code and then fail-back if you
> fail.
>
> -Joey
>
> On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  
> wrote:
> >
> > Maybe we could start providing Dockerfile’s and/or make arch specific 
> > rpm/deb packages that have everything setup correctly per architecture?
> > We could also download them all and have the startup scripts put stuff in 
> > the right places depending on the arch of the machine running them?
> > I feel like there are probably multiple ways we could solve this without 
> > requiring users to jump through a bunch of hoops?
> > But I do agree we can’t make the project x86 only.
> >
> > -Jeremiah
> >
> > > On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
> > >  wrote:
> > >
> > > Hi,
> > >
> > > as I was reviewing the patch for this feature (1), we realized that it is 
> > > not quite easy to bundle this directly into Cassandra.
> > >
> > > The problem is that this was supposed to be introduced as a new 
> > > dependency:
> > >
> > > 
> > >software.amazon.cryptools
> > >AmazonCorrettoCryptoProvider
> > >2.2.0
> > >linux-x86_64
> > > 
> > >
> > > Notice "classifier". That means that if we introduced this dependency 
> > > into the project, what about ARM users? (there is corresponding aarch 
> > > classifier as well). ACCP is platform-specific but we have to ship 
> > > Cassandra platform-agnostic. It just needs to run OOTB everywhere. If we 
> > > shipped that with x86 and a user runs Cassandra on ARM, I guess that 
> > > would break things, right?
> > >
> > > We also can not just add both dependencies (both x86 and aarch) because 
> > > how would we differentiate between them in runtime? That all is just too 
> > > tricky / error prone.
> > >
> > > So, the approach we want to take is this:
> > >
> > > 1) nothing will be bundled in Cassandra by default
> > > 2) a user is supposed to download the library and put it to the class path
> > > 3) a user is supposed to put the implementation of ICryptoProvider 
> > > interface Cassandra exposes to the class path
> > > 3) a user is supposed to configure cassandra.yaml and its section 
> > > "crypto_provider" to reference the implementation he wants
> > >
> > > That way, we avoid the situation when somebody runs x86 lib on ARM or 
> > > vice versa.
> > >
> > > By default, NoOpProvider will be used, that means that the default crypto 
> > > provider from JRE will be used.
> > >
> > > It can seem like we have not done too much progress here but hey ... we 
> > > opened the project to the custom implementations of crypto providers a 
> > > community can create. E.g. as 3rd party extensions etc ...
> > >
> > > I want to be sure that everybody is aware of this change (that we plan to 
> > > do that in such a way that it will not be "bundled") and that everybody 
> > > is on board with this. Otherwise I am all ears about how to do that 
> > > differently.
> > >
> > > (1) 
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-18624=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63825460743925475

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

[German Eichberger via dev]

In general I agree with Joey -- but I would prefer if this behavior is 
configurable, e.g. there is an option to get a startup failure if the 
configured fastest provider can't run for any reason to avoid a "silent" 
performance degradation as Jordan was experiencing.

Thanks,
German


From: Joseph Lynch 
Sent: Thursday, July 20, 2023 7:38 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default

Having native dependencies shouldn't make the project x86 only, it
should just accelerate the performance on x86 when available. Can't we
just try to load the fastest available provider (so arm will use
native java but x86 will use proper hardware acceleration) and failing
that fall-back to the default? If I recall correctly from the
messaging service patches (and zstd/lz4) it's reasonably
straightforward to try to load native code and then fail-back if you
fail.

-Joey

On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  wrote:
>
> Maybe we could start providing Dockerfile’s and/or make arch specific rpm/deb 
> packages that have everything setup correctly per architecture?
> We could also download them all and have the startup scripts put stuff in the 
> right places depending on the arch of the machine running them?
> I feel like there are probably multiple ways we could solve this without 
> requiring users to jump through a bunch of hoops?
> But I do agree we can’t make the project x86 only.
>
> -Jeremiah
>
> > On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
> >  wrote:
> >
> > Hi,
> >
> > as I was reviewing the patch for this feature (1), we realized that it is 
> > not quite easy to bundle this directly into Cassandra.
> >
> > The problem is that this was supposed to be introduced as a new dependency:
> >
> > 
> >software.amazon.cryptools
> >AmazonCorrettoCryptoProvider
> >2.2.0
> >linux-x86_64
> > 
> >
> > Notice "classifier". That means that if we introduced this dependency into 
> > the project, what about ARM users? (there is corresponding aarch classifier 
> > as well). ACCP is platform-specific but we have to ship Cassandra 
> > platform-agnostic. It just needs to run OOTB everywhere. If we shipped that 
> > with x86 and a user runs Cassandra on ARM, I guess that would break things, 
> > right?
> >
> > We also can not just add both dependencies (both x86 and aarch) because how 
> > would we differentiate between them in runtime? That all is just too tricky 
> > / error prone.
> >
> > So, the approach we want to take is this:
> >
> > 1) nothing will be bundled in Cassandra by default
> > 2) a user is supposed to download the library and put it to the class path
> > 3) a user is supposed to put the implementation of ICryptoProvider 
> > interface Cassandra exposes to the class path
> > 3) a user is supposed to configure cassandra.yaml and its section 
> > "crypto_provider" to reference the implementation he wants
> >
> > That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
> > versa.
> >
> > By default, NoOpProvider will be used, that means that the default crypto 
> > provider from JRE will be used.
> >
> > It can seem like we have not done too much progress here but hey ... we 
> > opened the project to the custom implementations of crypto providers a 
> > community can create. E.g. as 3rd party extensions etc ...
> >
> > I want to be sure that everybody is aware of this change (that we plan to 
> > do that in such a way that it will not be "bundled") and that everybody is 
> > on board with this. Otherwise I am all ears about how to do that 
> > differently.
> >
> > (1) 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FCASSANDRA-18624=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=kYGSZGi3caINvm%2FDT4ms3%2BrcnMTxg0E921cMjmUvHQw%3D=0<https://issues.apache.org/jira/browse/CASSANDRA-18624>
> >
> > 
> > From: German Eichberger via dev 
> > Sent: Friday, June 23, 2023 22:43
> > 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.
> >

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

[Joseph Lynch]

Having native dependencies shouldn't make the project x86 only, it
should just accelerate the performance on x86 when available. Can't we
just try to load the fastest available provider (so arm will use
native java but x86 will use proper hardware acceleration) and failing
that fall-back to the default? If I recall correctly from the
messaging service patches (and zstd/lz4) it's reasonably
straightforward to try to load native code and then fail-back if you
fail.

-Joey

On Thu, Jul 20, 2023 at 10:27 AM J. D. Jordan  wrote:
>
> Maybe we could start providing Dockerfile’s and/or make arch specific rpm/deb 
> packages that have everything setup correctly per architecture?
> We could also download them all and have the startup scripts put stuff in the 
> right places depending on the arch of the machine running them?
> I feel like there are probably multiple ways we could solve this without 
> requiring users to jump through a bunch of hoops?
> But I do agree we can’t make the project x86 only.
>
> -Jeremiah
>
> > On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
> >  wrote:
> >
> > Hi,
> >
> > as I was reviewing the patch for this feature (1), we realized that it is 
> > not quite easy to bundle this directly into Cassandra.
> >
> > The problem is that this was supposed to be introduced as a new dependency:
> >
> > 
> >software.amazon.cryptools
> >AmazonCorrettoCryptoProvider
> >2.2.0
> >linux-x86_64
> > 
> >
> > Notice "classifier". That means that if we introduced this dependency into 
> > the project, what about ARM users? (there is corresponding aarch classifier 
> > as well). ACCP is platform-specific but we have to ship Cassandra 
> > platform-agnostic. It just needs to run OOTB everywhere. If we shipped that 
> > with x86 and a user runs Cassandra on ARM, I guess that would break things, 
> > right?
> >
> > We also can not just add both dependencies (both x86 and aarch) because how 
> > would we differentiate between them in runtime? That all is just too tricky 
> > / error prone.
> >
> > So, the approach we want to take is this:
> >
> > 1) nothing will be bundled in Cassandra by default
> > 2) a user is supposed to download the library and put it to the class path
> > 3) a user is supposed to put the implementation of ICryptoProvider 
> > interface Cassandra exposes to the class path
> > 3) a user is supposed to configure cassandra.yaml and its section 
> > "crypto_provider" to reference the implementation he wants
> >
> > That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
> > versa.
> >
> > By default, NoOpProvider will be used, that means that the default crypto 
> > provider from JRE will be used.
> >
> > It can seem like we have not done too much progress here but hey ... we 
> > opened the project to the custom implementations of crypto providers a 
> > community can create. E.g. as 3rd party extensions etc ...
> >
> > I want to be sure that everybody is aware of this change (that we plan to 
> > do that in such a way that it will not be "bundled") and that everybody is 
> > on board with this. Otherwise I am all ears about how to do that 
> > differently.
> >
> > (1) https://issues.apache.org/jira/browse/CASSANDRA-18624
> >
> > 
> > From: German Eichberger via dev 
> > Sent: Friday, June 23, 2023 22:43
> > 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 - we love performance.
> > 
> > From: David Capwell 
> > Sent: Thursday, June 22, 2023 4:21 PM
> > To: dev 
> > Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
> >
> > +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 chang

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

[J. D. Jordan]

Maybe we could start providing Dockerfile’s and/or make arch specific rpm/deb 
packages that have everything setup correctly per architecture?
We could also download them all and have the startup scripts put stuff in the 
right places depending on the arch of the machine running them?
I feel like there are probably multiple ways we could solve this without 
requiring users to jump through a bunch of hoops?
But I do agree we can’t make the project x86 only.

-Jeremiah

> On Jul 20, 2023, at 2:01 AM, Miklosovic, Stefan 
>  wrote:
> 
> Hi,
> 
> as I was reviewing the patch for this feature (1), we realized that it is not 
> quite easy to bundle this directly into Cassandra.
> 
> The problem is that this was supposed to be introduced as a new dependency:
> 
> 
>software.amazon.cryptools
>AmazonCorrettoCryptoProvider
>2.2.0
>linux-x86_64
> 
> 
> Notice "classifier". That means that if we introduced this dependency into 
> the project, what about ARM users? (there is corresponding aarch classifier 
> as well). ACCP is platform-specific but we have to ship Cassandra 
> platform-agnostic. It just needs to run OOTB everywhere. If we shipped that 
> with x86 and a user runs Cassandra on ARM, I guess that would break things, 
> right?
> 
> We also can not just add both dependencies (both x86 and aarch) because how 
> would we differentiate between them in runtime? That all is just too tricky / 
> error prone.
> 
> So, the approach we want to take is this:
> 
> 1) nothing will be bundled in Cassandra by default
> 2) a user is supposed to download the library and put it to the class path
> 3) a user is supposed to put the implementation of ICryptoProvider interface 
> Cassandra exposes to the class path
> 3) a user is supposed to configure cassandra.yaml and its section 
> "crypto_provider" to reference the implementation he wants
> 
> That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
> versa.
> 
> By default, NoOpProvider will be used, that means that the default crypto 
> provider from JRE will be used.
> 
> It can seem like we have not done too much progress here but hey ... we 
> opened the project to the custom implementations of crypto providers a 
> community can create. E.g. as 3rd party extensions etc ...
> 
> I want to be sure that everybody is aware of this change (that we plan to do 
> that in such a way that it will not be "bundled") and that everybody is on 
> board with this. Otherwise I am all ears about how to do that differently.
> 
> (1) https://issues.apache.org/jira/browse/CASSANDRA-18624
> 
> 
> From: German Eichberger via dev 
> Sent: Friday, June 23, 2023 22:43
> 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 - we love performance.
> 
> From: David Capwell 
> Sent: Thursday, June 22, 2023 4:21 PM
> To: dev 
> Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default
> 
> +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<https://urldefense.com/v3/__https://nam04.safelinks.protection.outlook.com/?url=https*3A*2F*2Fgithub.com*2Fcorretto*2Famazon-corretto-crypto-provider=05*7C01*7CStefan.Miklosovic*40net

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

[Miklosovic, Stefan]

Hi,

as I was reviewing the patch for this feature (1), we realized that it is not 
quite easy to bundle this directly into Cassandra.

The problem is that this was supposed to be introduced as a new dependency:


software.amazon.cryptools
AmazonCorrettoCryptoProvider
2.2.0
linux-x86_64


Notice "classifier". That means that if we introduced this dependency into the 
project, what about ARM users? (there is corresponding aarch classifier as 
well). ACCP is platform-specific but we have to ship Cassandra 
platform-agnostic. It just needs to run OOTB everywhere. If we shipped that 
with x86 and a user runs Cassandra on ARM, I guess that would break things, 
right?

We also can not just add both dependencies (both x86 and aarch) because how 
would we differentiate between them in runtime? That all is just too tricky / 
error prone.

So, the approach we want to take is this:

1) nothing will be bundled in Cassandra by default
2) a user is supposed to download the library and put it to the class path
3) a user is supposed to put the implementation of ICryptoProvider interface 
Cassandra exposes to the class path
3) a user is supposed to configure cassandra.yaml and its section 
"crypto_provider" to reference the implementation he wants

That way, we avoid the situation when somebody runs x86 lib on ARM or vice 
versa.

By default, NoOpProvider will be used, that means that the default crypto 
provider from JRE will be used.

It can seem like we have not done too much progress here but hey ... we opened 
the project to the custom implementations of crypto providers a community can 
create. E.g. as 3rd party extensions etc ...

I want to be sure that everybody is aware of this change (that we plan to do 
that in such a way that it will not be "bundled") and that everybody is on 
board with this. Otherwise I am all ears about how to do that differently.

(1) https://issues.apache.org/jira/browse/CASSANDRA-18624


From: German Eichberger via dev 
Sent: Friday, June 23, 2023 22:43
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 - we love performance.

From: David Capwell 
Sent: Thursday, June 22, 2023 4:21 PM
To: dev 
Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default

+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<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorretto%2Famazon-corretto-crypto-provider=05%7C01%7CStefan.Miklosovic%40netapp.com%7C4d73ac88a46f4386826e08db742a82f3%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638231498154472637%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=IvtqDSHL%2BOunrhagmYKTfPa8zlknIPijr8TwVvCKKQw%3D=0>

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

[German Eichberger via dev]

+1 to ACCP - we love performance.

From: David Capwell 
Sent: Thursday, June 22, 2023 4:21 PM
To: dev 
Subject: [EXTERNAL] Re: [DISCUSS] Using ACCP or tc-native by default

+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

[Francisco Guerrero]

Great addition! +1 (nb) 

On 2023/06/23 13:37:02 Josh McKenzie wrote:
>  +1 here on inclusion by default.
> 
> On Fri, Jun 23, 2023, at 2:01 AM, Dinesh Joshi wrote:
> > This would be a good addition and would make Cassandra more performant out 
> > of the box.
> > 
> > Dinesh
> > 
> >> On 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.  
> >> 
> >> 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

[Josh McKenzie]

 +1 here on inclusion by default.

On Fri, Jun 23, 2023, at 2:01 AM, Dinesh Joshi wrote:
> This would be a good addition and would make Cassandra more performant out of 
> the box.
> 
> Dinesh
> 
>> On 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.  
>> 
>> 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 <jackson.flem...@netapp.com> 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 <dcapw...@apple.com>
Date: Friday, 23 June 2023 at 9:22 am
To: dev <dev@cassandra.apache.org>
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 <sc...@paradoxica.net> 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 <jji...@gmail.com> wrote:


 


 



Either would be better than today. 


 



On Thu, Jun 22, 2023 at 1:57 PM Jordan West <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

[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

[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

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