Re: Welcome Patrick McFadin as Cassandra Committer

[DuyHai Doan]

Congratulations to Patrick ! After those years serving the community it is
very well deserved !

Le mer. 8 févr. 2023, 18:43, Mick Semb Wever  a écrit :

>
> Long overdue with so much you have done for so many years. Congrats!
>
> On Thu, 2 Feb 2023 at 23:26, Molly Monroy  wrote:
>
>> Congrats, Patrick... much deserved!
>>
>> On Thu, Feb 2, 2023 at 1:59 PM Derek Chen-Becker 
>> wrote:
>>
>>> Congrats!
>>>
>>> On Thu, Feb 2, 2023 at 10:58 AM Benjamin Lerer 
>>> wrote:
>>>
 The PMC members are pleased to announce that Patrick McFadin has
 accepted
 the invitation to become committer today.

 Thanks a lot, Patrick, for everything you have done for this project
 and its community through the years.

 Congratulations and welcome!

 The Apache Cassandra PMC members

>>>
>>>
>>> --
>>> +---+
>>> | Derek Chen-Becker |
>>> | GPG Key available at https://keybase.io/dchenbecker
>>> 
>>> and   |
>>> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
>>> 
>>> |
>>> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
>>> +---+
>>>
>>>

Re: [DISCUSS] Moving system property names to the CassandraRelevantProperties

[David Capwell]

> Sure, a new checkstyle rule was added to address this case for production and 
> test classes.

Glad to hear =)

> On Feb 9, 2023, at 10:45 AM, Maxim Muzafarov  wrote:
> 
> David,
> 
>> Should” we detect this was violated and fail the build?
> 
> You are asking a good question! Sure, a new checkstyle rule was added
> to address this case for production and test classes.
> 
> On Thu, 9 Feb 2023 at 19:40, David Capwell  wrote:
>> 
>> All properties meant to be used only for tests would have a prefix like 
>> "cassandra.test.name.of.property" and production properties would be 
>> "cassandra.xyx". Once this is done, we can filter them out in vtable so 
>> there would not be any test-related properties in production. Test 
>> properties should be visible only when developing / testing Cassandra, in my 
>> opinion.
>> 
>> 
>> Good point, I wouldn’t want to expose properties meant to break C* for 
>> testing… that implies to users we should be using it!
>> 
>> I understand that there is a lot of legacy in place and we can not rename 
>> properties just like that for people.
>> 
>> 
>> We could always look to do things like we did in Config (which you call 
>> out), add a way to “migrate” to the new naming/format.  I am not sure if 
>> there is enough configs to justify this, but with 5.0 happening it may be a 
>> good time to think about normalizing these.
>> 
>> We are trying to clean up the source code around the direct use of system 
>> properties and make this use more manageable and transparent.
>> 
>> 
>> I didn’t review, but one question I have is inline with "I would like to 
>> describe the ideal state / end goal”, but from the point of view of 
>> maintaining things…. If someone adds a new system property “should” they use 
>> this enum?  “Should” we detect this was violated and fail the build?
>> 
>> If we migrate now, nothing stops us from adding new, causing someone else to 
>> be forced to migrate after…. Its one of the issues with the current enum, 
>> once it was created authors didn’t add to it always causing patches like 
>> this to try to migrate…
>> 
>> I am not trying to block your patch, if you don’t deal with this I am +0… 
>> just saying that maintaince is something we must think about
>> 
>> On Feb 9, 2023, at 6:37 AM, Miklosovic, Stefan 
>>  wrote:
>> 
>> Hi Maxim,
>> 
>> I would like to describe the ideal state / end goal, from my perspective.
>> 
>> All properties meant to be used only for tests would have a prefix like 
>> "cassandra.test.name.of.property" and production properties would be 
>> "cassandra.xyx". Once this is done, we can filter them out in vtable so 
>> there would not be any test-related properties in production. Test 
>> properties should be visible only when developing / testing Cassandra, in my 
>> opinion.
>> 
>> All other system properties should also have some consistent naming in place.
>> 
>> I understand that there is a lot of legacy in place and we can not rename 
>> properties just like that for people.
>> 
>> The approach I like is what was done to properties in cassandra.yaml. There 
>> is @Replaces annotation put on properties in Config which enables users to 
>> still use the old names.
>> 
>> I can imagine that something like this would used here. If an old name is 
>> specified, it would internally translate to a new name and only new names 
>> would be returned by vtable. There might be also a column for old names so 
>> people would know what new property the old one translates to and we should 
>> also emit warning for users that the system properties they are using are in 
>> the old format and they should move to the new ones.
>> 
>> Anyway, I am glad this is happening and we are making progress. It will be 
>> also way easier to dump all properties to the website when everything is 
>> centralized at once place.
>> 
>> Regards
>> 
>> 
>> From: Maxim Muzafarov 
>> Sent: Wednesday, February 8, 2023 19:48
>> To: dev@cassandra.apache.org
>> Subject: [DISCUSS] Moving system property names to the 
>> CassandraRelevantProperties
>> 
>> 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.
>> 
>> 
>> 
>> 
>> Hello everyone,
>> 
>> 
>> We are trying to clean up the source code around the direct use of
>> system properties and make this use more manageable and transparent.
>> To achieve this, I have prepared a patch that moves all system
>> property names to the CassandraRelevantProperties, which in turn makes
>> some of the properties visible to a user through the
>> SystemPropertiesTable virtual table.
>> 
>> The patch has passed a few rounds of review, but we still need another
>> pair of eyes to make sure we are not missing anything valuable.
>> Please, take a look at the patch.
>> 
>> You can find all the changes here:
>> https://issues.apache.org/jira/browse/CASSANDRA-17797
>> 
>> 
>> I'd also like to 

