[jira] [Commented] (CASSANDRA-19957) Nodetool support to get and set the authenticator and authorizer
[
https://issues.apache.org/jira/browse/CASSANDRA-19957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17885138#comment-17885138
]
Andy Tolbert commented on CASSANDRA-19957:
--
This is a great idea! Would love to have this capability to aid authentication
migrations or even as a mechanism to restrict authentication further. I
suppose it could also be used to make things more permissive so would want to
have good logging and observability around this.
> Nodetool support to get and set the authenticator and authorizer
>
>
> Key: CASSANDRA-19957
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19957
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Ayushi Singh
>Assignee: Ayushi Singh
>Priority: Normal
>
> Add {{nodetool}} support in Apache Cassandra to dynamically get and set
> {{authorizer}} and {{authenticator}} configurations. Currently, changes
> require updating the config file and restarting Cassandra. The new commands
> will allow administrators to make updates on-the-fly without a server
> restart, improving flexibility.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19862) gocql: Update testdata/pki certificates as they expire on September 16, 2024
[
https://issues.apache.org/jira/browse/CASSANDRA-19862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19862:
-
Resolution: Fixed
Status: Resolved (was: Triage Needed)
pr has been merged and will be included in 1.7.0 release.
> gocql: Update testdata/pki certificates as they expire on September 16, 2024
>
>
> Key: CASSANDRA-19862
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19862
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> While familiarizing myself with the integration tests for gocql I noticed
> that they were expiring on September 16th, as the certificates were generated
> with a 10 year validity nearly 10 years ago as part of
> [#251|https://github.com/apache/cassandra-gocql-driver/pull/251] which added
> TLS support to gocql:
> {noformat}
> openssl x509 -in testdata/pki/gocql.crt -text -noout
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number: 1 (0x1)
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: CN=cassandra
> Validity
> Not Before: Sep 19 21:18:33 2014 GMT
> Not After : Sep 16 21:18:33 2024 GMT
> {noformat}
> I'd like to regenerate the certificates and will also include a shell script
> for regenerating them as needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19840) Nullability annotations on mapper-runtime classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Tolbert updated CASSANDRA-19840: - Epic Link: CASSANDRA-19886 > Nullability annotations on mapper-runtime classes > - > > Key: CASSANDRA-19840 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19840 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: John B >Priority: Normal > > findbugs nullability annotations were added to the core and query builder > APIs in 4.0: > [https://github.com/apache/cassandra-java-driver/pull/1036/files] > I would like to see the same on the mapper-runtime classes, as I am extending > some of these classes, such as DaoBase and getting warnings on my own code > for marking methods as @Nullable because the DaoBase methods I am calling are > not marked @Nullable even though they explicitly return null. > I am happy to do this work, if there is agreement that this would be good. > Also, let me know if spotbugs annotations should not be used and > [jspecify|https://jspecify.dev/] instead. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19840) Nullability annotations on mapper-runtime classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17881096#comment-17881096 ] Andy Tolbert commented on CASSANDRA-19840: -- Adding as a possible Java 5.0 API change (as adding annotations are technically API changes) > Nullability annotations on mapper-runtime classes > - > > Key: CASSANDRA-19840 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19840 > Project: Cassandra > Issue Type: Improvement > Components: Client/java-driver >Reporter: John B >Priority: Normal > > findbugs nullability annotations were added to the core and query builder > APIs in 4.0: > [https://github.com/apache/cassandra-java-driver/pull/1036/files] > I would like to see the same on the mapper-runtime classes, as I am extending > some of these classes, such as DaoBase and getting warnings on my own code > for marking methods as @Nullable because the DaoBase methods I am calling are > not marked @Nullable even though they explicitly return null. > I am happy to do this work, if there is agreement that this would be good. > Also, let me know if spotbugs annotations should not be used and > [jspecify|https://jspecify.dev/] instead. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19885) Remove default implementations of getExecutionProfile in ExecutionInfo and GraphExecutionInfo
[
https://issues.apache.org/jira/browse/CASSANDRA-19885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19885:
-
Epic Link: CASSANDRA-19886
> Remove default implementations of getExecutionProfile in ExecutionInfo and
> GraphExecutionInfo
> -
>
> Key: CASSANDRA-19885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19885
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Priority: Normal
>
> As a follow on to
> [apache/cassandra-java-driver#1949|https://github.com/apache/cassandra-java-driver/pull/1949]
> we should remove the default implementations of {{getExecutionProfile}} on
> {{ExecutionInfo}} and {{GraphExecutionInfo}} types.
> These methods were added in a minor release (4.19), and in order to retain
> semantic versioning default implementations that return null were added in
> order to avoid breaking backwards compatibility.As returning null by
> default is not ideal, remove the {{default}} keyword on next major release as
> a breaking API change would ok then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19886) Java Driver 5.0 API Breaking Changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Tolbert updated CASSANDRA-19886: - Description: A collection of JIRAs that involve making breaking API changes that would need to be done in the next major driver release As the Apache Cassandra Java Driver aspires to follow [semantic versioning|https://semver.org/] ([reference|https://github.com/apache/cassandra-java-driver/blob/a17f7be614a09ab81bc2982b7f7ab3a123b4ab28/manual/api_conventions/README.md?plain=1#L29-L31]), any change that breaks backwards compatibility can not be made in a minor or patch release. Any breaking API change should be held back until a major release, and even then API changes should be minimal in order to reduce friction in upgrading between major releases. This epic captures JIRAs that were created that would possibly involve making breaking API changes so they can be more easily tracked. For example [CASSANDRA-19885], which involves removing a default interface method added in a minor version to avoid breaking compatibility in a minor release. was: As the Apache Cassandra Java Driver aspires to follow [semantic versioning|https://semver.org/] ([reference|https://github.com/apache/cassandra-java-driver/blob/a17f7be614a09ab81bc2982b7f7ab3a123b4ab28/manual/api_conventions/README.md?plain=1#L29-L31]), any change that breaks backwards compatibility can not be made in a minor or patch release. Any breaking API change should be held back until a major release, and even then API changes should be minimal in order to reduce friction in upgrading between major releases. This epic captures JIRAs that were created that would possibly involve making breaking API changes so they can be more easily tracked. For example [CASSANDRA-19885], which involves removing a default interface method added in a minor version to avoid breaking compatibility in a minor release. > Java Driver 5.0 API Breaking Changes > > > Key: CASSANDRA-19886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19886 > Project: Cassandra > Issue Type: Epic > Components: Client/java-driver >Reporter: Andy Tolbert >Priority: Normal > > A collection of JIRAs that involve making breaking API changes that would > need to be done in the next major driver release > As the Apache Cassandra Java Driver aspires to follow [semantic > versioning|https://semver.org/] > ([reference|https://github.com/apache/cassandra-java-driver/blob/a17f7be614a09ab81bc2982b7f7ab3a123b4ab28/manual/api_conventions/README.md?plain=1#L29-L31]), > any change that breaks backwards compatibility can not be made in a minor or > patch release. > Any breaking API change should be held back until a major release, and even > then API changes should be minimal in order to reduce friction in upgrading > between major releases. > This epic captures JIRAs that were created that would possibly involve making > breaking API changes so they can be more easily tracked. > For example [CASSANDRA-19885], which involves removing a default interface > method added in a minor version to avoid breaking compatibility in a minor > release. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19886) Java Driver 5.0 API Breaking Changes
[ https://issues.apache.org/jira/browse/CASSANDRA-19886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Tolbert updated CASSANDRA-19886: - Summary: Java Driver 5.0 API Breaking Changes (was: A collection of JIRAs that involve making breaking API changes that would need to be done in the next major driver release) > Java Driver 5.0 API Breaking Changes > > > Key: CASSANDRA-19886 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19886 > Project: Cassandra > Issue Type: Epic > Components: Client/java-driver >Reporter: Andy Tolbert >Priority: Normal > > As the Apache Cassandra Java Driver aspires to follow [semantic > versioning|https://semver.org/] > ([reference|https://github.com/apache/cassandra-java-driver/blob/a17f7be614a09ab81bc2982b7f7ab3a123b4ab28/manual/api_conventions/README.md?plain=1#L29-L31]), > any change that breaks backwards compatibility can not be made in a minor or > patch release. > Any breaking API change should be held back until a major release, and even > then API changes should be minimal in order to reduce friction in upgrading > between major releases. > This epic captures JIRAs that were created that would possibly involve making > breaking API changes so they can be more easily tracked. > For example [CASSANDRA-19885], which involves removing a default interface > method added in a minor version to avoid breaking compatibility in a minor > release. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19886) A collection of JIRAs that involve making breaking API changes that would need to be done in the next major driver release
Andy Tolbert created CASSANDRA-19886: Summary: A collection of JIRAs that involve making breaking API changes that would need to be done in the next major driver release Key: CASSANDRA-19886 URL: https://issues.apache.org/jira/browse/CASSANDRA-19886 Project: Cassandra Issue Type: Epic Components: Client/java-driver Reporter: Andy Tolbert As the Apache Cassandra Java Driver aspires to follow [semantic versioning|https://semver.org/] ([reference|https://github.com/apache/cassandra-java-driver/blob/a17f7be614a09ab81bc2982b7f7ab3a123b4ab28/manual/api_conventions/README.md?plain=1#L29-L31]), any change that breaks backwards compatibility can not be made in a minor or patch release. Any breaking API change should be held back until a major release, and even then API changes should be minimal in order to reduce friction in upgrading between major releases. This epic captures JIRAs that were created that would possibly involve making breaking API changes so they can be more easily tracked. For example [CASSANDRA-19885], which involves removing a default interface method added in a minor version to avoid breaking compatibility in a minor release. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19885) Remove default implementations of getExecutionProfile in ExecutionInfo and GraphExecutionInfo
[
https://issues.apache.org/jira/browse/CASSANDRA-19885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19885:
-
Description:
As a follow on to
[apache/cassandra-java-driver#1949|https://github.com/apache/cassandra-java-driver/pull/1949]
we should remove the default implementations of {{getExecutionProfile}} on
{{ExecutionInfo}} and {{GraphExecutionInfo}} types.
These methods were added in a minor release (4.19), and in order to retain
semantic versioning default implementations that return null were added in
order to avoid breaking backwards compatibility.As returning null by
default is not ideal, remove the {{default}} keyword on next major release as a
breaking API change would ok then.
was:
As a follow on to
[apache/cassandra-java-driver#1949|https://github.com/apache/cassandra-java-driver/pull/1949]
we should remove the default implementations of {{getExecutionProfile}} on
{{ExecutionInfo}} and {{GraphExecutionInfo}} types.
These methods were added in a minor release (4.19), and in order to retain
semantic versioning default implementations that return null were added in
order to avoid breaking backwards compatibility.As returning null by
default is not ideal, remove the {{default}} keyword on next major release as
breaking API change would ok then.
> Remove default implementations of getExecutionProfile in ExecutionInfo and
> GraphExecutionInfo
> -
>
> Key: CASSANDRA-19885
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19885
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Priority: Normal
>
> As a follow on to
> [apache/cassandra-java-driver#1949|https://github.com/apache/cassandra-java-driver/pull/1949]
> we should remove the default implementations of {{getExecutionProfile}} on
> {{ExecutionInfo}} and {{GraphExecutionInfo}} types.
> These methods were added in a minor release (4.19), and in order to retain
> semantic versioning default implementations that return null were added in
> order to avoid breaking backwards compatibility.As returning null by
> default is not ideal, remove the {{default}} keyword on next major release as
> a breaking API change would ok then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19885) Remove default implementations of getExecutionProfile in ExecutionInfo and GraphExecutionInfo
Andy Tolbert created CASSANDRA-19885:
Summary: Remove default implementations of getExecutionProfile in
ExecutionInfo and GraphExecutionInfo
Key: CASSANDRA-19885
URL: https://issues.apache.org/jira/browse/CASSANDRA-19885
Project: Cassandra
Issue Type: Improvement
Components: Client/java-driver
Reporter: Andy Tolbert
As a follow on to
[apache/cassandra-java-driver#1949|https://github.com/apache/cassandra-java-driver/pull/1949]
we should remove the default implementations of {{getExecutionProfile}} on
{{ExecutionInfo}} and {{GraphExecutionInfo}} types.
These methods were added in a minor release (4.19), and in order to retain
semantic versioning default implementations that return null were added in
order to avoid breaking backwards compatibility.As returning null by
default is not ideal, remove the {{default}} keyword on next major release as
breaking API change would ok then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19862) gocql: Update testdata/pki certificates as they expire on September 16, 2024
Andy Tolbert created CASSANDRA-19862:
Summary: gocql: Update testdata/pki certificates as they expire on
September 16, 2024
Key: CASSANDRA-19862
URL: https://issues.apache.org/jira/browse/CASSANDRA-19862
Project: Cassandra
Issue Type: Improvement
Components: Client/gocql-driver
Reporter: Andy Tolbert
Assignee: Andy Tolbert
While familiarizing myself with the integration tests for gocql I noticed that
they were expiring on September 16th, as the certificates were generated with a
10 year validity nearly 10 years ago as part of
[#251|https://github.com/apache/cassandra-gocql-driver/pull/251] which added
TLS support to gocql:
{noformat}
openssl x509 -in testdata/pki/gocql.crt -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=cassandra
Validity
Not Before: Sep 19 21:18:33 2014 GMT
Not After : Sep 16 21:18:33 2024 GMT
{noformat}
I'd like to regenerate the certificates and will also include a shell script
for regenerating them as needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19858) gocql: Add MutualTls authenticators to defaultApprovedAuthenticators
[
https://issues.apache.org/jira/browse/CASSANDRA-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876555#comment-17876555
]
Andy Tolbert commented on CASSANDRA-19858:
--
Thanks [~djoshi], updated to include a reference to the PR (y)
> gocql: Add MutualTls authenticators to defaultApprovedAuthenticators
>
>
> Key: CASSANDRA-19858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19858
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> gocql does not currently allow MutualTlsWithPasswordFallbackAuthenticator or
> MutualTlsAuthenticator on connection users will see an error like:
> {code}
> unexpected authenticator
> "org.apache.cassandra.auth.MutualTlsWithPasswordFallbackAuthenticator"
> {code}
> Update {{defaultApprovedAuthenticators}} in {{conn.go}} to include both
> authenticators.
> While it doesn't make a lot of sense for {{MutualTlsAuthenticator}} to be
> present here, it should be harmless to include it and it may be useful if we
> ever intend on making {{MutualTlsAuthenticator}} also require credentials.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19858) gocql: Add MutualTls authenticators to defaultApprovedAuthenticators
[
https://issues.apache.org/jira/browse/CASSANDRA-19858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19858:
-
Source Control Link:
https://github.com/apache/cassandra-gocql-driver/pull/1800
> gocql: Add MutualTls authenticators to defaultApprovedAuthenticators
>
>
> Key: CASSANDRA-19858
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19858
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> gocql does not currently allow MutualTlsWithPasswordFallbackAuthenticator or
> MutualTlsAuthenticator on connection users will see an error like:
> {code}
> unexpected authenticator
> "org.apache.cassandra.auth.MutualTlsWithPasswordFallbackAuthenticator"
> {code}
> Update {{defaultApprovedAuthenticators}} in {{conn.go}} to include both
> authenticators.
> While it doesn't make a lot of sense for {{MutualTlsAuthenticator}} to be
> present here, it should be harmless to include it and it may be useful if we
> ever intend on making {{MutualTlsAuthenticator}} also require credentials.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19859) gocql: Don't restrict server authenticator unless PasswordAuthentictor.AllowedAuthenticators is provided
[
https://issues.apache.org/jira/browse/CASSANDRA-19859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19859:
-
Source Control Link:
https://github.com/apache/cassandra-gocql-driver/pull/1801
> gocql: Don't restrict server authenticator unless
> PasswordAuthentictor.AllowedAuthenticators is provided
>
>
> Key: CASSANDRA-19859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19859
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> Currently gocql will only allow authenticating with authenticators defined in
> {{defaultApprovedAuthenticators}} in {{conn.go}}.
> There have been multiple occurrences of implementers needing to update this
> list, either when a vendor would like to add their authenticator, or a new
> authenticator being added, e.g.: [CASSANDRA-19858]
> examples:
> https://github.com/apache/cassandra-gocql-driver/pull/883
> https://github.com/apache/cassandra-gocql-driver/pull/1254
> https://github.com/apache/cassandra-gocql-driver/pull/1321
> https://github.com/apache/cassandra-gocql-driver/pull/1379
> I think it would probably reduce friction to just accept any authenticator
> provided by the server. From what I know, other drivers behave in this way.
> If a user wanted to restrict this, they could use the existing configuration
> {{PasswordAuthenticator.AllowedAuthenticators}}, e.g.:
> {code}
> cluster.Authenticator = PasswordAuthenticator{
> Username: x,
> Password: x,
> AllowedAuthenticators: []string {
> "myrandomauth",
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19859) gocql: Don't restrict server authenticator unless PasswordAuthentictor.AllowedAuthenticators is provided
[
https://issues.apache.org/jira/browse/CASSANDRA-19859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert reassigned CASSANDRA-19859:
Assignee: Andy Tolbert
> gocql: Don't restrict server authenticator unless
> PasswordAuthentictor.AllowedAuthenticators is provided
>
>
> Key: CASSANDRA-19859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19859
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> Currently gocql will only allow authenticating with authenticators defined in
> {{defaultApprovedAuthenticators}} in {{conn.go}}.
> There have been multiple occurrences of implementers needing to update this
> list, either when a vendor would like to add their authenticator, or a new
> authenticator being added, e.g.: [CASSANDRA-19858]
> examples:
> https://github.com/apache/cassandra-gocql-driver/pull/883
> https://github.com/apache/cassandra-gocql-driver/pull/1254
> https://github.com/apache/cassandra-gocql-driver/pull/1321
> https://github.com/apache/cassandra-gocql-driver/pull/1379
> I think it would probably reduce friction to just accept any authenticator
> provided by the server. From what I know, other drivers behave in this way.
> If a user wanted to restrict this, they could use the existing configuration
> {{PasswordAuthenticator.AllowedAuthenticators}}, e.g.:
> {code}
> cluster.Authenticator = PasswordAuthenticator{
> Username: x,
> Password: x,
> AllowedAuthenticators: []string {
> "myrandomauth",
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19859) gocql: Don't restrict server authenticator unless PasswordAuthentictor.AllowedAuthenticators is provided
[
https://issues.apache.org/jira/browse/CASSANDRA-19859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17876554#comment-17876554
]
Andy Tolbert commented on CASSANDRA-19859:
--
Thanks [~djoshi]! That sounds reasonable, will do this tomorrow morning.
> gocql: Don't restrict server authenticator unless
> PasswordAuthentictor.AllowedAuthenticators is provided
>
>
> Key: CASSANDRA-19859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19859
> Project: Cassandra
> Issue Type: Improvement
> Components: Client/gocql-driver
>Reporter: Andy Tolbert
>Priority: Normal
>
> Currently gocql will only allow authenticating with authenticators defined in
> {{defaultApprovedAuthenticators}} in {{conn.go}}.
> There have been multiple occurrences of implementers needing to update this
> list, either when a vendor would like to add their authenticator, or a new
> authenticator being added, e.g.: [CASSANDRA-19858]
> examples:
> https://github.com/apache/cassandra-gocql-driver/pull/883
> https://github.com/apache/cassandra-gocql-driver/pull/1254
> https://github.com/apache/cassandra-gocql-driver/pull/1321
> https://github.com/apache/cassandra-gocql-driver/pull/1379
> I think it would probably reduce friction to just accept any authenticator
> provided by the server. From what I know, other drivers behave in this way.
> If a user wanted to restrict this, they could use the existing configuration
> {{PasswordAuthenticator.AllowedAuthenticators}}, e.g.:
> {code}
> cluster.Authenticator = PasswordAuthenticator{
> Username: x,
> Password: x,
> AllowedAuthenticators: []string {
> "myrandomauth",
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19859) gocql: Don't restrict server authenticator unless PasswordAuthentictor.AllowedAuthenticators is provided
Andy Tolbert created CASSANDRA-19859:
Summary: gocql: Don't restrict server authenticator unless
PasswordAuthentictor.AllowedAuthenticators is provided
Key: CASSANDRA-19859
URL: https://issues.apache.org/jira/browse/CASSANDRA-19859
Project: Cassandra
Issue Type: Improvement
Components: Client/gocql-driver
Reporter: Andy Tolbert
Currently gocql will only allow authenticating with authenticators defined in
{{defaultApprovedAuthenticators}} in {{conn.go}}.
There have been multiple occurrences of implementers needing to update this
list, either when a vendor would like to add their authenticator, or a new
authenticator being added, e.g.: [CASSANDRA-19858]
examples:
https://github.com/apache/cassandra-gocql-driver/pull/883
https://github.com/apache/cassandra-gocql-driver/pull/1254
https://github.com/apache/cassandra-gocql-driver/pull/1321
https://github.com/apache/cassandra-gocql-driver/pull/1379
I think it would probably reduce friction to just accept any authenticator
provided by the server. From what I know, other drivers behave in this way.
If a user wanted to restrict this, they could use the existing configuration
{{PasswordAuthenticator.AllowedAuthenticators}}, e.g.:
{code}
cluster.Authenticator = PasswordAuthenticator{
Username: x,
Password: x,
AllowedAuthenticators: []string {
"myrandomauth",
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19858) gocql: Add MutualTls authenticators to defaultApprovedAuthenticators
Andy Tolbert created CASSANDRA-19858:
Summary: gocql: Add MutualTls authenticators to
defaultApprovedAuthenticators
Key: CASSANDRA-19858
URL: https://issues.apache.org/jira/browse/CASSANDRA-19858
Project: Cassandra
Issue Type: Improvement
Components: Client/gocql-driver
Reporter: Andy Tolbert
Assignee: Andy Tolbert
gocql does not currently allow MutualTlsWithPasswordFallbackAuthenticator or
MutualTlsAuthenticator on connection users will see an error like:
{code}
unexpected authenticator
"org.apache.cassandra.auth.MutualTlsWithPasswordFallbackAuthenticator"
{code}
Update {{defaultApprovedAuthenticators}} in {{conn.go}} to include both
authenticators.
While it doesn't make a lot of sense for {{MutualTlsAuthenticator}} to be
present here, it should be harmless to include it and it may be useful if we
ever intend on making {{MutualTlsAuthenticator}} also require credentials.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19669) Audit Log entries are missing identity for mTLS connections
[
https://issues.apache.org/jira/browse/CASSANDRA-19669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17853792#comment-17853792
]
Andy Tolbert commented on CASSANDRA-19669:
--
+1, PR looks great, thank you Francisco!
> Audit Log entries are missing identity for mTLS connections
> ---
>
> Key: CASSANDRA-19669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19669
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Francisco Guerrero
>Assignee: Francisco Guerrero
>Priority: Normal
> Fix For: 5.1
>
> Attachments: ci_summary-1.html, ci_summary.html
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> Audit log entries are missing the {{IDENTITY}} when an mTLS connection is
> established. Currently, the client state is captured as part of the audit log
> entries, however the additional metadata for the authenticated user does not
> get propagated to the entry. For the mTLS connections, this means that the
> identity information is not included to the log entry details.
> Additionally, when a TLS connection is terminated during handshake (say a
> client is using an expired certificate) the error is not propagated to the
> audit log failure attempts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17824985#comment-17824985 ] Andy Tolbert commented on CASSANDRA-15349: -- I think this would be a great candidate to track around future protocol improvements ([CASSANDRA-18478]) as it can really improve application behavior around cluster bounces. > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19399) Zombie repair session blocks further incremental repairs due to SSTable lock
[
https://issues.apache.org/jira/browse/CASSANDRA-19399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817476#comment-17817476
]
Andy Tolbert commented on CASSANDRA-19399:
--
Could this be the same as [CASSANDRA-19182]?
> Zombie repair session blocks further incremental repairs due to SSTable lock
>
>
> Key: CASSANDRA-19399
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19399
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Repair
>Reporter: Sebastian Marsching
>Priority: Normal
> Fix For: 4.1.x
>
> Attachments: system.log.txt
>
>
> We have experienced the following bug in C* 4.1.3 at least twice:
> Somtimes, a failed incremental repair session keeps future incremental repair
> sessions from running. These future sessions fail with the following message
> in the log file:
> {code:java}
> PendingAntiCompaction.java:210 - Prepare phase for incremental repair session
> c8b65260-cb53-11ee-a219-3d5d7e5cdec7 has failed because it encountered
> intersecting sstables belonging to another incremental repair session
> (02d7c1a0-cb3a-11ee-aa89-a1b2ad548382). This is caused by starting an
> incremental repair session before a previous one has completed. Check
> nodetool repair_admin for hung sessions and fix them. {code}
> This happens, even though there are no active repair sessions on any node
> ({{{}nodetool repair_admin list{}}} prints {{{}no sessions{}}}).
> When running {{{}nodetool repair_admin list --all{}}}, the offending session
> is listed as failed:
> {code:java}
> id | state | last activity |
> coordinator | participants
>
>
>
>
>
>
> | participants_wp
>
>
>
>
>
>
>
>
>
>
> 02d7c1a0-cb3a-11ee-aa89-a1b2ad548382 | FAILED | 5454 (s) |
> /192.168.108.235:7000 |
> 192.168.108.224,192.168.108.96,192.168.108.97,192.168.108.225,192.168.108.226,192.168.108.98,192.168.108.99,192.168.108.227,192.168.108.100,192.168.108.228,192.168.108.229,192.168.108.101,192.168.108.230,192.168.108.102,192.168.108.103,192.168.108.231,192.168.108.221,192.168.108.94,192.168.108.222,192.168.108.95,192.168.108.223,192.168.108.241,192.168.108.242,192.168.108.243,192.168.108.244,192.168.108.104,192.168.108.105,192.168.108.235
>
> {code}
> This still happens after canceling the repair session, regardless of whether
> it is canceled on the coordinator node or on all nodes (using
> {{{}--force{}}}).
> I attached all lines from the C* system log that refer to the offending
> session. It seems like another repair session was started while this session
> was still running (possibly due to a bug in Cassandra Reaper), but the
> session was failed right after that but still seems to hold a lock on some of
> the SSTables.
> The problem can be resolved by restarting the nodes affected by this (which
> typically means doing a rolling restart of the whole cluster), but this is
> obviously not ideal...
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17817112#comment-17817112
]
Andy Tolbert commented on CASSANDRA-19366:
--
Thank you [~smiklosovic] and [~frankgh] for all of your help in reviewing and
getting this committed!
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 4h
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19388) Incorrect connected node metric when session is closed and reinitted in same JVM
[ https://issues.apache.org/jira/browse/CASSANDRA-19388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816807#comment-17816807 ] Andy Tolbert commented on CASSANDRA-19388: -- I realized i'm mixing up concepts with the 3.x driver (there is no CqlCluster in 4.x). Do you have a test case or example that can reproduce this? > Incorrect connected node metric when session is closed and reinitted in same > JVM > > > Key: CASSANDRA-19388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19388 > Project: Cassandra > Issue Type: Bug > Components: Client/java-driver >Reporter: Nitin Chhabra >Assignee: Henry Hughes >Priority: Normal > > We observed incorrect connected nodes metric reported when session is closed > and re-initted. > *Setup* > Java 8 > Java Driver Version: 4.15.0 > Cassandra Server: 4.X > 3 nodes in Azure West > > *Steps to reproduce the issue* > # Init the CQLSession successfully. > # Observe the connected nodes metric is 3. > # Stop the session gracefully by calling: session.closeAsync() and wait for > few seconds for close. > # _Reinit the CQLSession and monitor the connected nodes metric. It goes > down to 1._ > > *Triage/Troubleshooting* > On Cassandra Server side, we can observe connections made to all 3 nodes. > Upon further debugging by putting some log statements and modifying the > driver, it appears the NodeStateManager updates its open connection count to > 3, however MetaDataManager does not show all 3 nodes have active connections. > Please let me know if more info is needed. > > Also, had initiated similar discussion in Open Src Community: > [https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer|https://urldefense.com/v3/__https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer__;!!IfjTnhH9!XpuIqw-OxNBAy2e4AVXzpwJwHST0C5CevI9NQGMGp54QUFPJGFCt5PZF527PRMYABto_Dwk03Pwb1dNSEgcLatnsOQ$]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19388) Incorrect connected node metric when session is closed and reinitted in same JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816802#comment-17816802
]
Andy Tolbert edited comment on CASSANDRA-19388 at 2/12/24 10:09 PM:
The driver maintains a 'control connection' that is tied to the {{CqlCluster}}.
When you close a session, this connection remains open, is it possible thats
what is going on here?
was (Author: andrew.tolbert):
The driver maintains a 'control connection' that is tied to the \{CqlCluster}.
When you close a session, this connection remains open, is it possible thats
what is going on here?
> Incorrect connected node metric when session is closed and reinitted in same
> JVM
>
>
> Key: CASSANDRA-19388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19388
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Nitin Chhabra
>Assignee: Henry Hughes
>Priority: Normal
>
> We observed incorrect connected nodes metric reported when session is closed
> and re-initted.
> *Setup*
> Java 8
> Java Driver Version: 4.15.0
> Cassandra Server: 4.X
> 3 nodes in Azure West
>
> *Steps to reproduce the issue*
> # Init the CQLSession successfully.
> # Observe the connected nodes metric is 3.
> # Stop the session gracefully by calling: session.closeAsync() and wait for
> few seconds for close.
> # _Reinit the CQLSession and monitor the connected nodes metric. It goes
> down to 1._
>
> *Triage/Troubleshooting*
> On Cassandra Server side, we can observe connections made to all 3 nodes.
> Upon further debugging by putting some log statements and modifying the
> driver, it appears the NodeStateManager updates its open connection count to
> 3, however MetaDataManager does not show all 3 nodes have active connections.
> Please let me know if more info is needed.
>
> Also, had initiated similar discussion in Open Src Community:
> [https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer|https://urldefense.com/v3/__https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer__;!!IfjTnhH9!XpuIqw-OxNBAy2e4AVXzpwJwHST0C5CevI9NQGMGp54QUFPJGFCt5PZF527PRMYABto_Dwk03Pwb1dNSEgcLatnsOQ$].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19388) Incorrect connected node metric when session is closed and reinitted in same JVM
[
https://issues.apache.org/jira/browse/CASSANDRA-19388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17816802#comment-17816802
]
Andy Tolbert commented on CASSANDRA-19388:
--
The driver maintains a 'control connection' that is tied to the \{CqlCluster}.
When you close a session, this connection remains open, is it possible thats
what is going on here?
> Incorrect connected node metric when session is closed and reinitted in same
> JVM
>
>
> Key: CASSANDRA-19388
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19388
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Nitin Chhabra
>Assignee: Henry Hughes
>Priority: Normal
>
> We observed incorrect connected nodes metric reported when session is closed
> and re-initted.
> *Setup*
> Java 8
> Java Driver Version: 4.15.0
> Cassandra Server: 4.X
> 3 nodes in Azure West
>
> *Steps to reproduce the issue*
> # Init the CQLSession successfully.
> # Observe the connected nodes metric is 3.
> # Stop the session gracefully by calling: session.closeAsync() and wait for
> few seconds for close.
> # _Reinit the CQLSession and monitor the connected nodes metric. It goes
> down to 1._
>
> *Triage/Troubleshooting*
> On Cassandra Server side, we can observe connections made to all 3 nodes.
> Upon further debugging by putting some log statements and modifying the
> driver, it appears the NodeStateManager updates its open connection count to
> 3, however MetaDataManager does not show all 3 nodes have active connections.
> Please let me know if more info is needed.
>
> Also, had initiated similar discussion in Open Src Community:
> [https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer|https://urldefense.com/v3/__https://groups.google.com/a/lists.datastax.com/g/java-driver-user/c/VoPOha4Oc0c/m/IDCVAREMAgAJ?utm_medium=email&utm_source=footer__;!!IfjTnhH9!XpuIqw-OxNBAy2e4AVXzpwJwHST0C5CevI9NQGMGp54QUFPJGFCt5PZF527PRMYABto_Dwk03Pwb1dNSEgcLatnsOQ$].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815726#comment-17815726
]
Andy Tolbert edited comment on CASSANDRA-19366 at 2/8/24 3:45 PM:
--
{quote}
Then it will print it twice, once as if it is with --all and the second time as
if it is with --verbose. Could we do it in such a way that when --all is
specified together with --verbose, we just set --all to false so --verbose will
print it just once? I consider --verbose to be a super set of --all as it will
print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{\-\-metadata \-\-all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{--verbose}}, I will change this.
{quote}
I also want to ask about the metadata. Is this something which is going to
expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this
is a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this
shortly.
was (Author: andrew.tolbert):
{quote}
Then it will print it twice, once as if it is with --all and the second time as
if it is with --verbose. Could we do it in such a way that when --all is
specified together with --verbose, we just set --all to false so --verbose will
print it just once? I consider --verbose to be a super set of --all as it will
print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{--metadata --all}} would interact with each
other previously, but I agree it shouldn't work this way with {{--verbose}}, I
will change this.
{quote}
I also want to ask about the metadata. Is this something which is going to
expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this
is a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this
shortly.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much
[jira] [Comment Edited] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815726#comment-17815726
]
Andy Tolbert edited comment on CASSANDRA-19366 at 2/8/24 3:46 PM:
--
{quote}Then it will print it twice, once as if it is with --all and the second
time as if it is with --verbose. Could we do it in such a way that when --all
is specified together with --verbose, we just set --all to false so --verbose
will print it just once? I consider --verbose to be a super set of --all as it
will print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{\-\-client-options \-\-all}} would interact
with each other previously, but I agree it shouldn't work this way with
{{{}--verbose{}}}, I will change this.
{quote}I also want to ask about the metadata. Is this something which is going
to expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this is
a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this shortly.
was (Author: andrew.tolbert):
{quote}Then it will print it twice, once as if it is with --all and the second
time as if it is with --verbose. Could we do it in such a way that when --all
is specified together with --verbose, we just set --all to false so --verbose
will print it just once? I consider --verbose to be a super set of --all as it
will print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{--client-options --all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{{}--verbose{}}}, I will change this.
{quote}I also want to ask about the metadata. Is this something which is going
to expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this is
a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this shortly.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
[jira] [Comment Edited] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815726#comment-17815726
]
Andy Tolbert edited comment on CASSANDRA-19366 at 2/8/24 3:46 PM:
--
{quote}Then it will print it twice, once as if it is with --all and the second
time as if it is with --verbose. Could we do it in such a way that when --all
is specified together with --verbose, we just set --all to false so --verbose
will print it just once? I consider --verbose to be a super set of --all as it
will print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{--client-options --all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{{}--verbose{}}}, I will change this.
{quote}I also want to ask about the metadata. Is this something which is going
to expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this is
a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this shortly.
was (Author: andrew.tolbert):
{quote}
Then it will print it twice, once as if it is with --all and the second time as
if it is with --verbose. Could we do it in such a way that when --all is
specified together with --verbose, we just set --all to false so --verbose will
print it just once? I consider --verbose to be a super set of --all as it will
print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{\-\-metadata \-\-all}} would interact with
each other previously, but I agree it shouldn't work this way with
{{--verbose}}, I will change this.
{quote}
I also want to ask about the metadata. Is this something which is going to
expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this
is a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this
shortly.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much lik
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815726#comment-17815726
]
Andy Tolbert commented on CASSANDRA-19366:
--
{quote}
Then it will print it twice, once as if it is with --all and the second time as
if it is with --verbose. Could we do it in such a way that when --all is
specified together with --verbose, we just set --all to false so --verbose will
print it just once? I consider --verbose to be a super set of --all as it will
print all what --all is printing, it will just print more details.
{quote}
Aha, good catch. This is the way {{--metadata --all}} would interact with each
other previously, but I agree it shouldn't work this way with {{--verbose}}, I
will change this.
{quote}
I also want to ask about the metadata. Is this something which is going to
expose security-sensitive information? What metadata we can expect there? I
want to prevent situations when somebody looks into nodetool / cqlsh and there
something will be leaked we should not see.
{quote}
With the provided authenticators, it will not expose anything sensitive.
Currently only MutualTls authed connections will include any metadata, which
will include the extracted identity used to validate the user. I think this
is a valid concern though, and we should document that the contents of metadata
are exposed in various tooling. I'll add some documentation around this
shortly.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to tra
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Description:
CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
which enables Cassandra to support either password and mTLS-authenticated
connections.
As an operator, it would be useful to know which connections are mTLS
authenticated, and which are password authenticated, as a possible mode of
operation is migrating users from one from of authentication to another. It
would also be useful to know if that if authentication attempts are failing
which mode of authentication is unsuccessful.
Proposing to add the following:
* Add a {{mode: string}} and {{metadata: map}} to
{{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
{{metadata}} map (e.g. this can include the extracted {{identity}} from a
client certificate for {{mtls}} authentication).
* Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
added to existing output to maintain compatibility, much like
{{-client-options}} did.
* Update {{system_views.clients}} to include columns for these new fields.
* Add new metrics to {{{}ClientMetrics{}}}:
** Track authentication success and failures by mode. (Note: The metrics
present by authentication mode scope are contextual based on the Authenticator
used (e.g. only {{scope=Password}} will be present for
{{{}PasswordAuthenticator{}}})
{noformat}
Existing:
org.apache.cassandra.metrics:name=AuthSuccess,type=Client
org.apache.cassandra.metrics:name=AuthFailure,type=Client
New:
org.apache.cassandra.metrics:name=AuthSuccess,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
{noformat}
*
** Track connection counts by mode:
{noformat}
Existing:
org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
(previously deprecated but still maintained)
New:
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=MutualTls,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
{noformat}
*
** A metric to track encrypted vs. non-encrypted connections:
{noformat}
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
{noformat}
was:
CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
which enables Cassandra to support either password and mTLS-authenticated
connections.
As an operator, it would be useful to know which connections are mTLS
authenticated, and which are password authenticated, as a possible mode of
operation is migrating users from one from of authentication to another. It
would also be useful to know if that if authentication attempts are failing
which mode of authentication is unsuccessful.
Proposing to add the following:
* Add a {{mode: string}} and {{metadata: map}} to
{{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
{{metadata}} map (e.g. this can include the extracted {{identity}} from a
client certificate for {{mtls}} authentication).
* Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
added to existing output to maintain compatibility, much like
{{-client-options}} did.
* Update {{system_views.clients}} to include columns for these new fields.
* Add new metrics to {{{}ClientMetrics{}}}:
** Track authentication success and failures by mode. (Note: The metrics
present by authentication mode scope are contextual based on the Authenticator
used (e.g. only {{scope=Password}} will be present for
{{{}PasswordAuthenticator{}}})
{noformat}
Existing:
org.apache.cassandra.metrics:name=AuthSuccess,type=Client
org.apache.cassandra.metrics:name=AuthFailure,type=Client
New:
org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
{noformat}
*
** Track connection counts by mode:
{noformat}
E
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17815515#comment-17815515
]
Andy Tolbert commented on CASSANDRA-19366:
--
Thank you [~smiklosovic] and [~frankgh] for reviewing! Attached is a test run
from the latest commit
([ea6e2fd|https://github.com/apache/cassandra/pull/3085/commits/ea6e2fdc1db13996248e8f4ea9ce4dad34d85e23])
[^CASSANDRA-19366-trunk-6_ci_summary.html][^CASSANDRA-19366-trunk-1_test_results.tgz]which
came back clean except for
{{org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest#updateTest-_jdk11}}
which should be fixed by [CASSANDRA-19168].
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-6_ci_summary.html
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results-1.tgz
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results-1.tgz,
> CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html,
> CASSANDRA-19366-trunk-6_ci_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Reviewers: Francisco Guerrero, Stefan Miklosovic (was: Stefan Miklosovic)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814475#comment-17814475
]
Andy Tolbert commented on CASSANDRA-19366:
--
awesome, thank you [~smiklosovic] ! I see you had some feedback already,
appreciate you taking a look, I'll take a look at your comments and make
changes this afternoon.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814446#comment-17814446
]
Andy Tolbert commented on CASSANDRA-19366:
--
Thanks [~frankgh] !
I've included my Pull Request which I will move out of Draft shortly.
Attached are the test results
[^CASSANDRA-19366-trunk-1_test_results_summary.html] /
[^CASSANDRA-19366-trunk-1_test_results.tgz]
The tests that failed were:
org.apache.cassandra.index.sai.cql.VectorUpdateDeleteTest#updateTest-_jdk11
(maybe connected to CASSANDRA-19168 which was recently fixed, investigating why
it still fails)
org.apache.cassandra.db.compaction.CompactionStrategyManagerTest
testAutomaticUpgradeConcurrency-_jdk11 (likely unconnected, also investigating)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: (was: CASSANDRA-19366-trunk-1_test_results.tgz)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results.tgz
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results_summary.html
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz,
> CASSANDRA-19366-trunk-1_test_results_summary.html
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: (was: ci_summary.html)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: ci_summary.html
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results.tgz
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: (was: CASSANDRA-19366-trunk-1_test_results.tgz)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Attachment: CASSANDRA-19366-trunk-1_test_results.tgz
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
> Attachments: CASSANDRA-19366-trunk-1_test_results.tgz
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Impacts: Docs (was: None)
Test and Documentation Plan:
Updated existing tests around nodetool clientstats and added a
\{{ClientMetricsTest}} that tests the existing metrics for
ConnectedClients,AuthSuccess,AuthFailure and the new metrics I added.
I ran utests and dtests against this branch and it came back clean with
exception to two likely unrelated tests which I'll capture in comments.
Status: Patch Available (was: Open)
Pull Request available at: [https://github.com/apache/cassandra/pull/3085]
I've marked this as Docs impacting as I've added new metrics. I have updated
the metrics.adoc file to include the new metrics in addition to existing ones
that weren't documented.
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
[
https://issues.apache.org/jira/browse/CASSANDRA-19366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19366:
-
Change Category: Operability
Complexity: Normal
Fix Version/s: 5.1
Assignee: Andy Tolbert
Status: Open (was: Triage Needed)
> Expose mode of authentication in system_views.clients, nodetool clientstats,
> and ClientMetrics
> --
>
> Key: CASSANDRA-19366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption, Messaging/Client, Observability/JMX,
> Observability/Metrics, Tool/nodetool
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 5.1
>
>
> CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
> contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
> which enables Cassandra to support either password and mTLS-authenticated
> connections.
> As an operator, it would be useful to know which connections are mTLS
> authenticated, and which are password authenticated, as a possible mode of
> operation is migrating users from one from of authentication to another. It
> would also be useful to know if that if authentication attempts are failing
> which mode of authentication is unsuccessful.
> Proposing to add the following:
> * Add a {{mode: string}} and {{metadata: map}} to
> {{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
> to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
> {{metadata}} map (e.g. this can include the extracted {{identity}} from a
> client certificate for {{mtls}} authentication).
> * Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
> which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
> added to existing output to maintain compatibility, much like
> {{-client-options}} did.
> * Update {{system_views.clients}} to include columns for these new fields.
> * Add new metrics to {{{}ClientMetrics{}}}:
> ** Track authentication success and failures by mode. (Note: The metrics
> present by authentication mode scope are contextual based on the
> Authenticator used (e.g. only {{scope=Password}} will be present for
> {{{}PasswordAuthenticator{}}})
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=AuthSuccess,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,type=Client
> New:
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
> {noformat}
> *
> ** Track connection counts by mode:
> {noformat}
> Existing:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
> org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
> (previously deprecated but still maintained)
> New:
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
> {noformat}
> *
> ** A metric to track encrypted vs. non-encrypted connections:
> {noformat}
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
> org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19366) Expose mode of authentication in system_views.clients, nodetool clientstats, and ClientMetrics
Andy Tolbert created CASSANDRA-19366:
Summary: Expose mode of authentication in system_views.clients,
nodetool clientstats, and ClientMetrics
Key: CASSANDRA-19366
URL: https://issues.apache.org/jira/browse/CASSANDRA-19366
Project: Cassandra
Issue Type: Improvement
Components: Feature/Encryption, Messaging/Client, Observability/JMX,
Observability/Metrics, Tool/nodetool
Reporter: Andy Tolbert
CASSANDRA-18554 added support for mTLS-authenticated clients. Part of this
contribution introduced {{{}MutualTlsWithPasswordFallbackAuthenticator{}}},
which enables Cassandra to support either password and mTLS-authenticated
connections.
As an operator, it would be useful to know which connections are mTLS
authenticated, and which are password authenticated, as a possible mode of
operation is migrating users from one from of authentication to another. It
would also be useful to know if that if authentication attempts are failing
which mode of authentication is unsuccessful.
Proposing to add the following:
* Add a {{mode: string}} and {{metadata: map}} to
{{{}AuthenticatedUser{}}}. Update existing {{IAuthenticator}} implementations
to pass {{mode}} (e.g. {{password}} , {{{}mtls{}}}), and optionally pass a
{{metadata}} map (e.g. this can include the extracted {{identity}} from a
client certificate for {{mtls}} authentication).
* Update nodetool clientstats to add a new option flag {{{}--metadata{}}},
which when passed exposes these new fields on {{{}AuthenticatedUser{}}}. (Not
added to existing output to maintain compatibility, much like
{{-client-options}} did.
* Update {{system_views.clients}} to include columns for these new fields.
* Add new metrics to {{{}ClientMetrics{}}}:
** Track authentication success and failures by mode. (Note: The metrics
present by authentication mode scope are contextual based on the Authenticator
used (e.g. only {{scope=Password}} will be present for
{{{}PasswordAuthenticator{}}})
{noformat}
Existing:
org.apache.cassandra.metrics:name=AuthSuccess,type=Client
org.apache.cassandra.metrics:name=AuthFailure,type=Client
New:
org.apache.cassandra.metrics:name=AuthSuccess,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthSuccess,scope=Password,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=AuthFailure,scope=Password,type=Client
{noformat}
*
** Track connection counts by mode:
{noformat}
Existing:
org.apache.cassandra.metrics:name=ConnectedNativeClients,type=Client
org.apache.cassandra.metrics:name=connectedNativeClients,type=Client
(previously deprecated but still maintained)
New:
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Mtls,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Password,type=Client
{noformat}
*
** A metric to track encrypted vs. non-encrypted connections:
{noformat}
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Encrypted,type=Client
org.apache.cassandra.metrics:name=ConnectedNativeClients,scope=Unencrypted,type=Client
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810033#comment-17810033
]
Andy Tolbert commented on CASSANDRA-19276:
--
I haven't given up on this quite yet, experimenting if I can make a custom
LeftCurly option, similar to what folks desire here:
[https://github.com/checkstyle/checkstyle/issues/12226|https://github.com/checkstyle/checkstyle/issues/12226.]
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19290:
-
Test and Documentation Plan: While the change is somewhat straightforward,
i'd like to run the full integration test at least locally, and also
familiarize myself with whatever testing options we have for the driver.
Status: Patch Available (was: Open)
patch available at: [https://github.com/apache/cassandra-java-driver/pull/1908]
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19290:
-
Bug Category: Parent values: Code(13163)Level 1 values: Bug - Unclear
Impact(13164)
Complexity: Low Hanging Fruit
Discovered By: User Report
Severity: Low
Status: Open (was: Triage Needed)
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
Andy Tolbert created CASSANDRA-19290:
Summary: Replace uses of AttributeKey.newInstance with
AttributeKey.valueOf in cassandra-java-driver
Key: CASSANDRA-19290
URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
Project: Cassandra
Issue Type: Bug
Components: Client/java-driver
Reporter: Andy Tolbert
Assignee: Henry Hughes
The java driver uses netty channel attributes to decorate a connection's
channel with the cluster name (returned from the system.local table) and the
map from the {{OPTIONS}} response, both of which are obtained on connection
initialization.
There's an issue here that I wouldn't expect to see in practice in that the
{{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
throws an exception if an {{AttributeKey}} of that name is defined anywhere
else in evaluated code.
https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
{code:java}
static final AttributeKey CLUSTER_NAME_KEY =
AttributeKey.newInstance("cluster_name");
static final AttributeKey>> OPTIONS_KEY =
AttributeKey.newInstance("options");
{code}
This was encountered by a user that was creating driver connections within a
trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
{noformat}
Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
already in use
at
io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
at
com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
... 30 common frames omitted
{noformat}
There is likely some class loading oddness in the Trigger implementation that
exacerbates the problem. But at the least, if the driver were to use
AttributeKey.valueOf instead (like Cassandra does where it uses them:
https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
this particular issue could be avoided.
Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as a
way of namespacing the attribute (e.g.
{{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
"cluster_name");}}, this does not seem necessary though.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19290) Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in cassandra-java-driver
[
https://issues.apache.org/jira/browse/CASSANDRA-19290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert reassigned CASSANDRA-19290:
Assignee: Andy Tolbert (was: Henry Hughes)
> Replace uses of AttributeKey.newInstance with AttributeKey.valueOf in
> cassandra-java-driver
> ---
>
> Key: CASSANDRA-19290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19290
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> The java driver uses netty channel attributes to decorate a connection's
> channel with the cluster name (returned from the system.local table) and the
> map from the {{OPTIONS}} response, both of which are obtained on connection
> initialization.
> There's an issue here that I wouldn't expect to see in practice in that the
> {{AttributeKey}}'s used are created using {{AttributeKey.newInstance}}, which
> throws an exception if an {{AttributeKey}} of that name is defined anywhere
> else in evaluated code.
> https://github.com/apache/cassandra-java-driver/blob/8d5849cb38995b312f29314d18256c0c3e94cf07/core/src/main/java/com/datastax/oss/driver/internal/core/channel/DriverChannel.java#L52-L54
> {code:java}
> static final AttributeKey CLUSTER_NAME_KEY =
> AttributeKey.newInstance("cluster_name");
> static final AttributeKey>> OPTIONS_KEY =
> AttributeKey.newInstance("options");
> {code}
> This was encountered by a user that was creating driver connections within a
> trigger: https://the-asf.slack.com/archives/CJZLTM05A/p1705537114305579
> {noformat}
> Caused by: java.lang.IllegalArgumentException: 'cluster_name' is
> already in use
> at
> io.netty.util.ConstantPool.createOrThrow(ConstantPool.java:109)
> at io.netty.util.ConstantPool.newInstance(ConstantPool.java:91)
> at io.netty.util.AttributeKey.newInstance(AttributeKey.java:55)
> at
> com.datastax.oss.driver.internal.core.channel.DriverChannel.(DriverChannel.java:50)
> ... 30 common frames omitted
> {noformat}
> There is likely some class loading oddness in the Trigger implementation that
> exacerbates the problem. But at the least, if the driver were to use
> AttributeKey.valueOf instead (like Cassandra does where it uses them:
> https://github.com/search?q=repo%3Aapache%2Fcassandra+AttributeKey.valueOf&type=code),
> this particular issue could be avoided.
> Debatably we could use {{valueOf(firstNameComponent,secondNameComponent)}} as
> a way of namespacing the attribute (e.g.
> {{AttributeKey.newInstance("com.datastax.oss.driver.internal.core.channel",
> "cluster_name");}}, this does not seem necessary though.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808844#comment-17808844
]
Andy Tolbert commented on CASSANDRA-19276:
--
I think what we really need is for {{LeftCurly}} to have an option like
{{RightCurly}}'s {{alone_or_singleline}} which specifies:
{quote}
The brace must be alone on the line, yet single-line format of block is allowed.
{quote}
will see if anyone has ever requested that; or if something maybe feasible to
add there
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808819#comment-17808819
]
Andy Tolbert edited comment on CASSANDRA-19276 at 1/19/24 10:56 PM:
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow {
to exist in the same way, i'll test that out as if we can make that work it'd
cut the number of violations significantly.
was (Author: andrew.tolbert):
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{{}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808819#comment-17808819
]
Andy Tolbert edited comment on CASSANDRA-19276 at 1/19/24 10:56 PM:
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{{}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
was (Author: andrew.tolbert):
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{{}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808819#comment-17808819
]
Andy Tolbert edited comment on CASSANDRA-19276 at 1/19/24 10:55 PM:
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{{}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
was (Author: andrew.tolbert):
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{}}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808819#comment-17808819
]
Andy Tolbert commented on CASSANDRA-19276:
--
ah, interesting, let me see if I can use in conjunction. I think the rule will
allow {{}}} on the same line, but i'm not certain if it will by proxy allow
{{}}} to exist in the same way, i'll test that out as if we can make that work
it'd cut the number of violations significantly.
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808807#comment-17808807
]
Andy Tolbert commented on CASSANDRA-18857:
--
Thanks everyone! Test results attached, things came back mostly clean:
[^ci_summary.html]
[^result_details.tar.gz]
The failing tests appear to be unrelated/flakes:
* largecolumn_test.TestLargeColumn#test_cleanup - looks like a common flake
that has come up a number of times; I'll look into seeing if something i can
help with if not already handled, but high confidence it's not related to my
change.
*
upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_4_1_x_To_indev_trunk
test_bootstrap_multidc ([CASSANDRA-17893])
*
upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_4_1_x_To_indev_trunk
test_parallel_upgrade_with_internode_ssl ([CASSANDRA-17893])
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Attachment: ci_summary.html
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Attachment: result_details.tar.gz
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Attachments: ci_summary.html, result_details.tar.gz
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19276:
-
Change Category: Code Clarity
Complexity: Normal
Priority: Low (was: Normal)
Status: Open (was: Triage Needed)
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Low
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808442#comment-17808442
]
Andy Tolbert commented on CASSANDRA-19276:
--
added [^checkstyle_lcurly_output.zip] which contains some collected output that
may be useful
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-19276:
-
Attachment: checkstyle_lcurly_output.zip
> Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
> ---
>
> Key: CASSANDRA-19276
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Attachments: checkstyle_lcurly_output.zip
>
>
> It came up in a review that I had missed some style changes in
> [CASSANDRA-18857]
> (https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
> Chatting with [~smiklosovic] we agreed that it would be nice if we could
> enforce this in checkstyle, so we wouldn't need to be dependent on this being
> caught in review.
> The change for this is effectively:
> {code}
> index 8b81f21281..9bd22dc1ac 100644
> --- a/.build/checkstyle.xml
> +++ b/.build/checkstyle.xml
> @@ -179,6 +179,10 @@
> value="'Deprecated annotation must provide 'since' value."/>
>
> +
> +
> + value="ANNOTATION_DEF,CLASS_DEF,CTOR_DEF,ENUM_CONSTANT_DEF,INTERFACE_DEF,LITERAL_CASE,LITERAL_CATCH,LITERAL_DEFAULT,LITERAL_DO,LITERAL_ELSE,LITERAL_FINALLY,LITERAL_FOR,LITERAL_IF,LITERAL_SWITCH,LITERAL_SYNCHRONIZED,LITERAL_TRY,LITERAL_WHILE,METHOD_DEF,OBJBLOCK,STATIC_INIT,RECORD_DEF,COMPACT_CTOR_DEF"/>
> +
>
>
> {code}
> Notably, we would allow braces on the same lines for lambdas as per the
> [project
> guidelines|https://cassandra.apache.org/_/development/code_style.html] on
> code formatting:
> {quote}
> {{{}} and {{}}} are placed on a new line except when empty or opening a
> multi-line lambda expression. Braces may be elided to a depth of one if the
> condition or loop guards a single expression.
> {quote}
> There are 594 violations and 211 source files that would need to be adjusted.
> I may play with the rules a little bit more to get this right.
> I would like to propose that we change all files that are not imported from
> other projects (there are a few, such as
> src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
> changes for), but we would change others.
> I'll make a patch with the changes send a small proposal to the mailing list
> as it could be disruptive to make a bunch of tiny changes, and depending on
> timing there may be a better time to make a change like this.
> We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
[
https://issues.apache.org/jira/browse/CASSANDRA-19276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17808440#comment-17808440
]
Andy Tolbert commented on CASSANDRA-19276:
--
Did a quick analysis on how many violations currently exist, apparently I had
missed tests in my first analysis. Here is a break down of checkstyle errors by
token and whether I think they should be included (tokens defined
[here|https://checkstyle.sourceforge.io/checks/blocks/leftcurly.html]):
||Type||Src Errors||Errors||Include?||
|ANNOTATION_DEF|0|0|Yes|
|CLASS_DEF|8|28|Yes|
|CTOR_DEF|55|24|Yes|
|ENUM_CONSTANT_DEF|2|6|Yes|
|INTERFACE_DEF|4|15|Yes|
|LAMBDA|372|1719|No|
|LITERAL_CASE|0|2|Yes|
|LITERAL_CATCH|17|70|Yes|
|LITERAL_DEFAULT|0|0|Yes|
|LITERAL_DO|7|1|Yes|
|LITERAL_ELSE|13|11|Yes|
|LITERAL_FINALLY|1|13|Yes|
|LITERAL_FOR|13|41|Yes|
|LITERAL_IF|68|52|Yes|
|LITERAL_SWITCH|1|2|Yes|
|LITERAL_SYNCHRONIZED|2|0|Yes|
|LITERAL_TRY|19|63|Yes|
|LITERAL_WHILE|15|10|Yes|
|METHOD_DEF|302|408|Yes|
|OBJBLOCK|79|198|Yes|
|STATIC_INIT|3|3|Yes|
|RECORD_DEF|0|0|Yes|
|COMPACT_CTOR_DEF|0|0|Yes|
|*Total (excl LAMBDA)*|595|898|n/a|
(small note: that if you add the numbers up, they eclipse the "Total" because
there is some overlap in the rules, the "Total (excl LAMBDA)" value was
calculated by running with all tokens except lamdba included.)
A large amount of the violations are on METHOD_DEF (declaration of a method),
usually where a method is a single collapsed line, .e.g:
{code:java}
public int getActiveTaskCount(){ return 0; }
public long getCompletedTaskCount() { return 0; }
public int getPendingTaskCount() { return 0; }
public int getCorePoolSize() { return 0; }
public int getMaximumPoolSize(){ return 0; }{code}
We could consider leaving these as is, but it would also be low effort to
change them. Unfortunately I can't seem to find a way to allow this particular
use while also forbidding multi-line methods that have left braces in the
declaration line, but i'll keep looking.
A good deal of violations come from a small set of files. I would suggest for
files that were inline from elsewhere that we suppress checkstyle on them.
||count||file||Copied from elsewhere?||
|70|src/java/org/apache/cassandra/utils/LongTimSort.java|Yes|
|25|src/java/org/apache/cassandra/locator/ReplicaPlan.java|No|
|21|src/java/org/apache/cassandra/service/StorageProxy.java|No|
|16|src/java/org/apache/cassandra/utils/ByteArrayUtil.java|Partially|
|16|src/java/org/apache/cassandra/net/OutboundConnection.java|No|
|14|src/java/org/apache/cassandra/locator/AbstractReplicaCollection.java|No|
|13|src/java/org/apache/cassandra/service/paxos/ContentionStrategy.java|No|
|12|src/java/org/apache/cassandra/concurrent/ImmediateExecutor.java|No|
|10|src/java/org/apache/cassandra/service/paxos/PaxosPrepare.java|No|
|9|src/java/org/apache/cassandra/utils/JMXServerUtils.java|Partially|
|9|src/java/org/apache/cassandra/concurrent/NamedThreadFactory.java|No|
|8|src/java/org/apache/cassandra/utils/obs/BitUtil.java|Yes|
|8|src/java/org/apache/cassandra/utils/btree/AbstractBTreeMap.java|No|
|8|src/java/org/apache/cassandra/utils/MBeanWrapper.java|No|
|8|src/java/org/apache/cassandra/service/paxos/PaxosPropose.java|No|
|8|src/java/org/apache/cassandra/net/OutboundConnectionInitiator.java|No|
|8|src/java/com/datastax/driver/core/PreparedStatementHelper.java|No|
|7|src/java/org/apache/cassandra/utils/btree/BTreeMultimap.java|No|
|7|src/java/org/apache/cassandra/utils/ExpiringMemoizingSupplier.java|No|
|6|src/java/org/apache/cassandra/utils/WithResources.java|No|
|6|src/java/org/apache/cassandra/tools/StandaloneSplitter.java|No|
|6|src/java/org/apache/cassandra/io/util/SequentialWriter.java|No|
|6|src/java/org/apache/cassandra/concurrent/Stage.java|No|
|5|src/java/org/apache/cassandra/utils/FilterFactory.java|No|
|5|src/java/org/apache/cassandra/service/paxos/uncommitted/UncommittedDataFile.java|No|
|5|src/java/org/apache/cassandra/service/paxos/BallotGenerator.java|No|
|5|src/java/org/apache/cassandra/index/sai/disk/v1/vector/VectorPostingsWriter.java|No|
|5|src/java/org/apache/cassandra/db/transform/Transformation.java|No|
|5|src/java/org/apache/cassandra/concurrent/ExecutorFactory.java|No|
|4|src/java/org/apache/cassandra/utils/MonotonicClock.java|No|
|4|src/java/org/apache/cassandra/transport/Event.java|No|
|4|src/java/org/apache/cassandra/metrics/ClientMetrics.java|No|
|4|src/java/org/apache/cassandra/locator/RangesAtEndpoint.java|No|
|4|src/java/org/apache/cassandra/index/sasi/utils/RangeIterator.java|No|
|4|src/java/org/apache/cassandra/index/sai/iterators/KeyRangeIterator.java|No|
|4|src/java/org/apache/cassandra/concurrent/InfiniteLoopExecutor.java|No|
|3|src/java/org/apache/cassandra/utils/memory/BufferPool.java|No|
|3|src/java/org/apache/cassandra/tools/nodetool/ViewBuildStatus.java|No|
|3|src/java/org/apache/cassandra/streaming/StreamSession.java|No|
|3|src/java/
[jira] [Created] (CASSANDRA-19276) Add 'LeftCurly' checkstyle rule to enforce braces on next line on build
Andy Tolbert created CASSANDRA-19276:
Summary: Add 'LeftCurly' checkstyle rule to enforce braces on next
line on build
Key: CASSANDRA-19276
URL: https://issues.apache.org/jira/browse/CASSANDRA-19276
Project: Cassandra
Issue Type: Task
Components: Build
Reporter: Andy Tolbert
Assignee: Andy Tolbert
It came up in a review that I had missed some style changes in
[CASSANDRA-18857]
(https://github.com/apache/cassandra/pull/2969#pullrequestreview-1810999533).
Chatting with [~smiklosovic] we agreed that it would be nice if we could
enforce this in checkstyle, so we wouldn't need to be dependent on this being
caught in review.
The change for this is effectively:
{code}
index 8b81f21281..9bd22dc1ac 100644
--- a/.build/checkstyle.xml
+++ b/.build/checkstyle.xml
@@ -179,6 +179,10 @@
+
+
+
+
{code}
Notably, we would allow braces on the same lines for lambdas as per the
[project guidelines|https://cassandra.apache.org/_/development/code_style.html]
on code formatting:
{quote}
{{{}} and {{}}} are placed on a new line except when empty or opening a
multi-line lambda expression. Braces may be elided to a depth of one if the
condition or loop guards a single expression.
{quote}
There are 594 violations and 211 source files that would need to be adjusted.
I may play with the rules a little bit more to get this right.
I would like to propose that we change all files that are not imported from
other projects (there are a few, such as
src/java/org/apache/cassandra/utils/obs/BitUtil.java, which we can suppress
changes for), but we would change others.
I'll make a patch with the changes send a small proposal to the mailing list as
it could be disruptive to make a bunch of tiny changes, and depending on timing
there may be a better time to make a change like this.
We should make this change only on trunk.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Impacts: Security (was: None)
Test and Documentation Plan:
Test included in PR:
* {{AuthenticationTest}} tests existing code path that ensures {{AUTHENTICATE}}
request is sent in response to {{STARTUP}} with {{PasswordAuthenticator}}
* {{EarlyCertificateAuthenticationTest}} which validates authentication path
where certificate is provided (or not) with MutualTlsAuthenticator.
*
{{MutualTlsWithPasswordFallbackAuthenticatorEarlyCertificateAuthenticationTest}}
additionally validates authentication path where certificate is optionally
provided with credentials.
Status: Patch Available (was: Open)
Patch available at: https://github.com/apache/cassandra/pull/2969
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert reassigned CASSANDRA-18857:
Assignee: Andy Tolbert
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17799627#comment-17799627
]
Andy Tolbert commented on CASSANDRA-18857:
--
Ran through dtests and didn't run into any issues
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17799573#comment-17799573
]
Andy Tolbert commented on CASSANDRA-18857:
--
I've rebased [#2969|https://github.com/apache/cassandra/pull/2969] on trunk
after [CASSANDRA-18811] has been merged, unit tests appear to be passing. This
should be ready for review, although I'm looking to run this through some
dtests to further vet things.
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17793913#comment-17793913
]
Andy Tolbert commented on CASSANDRA-18857:
--
Apologies for the late follow up here. Realized that for this to fully work
[CASSANDRA-18811] is needed. I've created a [pull
request|https://github.com/apache/cassandra/pull/2969] that I will update as
soon as [CASSANDRA-18811] lands in trunk.
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Summary: Allow CQL client certificate authentication to work without
sending an AUTHENTICATE request (was: Allow CQL client certificate
authentication to work without sending an AUTHENTICATE request to client)
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request
> ---
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Priority: Normal
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18857) Allow CQL client certificate authentication to work without sending an AUTHENTICATE request to client
[
https://issues.apache.org/jira/browse/CASSANDRA-18857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18857:
-
Summary: Allow CQL client certificate authentication to work without
sending an AUTHENTICATE request to client (was: Allow CQL client-certificate
authentication to work without sending an AUTHENTICATE request to client)
> Allow CQL client certificate authentication to work without sending an
> AUTHENTICATE request to client
> -
>
> Key: CASSANDRA-18857
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Encryption
>Reporter: Andy Tolbert
>Priority: Normal
>
> Currently when using {{MutualTlsAuthenticator}} or
> {{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
> {{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
> (e.g. a user name and password). This shouldn't be needed as the role can be
> identified using only the certificate.
> To address this, we could add the capability to authenticate early in
> processing of a {{STARTUP}} message if we can determine that both the
> configured authenticator supports certificate authentication and a client
> certificate was provided. If the certificate can be authenticated, a
> {{READY}} response is returned, otherwise an {{ERROR}} is returned.
> This change can be done done in a fully backwards compatible way and requires
> no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18857) Allow CQL client-certificate authentication to work without sending an AUTHENTICATE request to client
Andy Tolbert created CASSANDRA-18857:
Summary: Allow CQL client-certificate authentication to work
without sending an AUTHENTICATE request to client
Key: CASSANDRA-18857
URL: https://issues.apache.org/jira/browse/CASSANDRA-18857
Project: Cassandra
Issue Type: Improvement
Components: Feature/Encryption
Reporter: Andy Tolbert
Currently when using {{MutualTlsAuthenticator}} or
{{MutualTlsWithPasswordFallbackAuthenticator}} a client is prompted with an
{{AUTHENTICATE}} message to which they must respond with an {{AUTH_RESPONSE}}
(e.g. a user name and password). This shouldn't be needed as the role can be
identified using only the certificate.
To address this, we could add the capability to authenticate early in
processing of a {{STARTUP}} message if we can determine that both the
configured authenticator supports certificate authentication and a client
certificate was provided. If the certificate can be authenticated, a {{READY}}
response is returned, otherwise an {{ERROR}} is returned.
This change can be done done in a fully backwards compatible way and requires
no protocol or driver changes; I will supply a patch shortly!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759060#comment-17759060
]
Andy Tolbert commented on CASSANDRA-18778:
--
{quote}as I am reading that patch ... what about truststores? Should not we
apply same logic there?
{quote}
This is a good question. It looks like there is no such validation on trust
store password, and looks like its allowed to be null or empty, and there is an
existing test for this
([testEmptyTrustStorePassword|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/security/FileBasedSslContextFactoryTest.java#L167-L179])
so we should be covered well there.
{quote}
I built it all one more time on more recent branches
{quote}
Awesome, thank you!
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757655#comment-17757655
]
Andy Tolbert edited comment on CASSANDRA-18778 at 8/22/23 8:17 PM:
---
{quote}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
{quote}
Yep! That's what I am aiming for, which was the previous behavior I'd observed
in C* 4.0. Technically {{null}} could be allowed I suspect, but I figured for
consistency it should behave the same way (use an empty string for
{{keystore_password}} when there is no password, fail when null)
was (Author: andrew.tolbert):
{quote}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
{quote}
Yep! That's what I am aiming for, which was the previous behavior I'd observed
in C* 4.0. Technically {{null}} could be allowed I suspect, but I figured for
consistency it should behave the same way (use an empty string for
{{keystore_password}} when there is no password)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757655#comment-17757655
]
Andy Tolbert commented on CASSANDRA-18778:
--
{quote}
So, basically, the previous version was throwing exception if it was null OR
empty.
Now we throw if it is just null.
{quote}
Yep! That's what I am aiming for, which was the previous behavior I'd observed
in C* 4.0. Technically {{null}} could be allowed I suspect, but I figured for
consistency it should behave the same way (use an empty string for
{{keystore_password}} when there is no password)
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757653#comment-17757653
]
Andy Tolbert commented on CASSANDRA-18778:
--
My understanding of [CASSANDRA-18124] was that it was oriented towards allowing
{{keystore_password}} to be nullable for the
{{PEMBasedSslContextFactory}}-based implementation to allow null/empty
passwords, which it previously didn't. A side effect of this change was also
that the default {{FileBasedSslContextFactory}} was changed to additionally
validate the password to ensure it was non-null/empty[1]. This validation did
not previously exist, and since {{KeyStore}} does allow empty passwords, this
could be a regression for someone upgrading from 4.0 to 4.1.2+ where empty
password PKCS12 keystores were used. It's probably not a common use case, but
was something I encountered myself during testing.
[1]:
https://github.com/apache/cassandra/commit/bd49f6ff265c8bfa64bf140328ae6736dc4a87bd#diff-559a53285872c51f496ae3319425977f741ae2f3a359c2da674403294e17297e
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757055#comment-17757055
]
Andy Tolbert commented on CASSANDRA-18778:
--
Must have missed staging something but pushed a tiny one-liner fix on each of
my branches to fix the {{@Test}} annotation
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757041#comment-17757041
]
Andy Tolbert commented on CASSANDRA-18778:
--
I see some CI tests failing, I must have missed something on my patch...taking
a look
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756997#comment-17756997
]
Andy Tolbert commented on CASSANDRA-18778:
--
(y) thanks, would appreciate additional eyes. I believe it may also be valid
to pass a {{null}} password to {{KeyStore.load}} or
{{{}KeyManagerFactory.init{}}}, but Cassandra 4.0 also disallows null
{{keystore_password}} (but allows empty string) in config validation, so felt
ok to keep doing the same for consistency:
C* 4.0:
{noformat}
2023-08-11 19:37:43,595 ERROR [main]
org.apache.cassandra.service.CassandraDaemon - Exception encountered during
startup: Invalid yaml. Those properties [keystore_password] are not valid
{noformat}
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Tolbert updated CASSANDRA-18778:
-
Reviewers: Jon Meredith
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
[
https://issues.apache.org/jira/browse/CASSANDRA-18778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756981#comment-17756981
]
Andy Tolbert commented on CASSANDRA-18778:
--
Isn't too much to the change needed for this, branches below. Tentative branch
pending review and ci test assistance from [~jonmeredith] (thanks!)
||Branch||Source||
|cassandra-4.1|[branch|https://github.com/tolbertam/cassandra/tree/C18778-4.1]|
|cassandra-5.0|[branch|https://github.com/tolbertam/cassandra/tree/C18778-5.0]|
|trunk|[branch|https://github.com/tolbertam/cassandra/tree/C18778-trunk]|
> Empty keystore_password no longer allowed on encryption_options
> ---
>
> Key: CASSANDRA-18778
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Config
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.1.x, 5.0.x
>
>
> After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible
> to set an empty {{keystore_password}} under {{client_encryption_options}} or
> {{server_encryption_options}} using the default implementation
> {{{}DefaultSslContextFactory{}}}.
> While keytool does not allow generating keystores with empty passwords, it
> does support reading them. It is not uncommon to use PKCS12 certificates
> generated by other tools (eg. openssl) that do not enforce passwords.
> The fix for this should be pretty straightforward, which should involve
> changing
> [FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
> to only disallow null passwords (which would be consistent with previous
> versions). I will create pull requests against the relevant branches shortly.
> {noformat}
> Exception (org.apache.cassandra.exceptions.ConfigurationException)
> encountered during startup: Failed to initialize SSL
> org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize
> SSL
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
> at
> org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
> at
> org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
> Caused by: java.io.IOException: Failed to create SSL context using Native
> transport
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
> at
> org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
> ... 6 more
> Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
> specified
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
> at
> org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
> at
> org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
> at
> org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
> at
> org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18778) Empty keystore_password no longer allowed on encryption_options
Andy Tolbert created CASSANDRA-18778:
Summary: Empty keystore_password no longer allowed on
encryption_options
Key: CASSANDRA-18778
URL: https://issues.apache.org/jira/browse/CASSANDRA-18778
Project: Cassandra
Issue Type: Bug
Components: Local/Config
Reporter: Andy Tolbert
Assignee: Andy Tolbert
After CASSANDRA-18124 (introduced in 4.1.2 and 5.0) it is no longer possible to
set an empty {{keystore_password}} under {{client_encryption_options}} or
{{server_encryption_options}} using the default implementation
{{{}DefaultSslContextFactory{}}}.
While keytool does not allow generating keystores with empty passwords, it does
support reading them. It is not uncommon to use PKCS12 certificates generated
by other tools (eg. openssl) that do not enforce passwords.
The fix for this should be pretty straightforward, which should involve
changing
[FileBasedSslContextFactory.validatePassword|https://github.com/apache/cassandra/blob/cassandra-4.1.2/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java#L128-L135]
to only disallow null passwords (which would be consistent with previous
versions). I will create pull requests against the relevant branches shortly.
{noformat}
Exception (org.apache.cassandra.exceptions.ConfigurationException) encountered
during startup: Failed to initialize SSL
org.apache.cassandra.exceptions.ConfigurationException: Failed to initialize SSL
at
org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1155)
at
org.apache.cassandra.config.DatabaseDescriptor.applyAll(DatabaseDescriptor.java:390)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:204)
at
org.apache.cassandra.config.DatabaseDescriptor.daemonInitialization(DatabaseDescriptor.java:188)
at
org.apache.cassandra.service.CassandraDaemon.applyConfig(CassandraDaemon.java:804)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:747)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:875)
Caused by: java.io.IOException: Failed to create SSL context using Native
transport
at
org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:405)
at
org.apache.cassandra.config.DatabaseDescriptor.applySslContext(DatabaseDescriptor.java:1150)
... 6 more
Caused by: java.lang.IllegalArgumentException: 'keystore_password' must be
specified
at
org.apache.cassandra.security.FileBasedSslContextFactory.validatePassword(FileBasedSslContextFactory.java:133)
at
org.apache.cassandra.security.FileBasedSslContextFactory.buildKeyManagerFactory(FileBasedSslContextFactory.java:151)
at
org.apache.cassandra.security.AbstractSslContextFactory.createNettySslContext(AbstractSslContextFactory.java:181)
at
org.apache.cassandra.security.SSLFactory.createNettySslContext(SSLFactory.java:168)
at
org.apache.cassandra.security.SSLFactory.validateSslContext(SSLFactory.java:355)
... 7 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17945) Fix StorageService.getNativeaddress handling of IPv6 addresses
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613758#comment-17613758
]
Andy Tolbert commented on CASSANDRA-17945:
--
Awesome, thank you so much [~aweisberg] for reviewing and getting this
committed and [~brandon.williams] for the +1 as well!
> Fix StorageService.getNativeaddress handling of IPv6 addresses
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
> Fix For: 4.0.x, 4.1-rc
>
>
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHo
[jira] [Commented] (CASSANDRA-17945) StorageService.getNativeaddress does not account for IPv6 addresses in the case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
[
https://issues.apache.org/jira/browse/CASSANDRA-17945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612697#comment-17612697
]
Andy Tolbert commented on CASSANDRA-17945:
--
Pull Request: https://github.com/apache/cassandra/pull/1895
> StorageService.getNativeaddress does not account for IPv6 addresses in the
> case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
> --
>
> Key: CASSANDRA-17945
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
> Project: Cassandra
> Issue Type: Improvement
> Components: Cluster/Gossip
>Reporter: Andy Tolbert
>Assignee: Andy Tolbert
>Priority: Normal
>
> While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
> following in logs for upgraded nodes when processing down events for 3.0
> nodes that are going down as part of an upgrade:
>
> {noformat}
> 2022-09-28 20:18:48,244 ERROR [GossipStage:1]
> org.apache.cassandra.transport.Server - Problem retrieving RPC address for
> /[0:0:0:0:0:0:0:d9]:7000
> java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
> at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
> at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
> at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
>
> at
> org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
>
> at
> org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
> at
> org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
>
> at
> org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
> at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
> at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
> at
> org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
>
> at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
> at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
> at
> org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
>
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> [netty-all-4.1.58.Final.jar:4.1.58.Final]
> at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
> It appears that StorageService.getNativeaddress does not account for the fact
> that an endpoint may be an IPv6 address, which required brackets when
> specified with a port:
>
> [https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
>
>
> {code:java}
> /**
> * Return the native address associated with an endpoint as a string.
> * @param endpoint The endpoint to get rpc address for
> * @return the native address
> */
> public String getNativeaddress(InetAddressAndPort endpoint, boolean
> withPort)
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
> return
> FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
> != null)
> {
> try
> {
> InetAddressAndPort address =
> InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
> return address.getHostAddress(withPort);
> }
> catch (UnknownHostException e)
> {
> throw new RuntimeException(e);
> }
> }
> else if
> (Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
> == null)
> return endpoint.address.getHostAddress() + ":" +
> DatabaseDescriptor.getNativeTransportPort();
> else
[jira] [Created] (CASSANDRA-17945) StorageService.getNativeaddress does not account for IPv6 addresses in the case NATIVE_ADDRESS_AND_PORT is not present in gossip state for an endpoint
Andy Tolbert created CASSANDRA-17945:
Summary: StorageService.getNativeaddress does not account for IPv6
addresses in the case NATIVE_ADDRESS_AND_PORT is not present in gossip state
for an endpoint
Key: CASSANDRA-17945
URL: https://issues.apache.org/jira/browse/CASSANDRA-17945
Project: Cassandra
Issue Type: Improvement
Components: Cluster/Gossip
Reporter: Andy Tolbert
Assignee: Andy Tolbert
While upgrading a cluster using IPv6 addresses from 3.0 to 4.0 I noticed the
following in logs for upgraded nodes when processing down events for 3.0 nodes
that are going down as part of an upgrade:
{noformat}
2022-09-28 20:18:48,244 ERROR [GossipStage:1]
org.apache.cassandra.transport.Server - Problem retrieving RPC address for
/[0:0:0:0:0:0:0:d9]:7000
java.net.UnknownHostException: 0:0:0:0:0:0:0:d9:9042: invalid IPv6 address
at java.net.InetAddress.getAllByName(InetAddress.java:1355) ~[?:?]
at java.net.InetAddress.getAllByName(InetAddress.java:1306) ~[?:?]
at java.net.InetAddress.getByName(InetAddress.java:1256) ~[?:?]
at
org.apache.cassandra.locator.InetAddressAndPort.getByNameOverrideDefaults(InetAddressAndPort.java:227)
at
org.apache.cassandra.locator.InetAddressAndPort.getByName(InetAddressAndPort.java:212)
at
org.apache.cassandra.transport.Server$EventNotifier.getNativeAddress(Server.java:377)
at org.apache.cassandra.transport.Server$EventNotifier.onDown(Server.java:438)
at
org.apache.cassandra.service.StorageService.notifyDown(StorageService.java:2651)
at org.apache.cassandra.service.StorageService.onDead(StorageService.java:3516)
at org.apache.cassandra.gms.Gossiper.markDead(Gossiper.java:1347)
at org.apache.cassandra.gms.Gossiper.markAsShutdown(Gossiper.java:590)
at
org.apache.cassandra.gms.GossipShutdownVerbHandler.doVerb(GossipShutdownVerbHandler.java:39)
at org.apache.cassandra.net.InboundSink.lambda$new$0(InboundSink.java:78)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:97)
at org.apache.cassandra.net.InboundSink.accept(InboundSink.java:45)
at
org.apache.cassandra.net.InboundMessageHandler$ProcessMessage.run(InboundMessageHandler.java:433)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
[netty-all-4.1.58.Final.jar:4.1.58.Final]
at java.lang.Thread.run(Thread.java:829) [?:?]{noformat}
It appears that StorageService.getNativeaddress does not account for the fact
that an endpoint may be an IPv6 address, which required brackets when specified
with a port:
[https://github.com/apache/cassandra/blob/cassandra-4.0.6/src/java/org/apache/cassandra/service/StorageService.java#L1978-L1981]
{code:java}
/**
* Return the native address associated with an endpoint as a string.
* @param endpoint The endpoint to get rpc address for
* @return the native address
*/
public String getNativeaddress(InetAddressAndPort endpoint, boolean
withPort)
{
if (endpoint.equals(FBUtilities.getBroadcastAddressAndPort()))
return
FBUtilities.getBroadcastNativeAddressAndPort().getHostAddress(withPort);
else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT)
!= null)
{
try
{
InetAddressAndPort address =
InetAddressAndPort.getByName(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.NATIVE_ADDRESS_AND_PORT).value);
return address.getHostAddress(withPort);
}
catch (UnknownHostException e)
{
throw new RuntimeException(e);
}
}
else if
(Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS)
== null)
return endpoint.address.getHostAddress() + ":" +
DatabaseDescriptor.getNativeTransportPort();
else
return
Gossiper.instance.getEndpointStateForEndpoint(endpoint).getApplicationState(ApplicationState.RPC_ADDRESS).value
+ ":" + DatabaseDescriptor.getNativeTransportPort();
}{code}
In the two final else cases, the endpoint address and port are delimited with a
colon. For IPv6 addresses this creates an invalid address
(0:0:0:0:0:0:0:d9:9042), IPv6 addresses must be enclosed in brackets (e.g.
[0:0:0:0:0:0:0:d9]:9042) per
[https://datatracker.ietf.org/doc/html/rfc2732#section-2]
Once a cluster is fully upgraded to 4.0, this error no longer occurs as all
endpoints will have N
[jira] [Comment Edited] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090283#comment-17090283
]
Andy Tolbert edited comment on CASSANDRA-15472 at 4/23/20, 5:52 AM:
You are right, I should have been more clear there. Adding the dependency
alone is not enough, wherever a {{Cluster.builder}} is registered, we would
also need to do the following, per the java driver docs you linked:
{code}
Cluster cluster = Cluster.builder()
.withoutJMXReporting()
.build();
JmxReporter reporter =
JmxReporter.forRegistry(cluster.getMetrics().getRegistry())
.inDomain(cluster.getClusterName() + "-metrics")
.build();
reporter.start();
{code}
I think this is a reasonable compromise, it'll take some extra work but the end
result is we use metrics 4, and the behavior of our tooling that use the driver
should be the same as it pertains to emitting JMX metrics.
was (Author: andrew.tolbert):
You are right, I should have been more clear there. Adding the dependency
alone is not enough, wherever a {{Cluster.builder}} is registered, we would
also need to do the following, per the java driver docs you linked:
{code}
Cluster cluster = Cluster.builder()
.withoutJMXReporting()
.build();
JmxReporter reporter =
JmxReporter.forRegistry(cluster.getMetrics().getRegistry())
.inDomain(cluster.getClusterName() + "-metrics")
.build();
reporter.start();
{code}
I think this is a reasonable compromise, it'll take some extra work but the end
result is we use metrics 4, and the behavior of our tooling that use the driver
should be the same.
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
--
[jira] [Commented] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17090283#comment-17090283
]
Andy Tolbert commented on CASSANDRA-15472:
--
You are right, I should have been more clear there. Adding the dependency
alone is not enough, wherever a {{Cluster.builder}} is registered, we would
also need to do the following, per the java driver docs you linked:
{code}
Cluster cluster = Cluster.builder()
.withoutJMXReporting()
.build();
JmxReporter reporter =
JmxReporter.forRegistry(cluster.getMetrics().getRegistry())
.inDomain(cluster.getClusterName() + "-metrics")
.build();
reporter.start();
{code}
I think this is a reasonable compromise, it'll take some extra work but the end
result is we use metrics 4, and the behavior of our tooling that use the driver
should be the same.
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15472) Read failure due to exception from metrics-core dependency
[
https://issues.apache.org/jira/browse/CASSANDRA-15472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089193#comment-17089193
]
Andy Tolbert commented on CASSANDRA-15472:
--
Sorry for the delay in response [~sumanth.pasupuleti].
I think its probably reasonable to add {{metrics-jmx}} as a dependency while
upgrading to metrics 4, since metrics 3 included the JMX bits anyways so this
isn't really adding any additional baggage. The driver does work with metrics
4 (just like it works with netty 4.1 but depends on 4.0), we just didn't want
to bump the dependency as if I recall right we wanted to avoid making major
version upgrades of dependencies in minor releases.
Alternatively we could use {{withoutJMXReporting}} in all the cluster builders,
but not sure if anyone is dependent on the driver emitting metrics via JMX, so
i'd rather err on the side of adding {{metrics-jmx}}.
> Read failure due to exception from metrics-core dependency
> --
>
> Key: CASSANDRA-15472
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15472
> Project: Cassandra
> Issue Type: Bug
> Components: Dependencies
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> Stacktrace
> {code:java}
> Uncaught exception on thread Thread[SharedPool-Worker-27,5,main]: {}
> java.util.NoSuchElementException: null
> at
> java.util.concurrent.ConcurrentSkipListMap.firstKey(ConcurrentSkipListMap.java:2053)
> ~[na:1.8.0_222]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:102)
> ~[metrics-core-2.2.0.jar:na]
> at
> com.yammer.metrics.stats.ExponentiallyDecayingSample.update(ExponentiallyDecayingSample.java:81)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Histogram.update(Histogram.java:110)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:198)
> ~[metrics-core-2.2.0.jar:na]
> at com.yammer.metrics.core.Timer.update(Timer.java:76)
> ~[metrics-core-2.2.0.jar:na]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:108)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.metrics.LatencyMetrics.addNano(LatencyMetrics.java:114)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1897)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.db.Keyspace.getRow(Keyspace.java:353)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.SliceFromReadCommand.getRow(SliceFromReadCommand.java:85)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.db.ReadVerbHandler.doVerb(ReadVerbHandler.java:47)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:64)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> ~[na:1.8.0_222]
> at
> org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164)
> ~[nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105)
> [nf-cassandra-2.1.19.10.jar:2.1.19.10]
> at java.lang.Thread.run(Thread.java:748) [na:1.8.0_222]
> {code}
> This [issue|https://github.com/dropwizard/metrics/issues/1278] has been
> [fixed|https://github.com/dropwizard/metrics/pull/1436] in
> [v4.0.6|https://github.com/dropwizard/metrics/releases/tag/v4.0.6].
> This is observed on a 2.1.19 cluster, but this would impact pretty much any
> version of C* since we depend on lower versions of metrics-core that do not
> have the fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040727#comment-17040727
]
Andy Tolbert commented on CASSANDRA-14872:
--
{quote}
It will need some driver changes and I am reluctant to check in a custom build
of the driver. So this is an ok compromise for the time being
{quote}
+1 agree we should proceed with it included as it seems like a small
self-contained dependency, and it is really nice to not use a custom build.
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Andy Tolbert
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040697#comment-17040697
]
Andy Tolbert edited comment on CASSANDRA-14872 at 2/20/20 7:37 AM:
---
Changes look great! Played around with it a little bit and it's working well.
I like that autocompletion works flawlessly for vtables :)
One thing that is interesting is that geomet is a required dependency. Since
it's apache licensed and seems pretty small that doesn't seem like much of a
deal. I think it could be made optional in the python driver (it's used for
parsing DSE-specific geospatial types) so might be something worth pursuing on
that end (but don't think it's needed as a prereq to this).
was (Author: andrew.tolbert):
Changes look great! Played around with it a little bit and it's working well.
I like that autocompletion works flawlessly for vtables :)
One thing that is interesting is that geomet is a required dependency. Since
it's apache licensed and seems pretty small that doesn't seem like much of a
deal. I think it could be made optional in the python driver (it's used for
parsing DSE-specific geospatial types) so might be something worth pursuing on
that end.
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Andy Tolbert
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040697#comment-17040697
]
Andy Tolbert commented on CASSANDRA-14872:
--
Changes look great! Played around with it a little bit and it's working well.
I like that autocompletion works flawlessly for vtables :)
One thing that is interesting is that geomet is a required dependency. Since
it's apache licensed and seems pretty small that doesn't seem like much of a
deal. I think it could be made optional in the python driver (it's used for
parsing DSE-specific geospatial types) so might be something worth pursuing on
that end.
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Andy Tolbert
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14872) Update to version of python driver and update cqlsh to use driver metadata for virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17040686#comment-17040686
]
Andy Tolbert commented on CASSANDRA-14872:
--
I remember trying transient replication with the java driver and it not working
([JAVA-2105|https://datastax-oss.atlassian.net/browse/JAVA-2105]), I suspect
most/all client libraries that read schema need updates to parse it.
> Update to version of python driver and update cqlsh to use driver metadata
> for virtual tables
> -
>
> Key: CASSANDRA-14872
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14872
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/cqlsh
>Reporter: Andy Tolbert
>Assignee: Dinesh Joshi
>Priority: Normal
> Fix For: 4.0, 4.0-alpha
>
>
> When virtual tables were implemented ([CASSANDRA-7622]), cqlsh.py was updated
> to parse virtual keyspace metadata by making queries to the
> {{system_virtual_schema}} table and included a TODO:
> {code:python}
> # TODO remove after virtual tables are added to connection metadata
> {code}
> Since python driver 3.15.0 (released in August), the driver now parses
> virtual keyspace metadata. It would be good to update the bundled python
> driver and simplify cqlsh code to utilize its capability to parse virtual
> tables.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15349) Add “Going away” message to the client protocol
[ https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968651#comment-16968651 ] Andy Tolbert commented on CASSANDRA-15349: -- With regards to #3, I was only thinking about limiting the complexity on the client side. If the server could close the connection when there are no more inflight requests (or after some timeout if its taking too long) the client wouldn't need to worry about checking for it as it gets responses. The timeout could be more of a ceiling in cases where requests aren't being processed for whatever reason, or if the client won't stop sending requests. > Add “Going away” message to the client protocol > --- > > Key: CASSANDRA-15349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15349 > Project: Cassandra > Issue Type: New Feature > Components: Messaging/Client >Reporter: Alex Petrov >Priority: Normal > Labels: client-impacting > > Add “Going away” message that allows node to announce its shutdown and let > clients gracefully shutdown and not attempt further requests. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15349) Add “Going away” message to the client protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968498#comment-16968498
]
Andy Tolbert edited comment on CASSANDRA-15349 at 11/6/19 4:48 PM:
---
I think a new event for {{REGISTER}} seems adequate if the only information we
are communicating is that the node is going away. It seems to fit in that it's
the only current type that causes messages that aren't bound to a request. One
benefit of this is that sending this as an event shouldn't break any existing
clients that don't support it since they would have to know to {{REGISTER}} for
it.
Some thoughts about how I think it should work on the server side when it sends
{{GOING_AWAY}}:
* The node stops accepting new connections immediately.
* The node still accepts requests for some time, like 2 seconds. This gives
client time to react to the message. Another alternative is to make this a
quiet period, similar to Netty's
[shutdownGracefully|https://netty.io/4.0/api/io/netty/util/concurrent/GlobalEventExecutor.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-]
where it will continue accepting requests until some quiet period or timeout
has elapsed.
* After that time, it sends some kind of error, something like
{{Overloaded}}, which would cause most clients to retry on next host
* Then after some other configurable period of time (10 seconds?), it closes
the connections. Alternatively, connections could be closed when there are no
more inflight requests on them (after a quiet period).
On driver side, some ideas, but depends on driver's implementation:
1. If we go register route, each connection would need to register on this when
its initialized. This is probably easier to implement than doing it for one
connection per node I think.
2. When receiving {{GOING_AWAY}}, stop sending new requests to that node, but
don't consider it DOWN to allow pending requests to complete. Most drivers
will mark the host DOWN once all connections to it are closed, and will try
reconnecting per usual.
3. Don't close connections explicitly, let the server do it for you.
was (Author: andrew.tolbert):
I think a new event for {{REGISTER}} seems adequate if the only information we
are communicating is that the node is going away. It seems to fit in that it's
the only current type that causes messages that aren't bound to a request. One
benefit of this is that sending this as an event shouldn't break any existing
clients that don't support it since they would have to know to {{REGISTER}} for
it.
Some thoughts about how I think it should work on the server side when it sends
{{GOING_AWAY}}:
* The node stops accepting new connections immediately.
* The node still accepts requests for some time, like 2 seconds. This gives
client time to react to the message. Another alternative is to make this a
quiet period, similar to Netty's
[shutdownGracefully|https://netty.io/4.0/api/io/netty/util/concurrent/GlobalEventExecutor.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-]
where it will continue accepting requests until some quiet period or timeout
has elapsed.
* After that time, it sends some kind of error, something like
{{Overloaded}}, which would cause most clients to retry on next host
* Then after some other configurable period of time (10 seconds?), it closes
the connections.
On driver side, some ideas, but depends on driver's implementation:
1. If we go register route, each connection would need to register on this when
its initialized. This is probably easier to implement than doing it for one
connection per node I think.
2. When receiving {{GOING_AWAY}}, stop sending new requests to that node, but
don't consider it DOWN to allow pending requests to complete. Most drivers
will mark the host DOWN once all connections to it are closed, and will try
reconnecting per usual.
3. Don't close connections explicitly, let the server do it for you.
> Add “Going away” message to the client protocol
> ---
>
> Key: CASSANDRA-15349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15349
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Client
>Reporter: Alex Petrov
>Priority: Normal
> Labels: client-impacting
>
> Add “Going away” message that allows node to announce its shutdown and let
> clients gracefully shutdown and not attempt further requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15349) Add “Going away” message to the client protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968498#comment-16968498
]
Andy Tolbert edited comment on CASSANDRA-15349 at 11/6/19 4:48 PM:
---
I think a new event for {{REGISTER}} seems adequate if the only information we
are communicating is that the node is going away. It seems to fit in that it's
the only current type that causes messages that aren't bound to a request. One
benefit of this is that sending this as an event shouldn't break any existing
clients that don't support it since they would have to know to {{REGISTER}} for
it.
Some thoughts about how I think it should work on the server side when it sends
{{GOING_AWAY}}:
* The node stops accepting new connections immediately.
* The node still accepts requests for some time, like 2 seconds. This gives
client time to react to the message. Another alternative is to make this a
quiet period, similar to Netty's
[shutdownGracefully|https://netty.io/4.0/api/io/netty/util/concurrent/GlobalEventExecutor.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-]
where it will continue accepting requests until some quiet period or timeout
has elapsed.
* After that time, it sends some kind of error, something like
{{Overloaded}}, which would cause most clients to retry on next host
* Then after some other configurable period of time (10 seconds?), it closes
the connections.
On driver side, some ideas, but depends on driver's implementation:
1. If we go register route, each connection would need to register on this when
its initialized. This is probably easier to implement than doing it for one
connection per node I think.
2. When receiving {{GOING_AWAY}}, stop sending new requests to that node, but
don't consider it DOWN to allow pending requests to complete. Most drivers
will mark the host DOWN once all connections to it are closed, and will try
reconnecting per usual.
3. Don't close connections explicitly, let the server do it for you.
was (Author: andrew.tolbert):
I think a new event for {{REGISTER}} seems adequate if the only information we
are communicating is that the node is going away. It seems to fit in that it's
the only current type that causes messages that aren't bound to a request. One
benefit of this is that sending this as an event shouldn't break any existing
clients that don't support it since they would have to know to {{REGISTER}} for
it.
Some thoughts about how I think it should work on the server side when it sends
{{GOING_AWAY}}:
* The node stops accepting new connections immediately.
* The node still accepts requests for some time, like 2 seconds. This gives
client time to react to the message. Another alternative is to make this a
quiet period, similar to Netty's
[shutdownGracefully|https://netty.io/4.0/api/io/netty/util/concurrent/GlobalEventExecutor.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-]
where it will continue accepting requests until some quiet period or timeout
has elapsed.
* After that time, it sends some kind of error, something like
{{Overloaded}}), which would cause most clients to retry on next host
* Then after some other configurable period of time (10 seconds?), it closes
the connections.
On driver side, some ideas, but depends on driver's implementation:
1. If we go register route, each connection would need to register on this when
its initialized. This is probably easier to implement than doing it for one
connection per node I think.
2. When receiving {{GOING_AWAY}}, stop sending new requests to that node, but
don't consider it DOWN to allow pending requests to complete. Most drivers
will mark the host DOWN once all connections to it are closed, and will try
reconnecting per usual.
3. Don't close connections explicitly, let the server do it for you.
> Add “Going away” message to the client protocol
> ---
>
> Key: CASSANDRA-15349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15349
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Client
>Reporter: Alex Petrov
>Priority: Normal
> Labels: client-impacting
>
> Add “Going away” message that allows node to announce its shutdown and let
> clients gracefully shutdown and not attempt further requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15349) Add “Going away” message to the client protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16968498#comment-16968498
]
Andy Tolbert commented on CASSANDRA-15349:
--
I think a new event for {{REGISTER}} seems adequate if the only information we
are communicating is that the node is going away. It seems to fit in that it's
the only current type that causes messages that aren't bound to a request. One
benefit of this is that sending this as an event shouldn't break any existing
clients that don't support it since they would have to know to {{REGISTER}} for
it.
Some thoughts about how I think it should work on the server side when it sends
{{GOING_AWAY}}:
* The node stops accepting new connections immediately.
* The node still accepts requests for some time, like 2 seconds. This gives
client time to react to the message. Another alternative is to make this a
quiet period, similar to Netty's
[shutdownGracefully|https://netty.io/4.0/api/io/netty/util/concurrent/GlobalEventExecutor.html#shutdownGracefully-long-long-java.util.concurrent.TimeUnit-]
where it will continue accepting requests until some quiet period or timeout
has elapsed.
* After that time, it sends some kind of error, something like
{{Overloaded}}), which would cause most clients to retry on next host
* Then after some other configurable period of time (10 seconds?), it closes
the connections.
On driver side, some ideas, but depends on driver's implementation:
1. If we go register route, each connection would need to register on this when
its initialized. This is probably easier to implement than doing it for one
connection per node I think.
2. When receiving {{GOING_AWAY}}, stop sending new requests to that node, but
don't consider it DOWN to allow pending requests to complete. Most drivers
will mark the host DOWN once all connections to it are closed, and will try
reconnecting per usual.
3. Don't close connections explicitly, let the server do it for you.
> Add “Going away” message to the client protocol
> ---
>
> Key: CASSANDRA-15349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15349
> Project: Cassandra
> Issue Type: New Feature
> Components: Messaging/Client
>Reporter: Alex Petrov
>Priority: Normal
> Labels: client-impacting
>
> Add “Going away” message that allows node to announce its shutdown and let
> clients gracefully shutdown and not attempt further requests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-10190) Python 3 support for cqlsh
[
https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16946590#comment-16946590
]
Andy Tolbert commented on CASSANDRA-10190:
--
Added [^0001-Fix-issues-from-version-specific-logic-commit.patch] which fixes
issues from my previous commit and should cause the 2 new failing tests to now
pass. There's still a little more testing I'd like to do though, from the
[{{cqlshlib6-rebase-20190322}}|https://github.com/ptbannister/cassandra-dtest/commits/cqlshlib6-rebase-20190322]
branch, other than the virtual tables related failures, there's one test that
fails because a unicode type instead of str type is given:
{noformat}
TestCqlsh.test_materialized_view
...
> assert "Materialized view 'users_by_state' not found" in err
E assert "Materialized view 'users_by_state' not found" in
":2:Materialized view u'users_by_state' not found\n"
{noformat}
> Python 3 support for cqlsh
> --
>
> Key: CASSANDRA-10190
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10190
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools
>Reporter: Andrew Pennebaker
>Assignee: Patrick Bannister
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 4.0-alpha
>
> Attachments:
> 0001-Fix-issues-from-version-specific-logic-commit.patch,
> 0001-Update-six-to-1.12.0.patch,
> 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch,
> coverage_notes.txt
>
>
> Users who operate in a Python 3 environment may have trouble launching cqlsh.
> Could we please update cqlsh's syntax to run in Python 3?
> As a workaround, users can setup pyenv, and cd to a directory with a
> .python-version containing "2.7". But it would be nice if cqlsh supported
> modern Python versions out of the box.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-10190) Python 3 support for cqlsh
[ https://issues.apache.org/jira/browse/CASSANDRA-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Tolbert updated CASSANDRA-10190: - Attachment: 0001-Fix-issues-from-version-specific-logic-commit.patch > Python 3 support for cqlsh > -- > > Key: CASSANDRA-10190 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10190 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Tools >Reporter: Andrew Pennebaker >Assignee: Patrick Bannister >Priority: Normal > Labels: cqlsh > Fix For: 4.0, 4.0-alpha > > Attachments: > 0001-Fix-issues-from-version-specific-logic-commit.patch, > 0001-Update-six-to-1.12.0.patch, > 0002-Simplify-version-specific-logic-by-using-six.moves-a.patch, > coverage_notes.txt > > > Users who operate in a Python 3 environment may have trouble launching cqlsh. > Could we please update cqlsh's syntax to run in Python 3? > As a workaround, users can setup pyenv, and cd to a directory with a > .python-version containing "2.7". But it would be nice if cqlsh supported > modern Python versions out of the box. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
