Re: Who wants a free Cassandra t-shirt?

[guo Maxwell]

It seems I‘ve never had one… 

Patrick McFadin 于2023年7月22日 周六上午8:48写道：

> We have about another week left on the user survey I posted last week. The
> response has been slow, so it's time to get things in gear.
>
> I found a box of Cassandra t-shirts that will make an excellent thank you
> for anyone filling out the survey. Once the survey window closes, I'll pick
> a random group of emails to receive a shirt. Given the tepid response so
> far, your chances are decent to receive a shirt!
>
> 5-10 minutes. That's all it takes. Promote to your networks and let's get
> some opinions known!
>
> https://forms.gle/KVNd7UmUfcBuoNvF7
>
> Thanks again,
>
> Patrick
>
-- 
you are the apple of my eye !

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Yuki Morishita]

+1

Just one update to CEP that I would like to propose is to clarify which
"appropriate permissions" are necessary to add/drop identities.
According to the current patch, in order to add identities, the
roles require "CREATE ROLE" permission, and to drop they require "DROP
ROLE" permission.
I have no objection here, just want to make sure we are not introducing
another role resource.

On Sat, Jul 22, 2023 at 7:43 AM Abe Ratnofsky  wrote:

> +1 (nb)
>
> On Jul 21, 2023, at 3:03 PM, Jon Meredith  wrote:
>
> +1
>
> On Fri, Jul 21, 2023 at 2:33 PM Blake Eggleston 
> wrote:
>
>> +1
>>
>> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa 
>> wrote:
>>
>> Hi Everyone!
>>
>> I would like to start a vote thread for CEP-34.
>>
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
>> JIRA   :
>> https://issues.apache.org/jira/browse/CASSANDRA-18554
>> Draft Implementation : https://github.com/apache/cassandra/pull/2372
>> Discussion :
>> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>>
>> The vote will be open for 72 hours. A vote passes if there are at least 3
>> binding +1s and no binding vetoes.
>>
>> Thanks,
>> Jyothsna Konisa.
>>
>>
>>
>

Who wants a free Cassandra t-shirt?

[Patrick McFadin]

We have about another week left on the user survey I posted last week. The
response has been slow, so it's time to get things in gear.

I found a box of Cassandra t-shirts that will make an excellent thank you
for anyone filling out the survey. Once the survey window closes, I'll pick
a random group of emails to receive a shirt. Given the tepid response so
far, your chances are decent to receive a shirt!

5-10 minutes. That's all it takes. Promote to your networks and let's get
some opinions known!

https://forms.gle/KVNd7UmUfcBuoNvF7

Thanks again,

Patrick

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Abe Ratnofsky]

+1 (nb)

> On Jul 21, 2023, at 3:03 PM, Jon Meredith  wrote:
> 
> +1
> 
> On Fri, Jul 21, 2023 at 2:33 PM Blake Eggleston  > wrote:
>> +1
>> 
>>> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa >> > wrote:
>>> 
>>> Hi Everyone!
>>> 
>>> I would like to start a vote thread for CEP-34.
>>> 
>>> Proposal: 
>>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
>>> JIRA   : 
>>> https://issues.apache.org/jira/browse/CASSANDRA-18554
>>> Draft Implementation : https://github.com/apache/cassandra/pull/2372
>>> Discussion : 
>>> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>>> 
>>> The vote will be open for 72 hours. A vote passes if there are at least 3 
>>> binding +1s and no binding vetoes.
>>> 
>>> Thanks,
>>> Jyothsna Konisa.
>> 

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Jon Meredith]

+1

On Fri, Jul 21, 2023 at 2:33 PM Blake Eggleston 
wrote:

> +1
>
> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa 
> wrote:
>
> Hi Everyone!
>
> I would like to start a vote thread for CEP-34.
>
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
> JIRA   :
> https://issues.apache.org/jira/browse/CASSANDRA-18554
> Draft Implementation : https://github.com/apache/cassandra/pull/2372
> Discussion :
> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>
> The vote will be open for 72 hours. A vote passes if there are at least 3
> binding +1s and no binding vetoes.
>
> Thanks,
> Jyothsna Konisa.
>
>
>

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Blake Eggleston]

+1

> On Jul 21, 2023, at 9:57 AM, Jyothsna Konisa  wrote:
> 
> Hi Everyone!
> 
> I would like to start a vote thread for CEP-34.
> 
> Proposal: 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
> JIRA   : 
> https://issues.apache.org/jira/browse/CASSANDRA-18554
> Draft Implementation : https://github.com/apache/cassandra/pull/2372
> Discussion : 
> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3 
> binding +1s and no binding vetoes.
> 
> Thanks,
> Jyothsna Konisa.

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Yifan Cai]

+1

From: Dinesh Joshi 
Sent: Friday, July 21, 2023 12:23:30 PM
To: dev 
Subject: Re: [VOTE] CEP-34: mTLS based client and internode authenticators

+1