Re: [DISCUSS] Moving system property names to the CassandraRelevantProperties

[Maxim Muzafarov]

David,

> Should” we detect this was violated and fail the build?

You are asking a good question! Sure, a new checkstyle rule was added
to address this case for production and test classes.

On Thu, 9 Feb 2023 at 19:40, David Capwell  wrote:
>
> All properties meant to be used only for tests would have a prefix like 
> "cassandra.test.name.of.property" and production properties would be 
> "cassandra.xyx". Once this is done, we can filter them out in vtable so there 
> would not be any test-related properties in production. Test properties 
> should be visible only when developing / testing Cassandra, in my opinion.
>
>
> Good point, I wouldn’t want to expose properties meant to break C* for 
> testing… that implies to users we should be using it!
>
> I understand that there is a lot of legacy in place and we can not rename 
> properties just like that for people.
>
>
> We could always look to do things like we did in Config (which you call out), 
> add a way to “migrate” to the new naming/format.  I am not sure if there is 
> enough configs to justify this, but with 5.0 happening it may be a good time 
> to think about normalizing these.
>
> We are trying to clean up the source code around the direct use of system 
> properties and make this use more manageable and transparent.
>
>
> I didn’t review, but one question I have is inline with "I would like to 
> describe the ideal state / end goal”, but from the point of view of 
> maintaining things…. If someone adds a new system property “should” they use 
> this enum?  “Should” we detect this was violated and fail the build?
>
> If we migrate now, nothing stops us from adding new, causing someone else to 
> be forced to migrate after…. Its one of the issues with the current enum, 
> once it was created authors didn’t add to it always causing patches like this 
> to try to migrate…
>
> I am not trying to block your patch, if you don’t deal with this I am +0… 
> just saying that maintaince is something we must think about
>
> On Feb 9, 2023, at 6:37 AM, Miklosovic, Stefan  
> wrote:
>
> Hi Maxim,
>
> I would like to describe the ideal state / end goal, from my perspective.
>
> All properties meant to be used only for tests would have a prefix like 
> "cassandra.test.name.of.property" and production properties would be 
> "cassandra.xyx". Once this is done, we can filter them out in vtable so there 
> would not be any test-related properties in production. Test properties 
> should be visible only when developing / testing Cassandra, in my opinion.
>
> All other system properties should also have some consistent naming in place.
>
> I understand that there is a lot of legacy in place and we can not rename 
> properties just like that for people.
>
> The approach I like is what was done to properties in cassandra.yaml. There 
> is @Replaces annotation put on properties in Config which enables users to 
> still use the old names.
>
> I can imagine that something like this would used here. If an old name is 
> specified, it would internally translate to a new name and only new names 
> would be returned by vtable. There might be also a column for old names so 
> people would know what new property the old one translates to and we should 
> also emit warning for users that the system properties they are using are in 
> the old format and they should move to the new ones.
>
> Anyway, I am glad this is happening and we are making progress. It will be 
> also way easier to dump all properties to the website when everything is 
> centralized at once place.
>
> Regards
>
> 
> From: Maxim Muzafarov 
> Sent: Wednesday, February 8, 2023 19:48
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Moving system property names to the 
> CassandraRelevantProperties
>
> 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.
>
>
>
>
> Hello everyone,
>
>
> We are trying to clean up the source code around the direct use of
> system properties and make this use more manageable and transparent.
> To achieve this, I have prepared a patch that moves all system
> property names to the CassandraRelevantProperties, which in turn makes
> some of the properties visible to a user through the
> SystemPropertiesTable virtual table.
>
> The patch has passed a few rounds of review, but we still need another
> pair of eyes to make sure we are not missing anything valuable.
> Please, take a look at the patch.
>
> You can find all the changes here:
> https://issues.apache.org/jira/browse/CASSANDRA-17797
>
>
> I'd also like to share the names of the properties that will appear in
> the SystemPropertiesTable, the appearance of which is related to the
> public API changes we agreed to discuss on the dev list.
>
>
> The public API changes
>
> Newly production system properties added:
>
> io.netty.eventLoopThreads
> io.netty.transport.estimateSizeOnSubmit
> 

