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 <dri...@gmail.com> 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
>> <dev@cassandra.apache.org> 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 <joe.e.ly...@gmail.com>
>> Sent: Thursday, July 20, 2023 7:38 AM
>> To: dev@cassandra.apache.org <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 <jeremiah.jor...@gmail.com> 
>>> 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 
>>>> <stefan.mikloso...@netapp.com> 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:
>>>> 
>>>> <dependency>
>>>>       <groupId>software.amazon.cryptools</groupId>
>>>>       <artifactId>AmazonCorrettoCryptoProvider</artifactId>
>>>>       <version>2.2.0</version>
>>>>       <classifier>linux-x86_64</classifier>
>>>> <dependency>
>>>> 
>>>> 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&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=kYGSZGi3caINvm%2FDT4ms3%2BrcnMTxg0E921cMjmUvHQw%3D&reserved=0
>>>> 
>>>> ________________________________________
>>>> From: German Eichberger via dev <dev@cassandra.apache.org>
>>>> 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 <dcapw...@apple.com>
>>>> Sent: Thursday, June 22, 2023 4:21 PM
>>>> To: dev <dev@cassandra.apache.org>
>>>> 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 <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<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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcorretto%2Famazon-corretto-crypto-provider&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bGU%2B7jerm8fiS0Tmav8geFStI%2FcvZKinF35YGKuEQtY%3D&reserved=0<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam04.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fgithub.com*2Fcorretto*2Famazon-corretto-crypto-provider%26data%3D05*7C01*7CStefan.Miklosovic*40netapp.com*7C4d73ac88a46f4386826e08db742a82f3*7C4b0911a0929b4715944bc03745165b3a*7C0*7C0*7C638231498154472637*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3DIvtqDSHL*2BOunrhagmYKTfPa8zlknIPijr8TwVvCKKQw*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!PbtH5S7Ebw!fuCaq60SW0zceq0aFBYG3J8ga4gAtUG5n1qZyiyRSo8X-epQfmmdXqSOXzX4tQbeAMSc5QuTXtz2W0xWyPp59OcTF5Ra%24&data=05%7C01%7CGerman.Eichberger%40microsoft.com%7Cf4530a41df3b419fd2ff08db892f0ed6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638254607439254753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZWsg5GPkPCDf6EFKcqhEtbYLtEpHtcFbY8ir2i69Nfw%3D&reserved=0
>>>>  >
>>>> 
>>>> 

Reply via email to