> On Jul 21, 2023, at 11:07 AM, Francisco Guerrero  wrote:
>
> +1 (nb). This is a very valuable enhancement for the project.
>
> Thanks for the contribution, Jyothsna!
>
> On 2023/07/21 16:57:45 Jyothsna Konisa wrote:
>> Hi Everyone!
>>
>> I would like to start a vote thread for CEP-34.
>>
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
>> JIRA   :
>> https://issues.apache.org/jira/browse/CASSANDRA-18554
>> Draft Implementation : https://github.com/apache/cassandra/pull/2372
>> Discussion :
>> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>>
>> The vote will be open for 72 hours. A vote passes if there are at least 3
>> binding +1s and no binding vetoes.
>>
>> Thanks,
>> Jyothsna Konisa.
>>

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Dinesh Joshi]

+1

> On Jul 21, 2023, at 11:07 AM, Francisco Guerrero  wrote:
> 
> +1 (nb). This is a very valuable enhancement for the project.
> 
> Thanks for the contribution, Jyothsna!
> 
> On 2023/07/21 16:57:45 Jyothsna Konisa wrote:
>> Hi Everyone!
>> 
>> I would like to start a vote thread for CEP-34.
>> 
>> Proposal:
>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
>> JIRA   :
>> https://issues.apache.org/jira/browse/CASSANDRA-18554
>> Draft Implementation : https://github.com/apache/cassandra/pull/2372
>> Discussion :
>> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
>> 
>> The vote will be open for 72 hours. A vote passes if there are at least 3
>> binding +1s and no binding vetoes.
>> 
>> Thanks,
>> Jyothsna Konisa.
>> 

Re: [VOTE] CEP-34: mTLS based client and internode authenticators

[Francisco Guerrero]

+1 (nb). This is a very valuable enhancement for the project.

Thanks for the contribution, Jyothsna!

On 2023/07/21 16:57:45 Jyothsna Konisa wrote:
> Hi Everyone!
> 
> I would like to start a vote thread for CEP-34.
> 
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
> JIRA   :
> https://issues.apache.org/jira/browse/CASSANDRA-18554
> Draft Implementation : https://github.com/apache/cassandra/pull/2372
> Discussion :
> https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f
> 
> The vote will be open for 72 hours. A vote passes if there are at least 3
> binding +1s and no binding vetoes.
> 
> Thanks,
> Jyothsna Konisa.
> 

Re: Cassandra Sidecar CI is now green!

[Dinesh Joshi]

Thanks Francisco, Mick and Yifan for making this happen!

> On Jul 20, 2023, at 4:00 PM, Francisco Guerrero  wrote:
> 
> Hi list,
> 
> I wanted to bring some visibility into the Cassandra Sidecar CI health [1].
> It seems like it has been broken for quite a while and we have finally fixed
> it today.
> 
> Special thanks to Mick for noticing the issue and bringing it up to me. Also,
> thanks to Yifan and Dinesh for reviewing the PR [2] and helping me iterate
> over the PR.
> 
> Best,
> - Francisco
> 
> [1] https://ci-cassandra.apache.org/job/cassandra~sidecar/
> [2] https://issues.apache.org/jira/browse/CASSANDRASC-66

[VOTE] CEP-34: mTLS based client and internode authenticators

[Jyothsna Konisa]

Hi Everyone!

I would like to start a vote thread for CEP-34.

Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-34%3A+mTLS+based+client+and+internode+authenticators
JIRA   :
https://issues.apache.org/jira/browse/CASSANDRA-18554
Draft Implementation : https://github.com/apache/cassandra/pull/2372
Discussion :
https://lists.apache.org/thread/pnfg65r76rbbs70hwhsz94ds6yo2042f

The vote will be open for 72 hours. A vote passes if there are at least 3
binding +1s and no binding vetoes.

Thanks,
Jyothsna Konisa.

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] Maintain backwards compatibility after dependency upgrade in the 5.0

[Maxim Muzafarov]

Hello everyone,

It still needs a pair of eyes to push it forward.


I came across another good thing that might help us to overcome the
difficulties with the dropwizard metrics dependency upgrade. The
change relates to the driver itself and reuses the same approach that
was used to deal with the driver's netty dependencies. We need to
shade the dropwizard metrics classes and no longer rely on the
cassandra classpath at least for the 3.x version of the java driver,
and make the next 3.11.4 release of the java driver accordingly.

The changes for the driver are here:
https://github.com/datastax/java-driver/pull/1685

This will give us (and users as well) the confidence to move forward
with this change to 5.x alongside the 3.11 version of the driver
usage. Looking forward to your thoughts.

Changes for the Cassandra part are here:
https://github.com/apache/cassandra/pull/2238/files