Re: [DISCUSS] Moving system property names to the CassandraRelevantProperties

[David Capwell]

> All properties meant to be used only for tests would have a prefix like 
> "cassandra.test.name.of.property" and production properties would be 
> "cassandra.xyx". Once this is done, we can filter them out in vtable so there 
> would not be any test-related properties in production. Test properties 
> should be visible only when developing / testing Cassandra, in my opinion.
> 

Good point, I wouldn’t want to expose properties meant to break C* for testing… 
that implies to users we should be using it!

> I understand that there is a lot of legacy in place and we can not rename 
> properties just like that for people.

We could always look to do things like we did in Config (which you call out), 
add a way to “migrate” to the new naming/format.  I am not sure if there is 
enough configs to justify this, but with 5.0 happening it may be a good time to 
think about normalizing these.

> We are trying to clean up the source code around the direct use of system 
> properties and make this use more manageable and transparent.


I didn’t review, but one question I have is inline with "I would like to 
describe the ideal state / end goal”, but from the point of view of maintaining 
things…. If someone adds a new system property “should” they use this enum?  
“Should” we detect this was violated and fail the build?  

If we migrate now, nothing stops us from adding new, causing someone else to be 
forced to migrate after…. Its one of the issues with the current enum, once it 
was created authors didn’t add to it always causing patches like this to try to 
migrate…

I am not trying to block your patch, if you don’t deal with this I am +0… just 
saying that maintaince is something we must think about