On Mon, 3 Jul 2023 at 15:15, Maxim Muzafarov  wrote:
>
> I'd like to mention the approach we took here: to untangle the driver
> update in tests with the dropwizard library version (cassandra-driver
> 3.11 requires the "old" JMXReporter classes in the classpath) we have
> copied the classes into the tests themselves, as it is allowed by the
> Apache License 2.0. This way we can update the metrics library itself
> and then update the driver used in the tests afterwards.
>
> If there are no objections, we need another committer to take a look
> at these changes:
> https://issues.apache.org/jira/browse/CASSANDRA-14667
> https://github.com/apache/cassandra/pull/2238/files
>
> Thanks in advance for your help!
>
> On Wed, 28 Jun 2023 at 16:04, Bowen Song via dev
>  wrote:
> >
> > IMHO, anyone upgrading software between major versions should expect to
> > see breaking changes. Introducing breaking or major changes is the whole
> > point of bumping major version numbers.
> >
> > Since the library upgrade need to happen sooner or later, I don't see
> > any reason why it should not happen in the 5.0 release.
> >
> >
> > On 27/06/2023 19:21, Maxim Muzafarov wrote:
> > > Hello everyone,
> > >
> > >
> > > We use the Dropwizard Metrics 3.1.5 library, which provides a basic
> > > set of classes to easily expose Cassandra internals to a user through
> > > various interfaces (the most common being JMX). We want to upgrade
> > > this library version in the next major release 5.0 up to the latest
> > > stable 4.2.19 for the following reasons:
> > > - the 3.x (and 4.0.x) Dropwizard Metrics library is no longer
> > > supported, which means that if we face a critical CVE, we'll still
> > > need to upgrade, so it's better to do it sooner and more calmly;
> > > - as of 4.2.5 the library supports jdk11, jdk17, so we will be in-sync
> > > [1] as well as having some of the compatibility fixes mentioned in the
> > > related JIRA [2];
> > > - there have been a few user-related requests [3][4] whose
> > > applications collide with the old version of the library, we want to
> > > help them;
> > >
> > >
> > > The problem
> > >
> > > The problem with simply upgrading is that the JmxReporter class of the
> > > library has moved from the com.codahale.metrics package in the 3.x
> > > release to the com.codahale.metrics.jmx package in the 4.x release.
> > > This is a problem for applications/tools that rely on the cassandra
> > > classpath (lib/jars) as after the upgrade they may be looking for the
> > > JmxReporter class which has changed its location.
> > >
> > > A good example of the problem that we (or a user) may face after the
> > > upgrade is our tests and the cassandra-driver-core 3.1.1, which uses
> > > the old 3.x version of the library in tests. Of course, in this case,
> > > we can upgrade the cassandra driver up to 4.x [5][6] to fix the
> > > problem, as the new driver uses a newer version of the library, but
> > > that's another story I won't go into for now. I'm talking more about
> > > visualising the problem a user might face after upgrading to 5.0 if
> > > he/she rely on the cassandra classpath, but on the other hand, they
> > > might not face this problem at all because, as I understand, they will
> > > provide this library in their applications by themselves.
> > >
> > >
> > > So, since Cassandra has a huge ecosystem and a variety of tools that I
> > > can't even imagine, the main question here is:
> > >
> > > Can we move forward with this change without breaking backwards
> > > compatibility with any kind of tools that we have considering the
> > > example above as the main case? Do you have any thoughts on this?
> > >
> > > The changes are here:
> > > https://github.com/apache/cassandra/pull/2238/files
> > >
> > >
> > >
> > > [1] 
> > > https://github.com/dropwizard/metrics/pull/2180/files#diff-5dbf1a803ecc13ff945a08ed3eb09149a83615e83f15320550af8e3a91976446R14
> > > [2] https://issues.apache.org/jira/browse/CASSANDRA-14667
> > > [3] 
> > > https://github.com/dropwizard/metrics/issues/1581#issuecomment-628430870
> > > [4] 

Re: Cassandra Sidecar CI is now green!

[Francisco Guerrero]

I'm happy to help in any way I can with other subprojects!

- Francisco

On 2023/07/21 04:59:50 Mick Semb Wever wrote:
> Thank you everyone that was involved.
> There's a lot to do with sub-projects, I'm sure the folk who will be
> working with the drivers subproject will want to learn a lot from you.
> 
> 
> On Fri, 21 Jul 2023 at 01:11, Yifan Cai  wrote:
> 
> > Thank you for fixing the build on ci-cassandra! I am glad that I can
> > contribute to the process :D
> >
> > - Yifan
> >
> > On Thu, Jul 20, 2023 at 4:00 PM Francisco Guerrero 
> > wrote:
> >
> >> Hi list,
> >>
> >> I wanted to bring some visibility into the Cassandra Sidecar CI health
> >> [1].
> >> It seems like it has been broken for quite a while and we have finally
> >> fixed
> >> it today.
> >>
> >> Special thanks to Mick for noticing the issue and bringing it up to me.
> >> Also,
> >> thanks to Yifan and Dinesh for reviewing the PR [2] and helping me iterate
> >> over the PR.
> >>
> >> Best,
> >> - Francisco
> >>
> >> [1] https://ci-cassandra.apache.org/job/cassandra~sidecar/
> >> [2] https://issues.apache.org/jira/browse/CASSANDRASC-66
> >>
> >
>