> On Feb 9, 2023, at 6:37 AM, Miklosovic, Stefan  
> wrote:
> 
> Hi Maxim,
> 
> I would like to describe the ideal state / end goal, from my perspective.
> 
> All properties meant to be used only for tests would have a prefix like 
> "cassandra.test.name.of.property" and production properties would be 
> "cassandra.xyx". Once this is done, we can filter them out in vtable so there 
> would not be any test-related properties in production. Test properties 
> should be visible only when developing / testing Cassandra, in my opinion.
> 
> All other system properties should also have some consistent naming in place.
> 
> I understand that there is a lot of legacy in place and we can not rename 
> properties just like that for people.
> 
> The approach I like is what was done to properties in cassandra.yaml. There 
> is @Replaces annotation put on properties in Config which enables users to 
> still use the old names.
> 
> I can imagine that something like this would used here. If an old name is 
> specified, it would internally translate to a new name and only new names 
> would be returned by vtable. There might be also a column for old names so 
> people would know what new property the old one translates to and we should 
> also emit warning for users that the system properties they are using are in 
> the old format and they should move to the new ones.
> 
> Anyway, I am glad this is happening and we are making progress. It will be 
> also way easier to dump all properties to the website when everything is 
> centralized at once place.
> 
> Regards
> 
> 
> From: Maxim Muzafarov 
> Sent: Wednesday, February 8, 2023 19:48
> To: dev@cassandra.apache.org
> Subject: [DISCUSS] Moving system property names to the 
> CassandraRelevantProperties
> 
> 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.
> 
> 
> 
> 
> Hello everyone,
> 
> 
> We are trying to clean up the source code around the direct use of
> system properties and make this use more manageable and transparent.
> To achieve this, I have prepared a patch that moves all system
> property names to the CassandraRelevantProperties, which in turn makes
> some of the properties visible to a user through the
> SystemPropertiesTable virtual table.
> 
> The patch has passed a few rounds of review, but we still need another
> pair of eyes to make sure we are not missing anything valuable.
> Please, take a look at the patch.
> 
> You can find all the changes here:
> https://issues.apache.org/jira/browse/CASSANDRA-17797
> 
> 
> I'd also like to share the names of the properties that will appear in
> the SystemPropertiesTable, the appearance of which is related to the
> public API changes we agreed to discuss on the dev list.
> 
> 
> The public API changes
> 
> Newly production system properties added:
> 
> io.netty.eventLoopThreads
> io.netty.transport.estimateSizeOnSubmit
> java.security.auth.login.config
> javax.rmi.ssl.client.enabledCipherSuites
> javax.rmi.ssl.client.enabledProtocols
> ssl.enable
> log4j2.disable.jmx
> log4j2.shutdownHookEnabled
> logback.configurationFile
> 
> Newly added and used for tests only:
> 
> 

Re: [EXTERNAL] Welcome Patrick McFadin as Cassandra Committer

[German Eichberger via dev]

Congratulations! Surprised Patrick wasn't a committer already...

From: Benjamin Lerer 
Sent: Thursday, February 2, 2023 9:58 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Welcome Patrick McFadin as Cassandra Committer

The PMC members are pleased to announce that Patrick McFadin has accepted
the invitation to become committer today.

Thanks a lot, Patrick, for everything you have done for this project and its 
community through the years.

Congratulations and welcome!

The Apache Cassandra PMC members

Re: Welcome Patrick McFadin as Cassandra Committer

[Ariel Weisberg]

Welcome Patrick! Thank you for your years of contributions to the community.

On Thu, Feb 2, 2023, at 12:58 PM, Benjamin Lerer wrote:
> The PMC members are pleased to announce that Patrick McFadin has accepted
> the invitation to become committer today.
> 
> Thanks a lot, Patrick, for everything you have done for this project and its 
> community through the years.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: [DISCUSS] Moving system property names to the CassandraRelevantProperties

[Miklosovic, Stefan]

Hi Maxim,

I would like to describe the ideal state / end goal, from my perspective.

All properties meant to be used only for tests would have a prefix like 
"cassandra.test.name.of.property" and production properties would be 
"cassandra.xyx". Once this is done, we can filter them out in vtable so there 
would not be any test-related properties in production. Test properties should 
be visible only when developing / testing Cassandra, in my opinion.

All other system properties should also have some consistent naming in place.

I understand that there is a lot of legacy in place and we can not rename 
properties just like that for people.

The approach I like is what was done to properties in cassandra.yaml. There is 
@Replaces annotation put on properties in Config which enables users to still 
use the old names.

I can imagine that something like this would used here. If an old name is 
specified, it would internally translate to a new name and only new names would 
be returned by vtable. There might be also a column for old names so people 
would know what new property the old one translates to and we should also emit 
warning for users that the system properties they are using are in the old 
format and they should move to the new ones.

Anyway, I am glad this is happening and we are making progress. It will be also 
way easier to dump all properties to the website when everything is centralized 
at once place.

Regards


From: Maxim Muzafarov 
Sent: Wednesday, February 8, 2023 19:48
To: dev@cassandra.apache.org
Subject: [DISCUSS] Moving system property names to the 
CassandraRelevantProperties

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.




Hello everyone,


We are trying to clean up the source code around the direct use of
system properties and make this use more manageable and transparent.
To achieve this, I have prepared a patch that moves all system
property names to the CassandraRelevantProperties, which in turn makes
some of the properties visible to a user through the
SystemPropertiesTable virtual table.

The patch has passed a few rounds of review, but we still need another
pair of eyes to make sure we are not missing anything valuable.
Please, take a look at the patch.

You can find all the changes here:
https://issues.apache.org/jira/browse/CASSANDRA-17797


I'd also like to share the names of the properties that will appear in
the SystemPropertiesTable, the appearance of which is related to the
public API changes we agreed to discuss on the dev list.


The public API changes

Newly production system properties added:

io.netty.eventLoopThreads
io.netty.transport.estimateSizeOnSubmit
java.security.auth.login.config
javax.rmi.ssl.client.enabledCipherSuites
javax.rmi.ssl.client.enabledProtocols
ssl.enable
log4j2.disable.jmx
log4j2.shutdownHookEnabled
logback.configurationFile

Newly added and used for tests only:

invalid-legacy-sstable-root
legacy-sstable-root
org.apache.cassandra.tools.UtilALLOW_TOOL_REINIT_FOR_TEST
org.caffinitas.ohc.segmentCount
suitename
sun.stderr.encoding
sun.stdout.encoding
test.bbfailhelper.enabled
write_survey

Re: [VOTE] Release Apache Cassandra 4.0.8

[Berenguer Blasi]

+1

On 9/2/23 12:50, Brandon Williams wrote:

+1

Kind Regards,
Brandon

On Thu, Feb 9, 2023 at 4:56 AM Miklosovic, Stefan
 wrote:

Proposing the test build of Cassandra 4.0.8 for release.

sha1: 32c56df067b72da8593c1ddaaf143fe8668459dd
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.8-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1283/org/apache/cassandra/cassandra-all/4.0.8/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.8/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.8-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.8-tentative

Re: [VOTE] Release Apache Cassandra 4.0.8

[Brandon Williams]

+1

Kind Regards,
Brandon

On Thu, Feb 9, 2023 at 4:56 AM Miklosovic, Stefan
 wrote:
>
> Proposing the test build of Cassandra 4.0.8 for release.
>
> sha1: 32c56df067b72da8593c1ddaaf143fe8668459dd
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.8-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1283/org/apache/cassandra/cassandra-all/4.0.8/
>
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.8/
>
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.8-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.8-tentative

Re: [VOTE] Release Apache Cassandra 4.0.8

[Mick Semb Wever]

>
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
>
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.8-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.8-tentative
>


+1

Checked
- signing correct
- checksums are correct
- source artefact builds (JDK 8+11)
- binary artefact runs (JDK 8+11)
- debian package runs (JDK 8+11)
- debian repo runs (JDK 8+11)
- redhat* package runs (JDK 8+11)
- redhat* repo runs (JDK 8+11)

[VOTE] Release Apache Cassandra 4.0.8

[Miklosovic, Stefan]

Proposing the test build of Cassandra 4.0.8 for release.

sha1: 32c56df067b72da8593c1ddaaf143fe8668459dd 
Git: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.8-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1283/org/apache/cassandra/cassandra-all/4.0.8/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/4.0.8/

The vote will be open for 72 hours (longer if needed). Everyone who has tested 
the build is invited to vote. Votes by PMC members are considered binding. A 
vote passes if there are at least three binding +1s and no -1's.

[1]: CHANGES.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.8-tentative
[2]: NEWS.txt: 
https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.8-tentative