[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362217#comment-17362217
]
Ekaterina Dimitrova commented on CASSANDRA-16669:
-
There is one [single failure
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/5e3fa9b6-0c5f-443a-880f-7635d04cea18/jobs/5693]
which is not related.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362216#comment-17362216
]
Ekaterina Dimitrova commented on CASSANDRA-16695:
-
[2.2 | https://github.com/ekaterinadimitrova2/cassandra/pull/141] | [CI
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/957/workflows/e7524714-b3db-4dc2-86a5-138d836d8363]
[3.0 | https://github.com/ekaterinadimitrova2/cassandra/pull/142| ] | [CI
run|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/963/workflows/315bd1ba-a437-4d01-aa2b-c938ee094a00]
[3.11 | https://github.com/ekaterinadimitrova2/cassandra/pull/143] | [CI run |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/964/workflows/4768f7cb-18e2-495c-87c3-4bbac98ea758]
[4.0.0 |https://github.com/ekaterinadimitrova2/cassandra/pull/144 ] | CI [Java
8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/966/workflows/d55aef8f-24fc-4024-b3bc-587fbfca5c32]
| [Java
11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/966/workflows/cab3c0cb-c2ba-491b-85fe-fb70f50572f8]
[4.0|https://github.com/ekaterinadimitrova2/cassandra/pull/131] | CI [Java
8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/968/workflows/a0e41baa-1d54-4bfb-b4da-55ffc2fb7413]
| [Java
11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/968/workflows/0200263f-dea9-4449-a422-0e51f066ca42]
[trunk|https://github.com/ekaterinadimitrova2/cassandra/pull/145] CI [java
8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/971/workflows/e7cd9921-60ad-46dd-a70c-5f7fa99e83bd]
| [Java 11|
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/971/workflows/95501365-4c62-44ae-9724-e4b796f6581c]
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16669) Password obfuscation for DCL audit log statements
[ https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362204#comment-17362204 ] Ekaterina Dimitrova edited comment on CASSANDRA-16669 at 6/12/21, 12:31 AM: Thank you [~sumanth.pasupuleti] for all your work. I spent some time on the patch today and I did also a lot of additional manual testing to be sure about my understanding about how things work. Attached is a [PR |https://github.com/ekaterinadimitrova2/cassandra/pull/140] containing your [commit |https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/b2ed399c0818c0d3616fdb353a089829be469d3e] and [commit |https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/3b57f9ccfc6cec0a677463bc1f0cef722d61dbab] with my small review comments. The new tests are all passing locally for me. I added a few sentences to the docs to reflect the current limitations around password obfuscation. I am currently running full CI - [Java 8 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/5e3fa9b6-0c5f-443a-880f-7635d04cea18] | [Java 11 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/edb2b149-f237-4302-8814-3c41b8fb9035] I was thinking of more tests to add but after running more FQL and the AuditLogging locally I think the current suite satisfies the needs as we have a centralized solution within the _QueryEvents_. [~vinaykumarcse], please, correct me if I am wrong as you are the author and you might have some additional deep knowledge. Please let me know If you want me to add something more. Currently we obfuscate with everything after the word password in a DCL statement record so I would expect more information than less to be obfuscated. *NOTE:* On green CI and +1 from [~vinaykumarcse] I will propagate to cassandra-4.0 and trunk branches and commit. I was informed by [~aholmber] that [~stefan.miklosovic] agreed if we are done before he is back next week to merge the change on +1 from me and [~vinaykumarcse] so we can unblock the 4.0 RC2 I am +1 to the patch on green CI completion. I will check back a bit later tonight if there are any new failures. was (Author: e.dimitrova): Thank you [~sumanth.pasupuleti] for all your work. I spent some time on the patch today and I did also a lot of additional manual testing to be sure about my understanding about how things work. Attached is a [PR |https://github.com/ekaterinadimitrova2/cassandra/pull/140] containing your [commit |https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/b2ed399c0818c0d3616fdb353a089829be469d3e] and [commit |https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/3b57f9ccfc6cec0a677463bc1f0cef722d61dbab] with my small review comments. The new tests are all passing locally for me. I added a few sentences to the docs to reflect the current limitations around password obfuscation. I am currently running full CI - [Java 8 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/5e3fa9b6-0c5f-443a-880f-7635d04cea18] | [Java 11 |https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/edb2b149-f237-4302-8814-3c41b8fb9035] I was thinking of more tests to add but after running more FQL and the AuditLogging locally I think the current suite satisfies the needs as we have a centralized solution within the _QueryEvents_. [~vinaykumarcse], please, correct me if I am wrong as you are the author and you might have some additional deep knowledge. Please let me know If you want me to add something more. Currently we obfuscate with everything after the word password in a DCL statement record so I would expect more information than less to be obfuscated. I am +1 to the patch on green CI completion. I will check back a bit later tonight if there are any new failures. > Password obfuscation for DCL audit log statements > - > > Key: CASSANDRA-16669 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16669 > Project: Cassandra > Issue Type: Bug > Components: Tool/auditlogging >Reporter: Vinay Chella >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: audit, security > Fix For: 4.0-rc, 4.0.x, 4.x > > Time Spent: 5h 10m > Remaining Estimate: 0h > > The goal of this JIRA is to obfuscate passwords or any sensitive information > from DCL audit log statements. > Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL > ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles] > and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] ) > queries with passwords in
[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362204#comment-17362204
]
Ekaterina Dimitrova commented on CASSANDRA-16669:
-
Thank you [~sumanth.pasupuleti] for all your work. I spent some time on the
patch today and I did also a lot of additional manual testing to be sure about
my understanding about how things work.
Attached is a [PR |https://github.com/ekaterinadimitrova2/cassandra/pull/140]
containing your [commit
|https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/b2ed399c0818c0d3616fdb353a089829be469d3e]
and [commit
|https://github.com/ekaterinadimitrova2/cassandra/pull/140/commits/3b57f9ccfc6cec0a677463bc1f0cef722d61dbab]
with my small review comments. The new tests are all passing locally for me.
I added a few sentences to the docs to reflect the current limitations around
password obfuscation.
I am currently running full CI - [Java 8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/5e3fa9b6-0c5f-443a-880f-7635d04cea18]
| [Java 11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/954/workflows/edb2b149-f237-4302-8814-3c41b8fb9035]
I was thinking of more tests to add but after running more FQL and the
AuditLogging locally I think the current suite satisfies the needs as we have a
centralized solution within the _QueryEvents_. [~vinaykumarcse], please,
correct me if I am wrong as you are the author and you might have some
additional deep knowledge. Please let me know If you want me to add something
more.
Currently we obfuscate with everything after the word password in a
DCL statement record so I would expect more information than less to be
obfuscated.
I am +1 to the patch on green CI completion. I will check back a bit later
tonight if there are any new failures.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional
[jira] [Comment Edited] (CASSANDRA-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361510#comment-17361510
]
Erick Ramirez edited comment on CASSANDRA-16731 at 6/12/21, 12:26 AM:
--
PR submitted by https://github.com/polymetric –
[https://github.com/apache/cassandra-website/pull/55]
was (Author: flightc):
PR submitted by Alexander Pomosov –
https://github.com/apache/cassandra-website/pull/55
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF https://github.com/polymetric:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
> zsh) one of the invocations also had a missing right angle bracket
> * the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
> function {{toDate()}} is deprecated? I replaced it with the recommended
> {{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
> second error - {{1234}} is not a valid value for type "text." so I added
> single quotes and voila.
> * used a network to connect the database and shell containers because
> host.docker.internal does not work on Linux
> * added another step with a docker command to use cqlsh interactively (there
> wasn't one before, all the previous command in step 4 did was load data.cql,
> it did not start an interactive session, which was very confusing)
> * rewrote and reorganized some of the text due to the new step
> This should be tested on something other than Linux, because I haven't had a
> chance to do that.
> of course all these changes are subject to evaluation! I probably should've
> split it out into multiple commits. Hopefully the diff isn't too hard to
> read. Let me know if I forgot to mention something or you need anything
> clarified.
--
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-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16731:
--
Description:
ON BEHALF OF https://github.com/polymetric:
It looks like whoever wrote this quickstart guide wrote it without actually
testing. Nothing wrong with that, though! I did something like that just the
other day. But it should probably be fixed. Cassandra sounds awesome to me but
this didn't seem like the best way to give a first impression, so I tried my
hand at improving it.
list of changes:
* removed the authentication part as the test works fine without that and is
probably a bit out of the scope of this document
* replaced {{#}} comments in the CQL script with the proper {{--}}
* is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
zsh) one of the invocations also had a missing right angle bracket
* the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
function {{toDate()}} is deprecated? I replaced it with the recommended
{{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
second error - {{1234}} is not a valid value for type "text." so I added single
quotes and voila.
* used a network to connect the database and shell containers because
host.docker.internal does not work on Linux
* added another step with a docker command to use cqlsh interactively (there
wasn't one before, all the previous command in step 4 did was load data.cql, it
did not start an interactive session, which was very confusing)
* rewrote and reorganized some of the text due to the new step
This should be tested on something other than Linux, because I haven't had a
chance to do that.
of course all these changes are subject to evaluation! I probably should've
split it out into multiple commits. Hopefully the diff isn't too hard to read.
Let me know if I forgot to mention something or you need anything clarified.
was:
ON BEHALF OF ALEXANDER POMOSOV:
It looks like whoever wrote this quickstart guide wrote it without actually
testing. Nothing wrong with that, though! I did something like that just the
other day. But it should probably be fixed. Cassandra sounds awesome to me but
this didn't seem like the best way to give a first impression, so I tried my
hand at improving it.
list of changes:
* removed the authentication part as the test works fine without that and is
probably a bit out of the scope of this document
* replaced {{#}} comments in the CQL script with the proper {{--}}
* is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
zsh) one of the invocations also had a missing right angle bracket
* the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
function {{toDate()}} is deprecated? I replaced it with the recommended
{{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
second error - {{1234}} is not a valid value for type "text." so I added single
quotes and voila.
* used a network to connect the database and shell containers because
host.docker.internal does not work on Linux
* added another step with a docker command to use cqlsh interactively (there
wasn't one before, all the previous command in step 4 did was load data.cql, it
did not start an interactive session, which was very confusing)
* rewrote and reorganized some of the text due to the new step
This should be tested on something other than Linux, because I haven't had a
chance to do that.
of course all these changes are subject to evaluation! I probably should've
split it out into multiple commits. Hopefully the diff isn't too hard to read.
Let me know if I forgot to mention something or you need anything clarified.
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF https://github.com/polymetric:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}}
[jira] [Comment Edited] (CASSANDRA-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361507#comment-17361507
]
Erick Ramirez edited comment on CASSANDRA-16731 at 6/12/21, 12:25 AM:
--
Noting here that I've reached out to -Alexander Pomosov on ASF Slack-
[https://github.com/polymetric] to get their Jira username so I can attribute
this ticket appropriately.
was (Author: flightc):
Noting here that I've reached out to Alexander Pomosov on ASF Slack to get his
Jira username so I can attribute this ticket appropriately.
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF https://github.com/polymetric:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
> zsh) one of the invocations also had a missing right angle bracket
> * the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
> function {{toDate()}} is deprecated? I replaced it with the recommended
> {{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
> second error - {{1234}} is not a valid value for type "text." so I added
> single quotes and voila.
> * used a network to connect the database and shell containers because
> host.docker.internal does not work on Linux
> * added another step with a docker command to use cqlsh interactively (there
> wasn't one before, all the previous command in step 4 did was load data.cql,
> it did not start an interactive session, which was very confusing)
> * rewrote and reorganized some of the text due to the new step
> This should be tested on something other than Linux, because I haven't had a
> chance to do that.
> of course all these changes are subject to evaluation! I probably should've
> split it out into multiple commits. Hopefully the diff isn't too hard to
> read. Let me know if I forgot to mention something or you need anything
> clarified.
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16669:
Test and Documentation Plan:
[https://github.com/ekaterinadimitrova2/cassandra/pull/140]
Additional tests and docs added as part of the patch
was:
[https://github.com/ekaterinadimitrova2/cassandra/pull/140]
Additional tests added
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16669:
Test and Documentation Plan:
[https://github.com/ekaterinadimitrova2/cassandra/pull/140]
Additional tests added
was:[https://github.com/ekaterinadimitrova2/cassandra/pull/140]
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16669:
Reviewers: Ekaterina Dimitrova, Stefan Miklosovic, Vinay Chella, Ekaterina
Dimitrova (was: Ekaterina Dimitrova, Stefan Miklosovic, Vinay Chella)
Ekaterina Dimitrova, Stefan Miklosovic, Vinay Chella, Ekaterina
Dimitrova (was: Ekaterina Dimitrova, Stefan Miklosovic, Vinay Chella)
Status: Review In Progress (was: Patch Available)
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16669:
Test and Documentation Plan:
[https://github.com/ekaterinadimitrova2/cassandra/pull/140]
Status: Patch Available (was: In Progress)
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362196#comment-17362196
]
Adam Holmberg commented on CASSANDRA-16695:
---
+1 again, here. Thanks.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16733:
Reviewers: Andres de la Peña, Brandon Williams (was: Andres de la Peña,
Brandon Williams, Ekaterina Dimitrova)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16733:
Reviewers: Andres de la Peña, Brandon Williams, Ekaterina Dimitrova (was:
Andres de la Peña)
Status: Review In Progress (was: Patch Available)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16695:
--
Status: Ready to Commit (was: Review In Progress)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362078#comment-17362078
]
David Capwell commented on CASSANDRA-16695:
---
+1 to cassandra and Dtest commits
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362074#comment-17362074
]
Ekaterina Dimitrova commented on CASSANDRA-16695:
-
Great, so [~dcapwell], I assume now you are also +1 as a reviewer? I believe
this is THE test we needed. :)
I will propagate to all patches and run CI soon to commit it tonight if there
are no other concerns.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16695:
-
Reviewers: Adam Holmberg, Brandon Williams, David Capwell (was: Adam
Holmberg, David Capwell)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362046#comment-17362046
]
Brandon Williams commented on CASSANDRA-16695:
--
Added a cqlsh test for TLSv1.2
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-16695]
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-12519) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362042#comment-17362042
]
Stefania Alborghetti commented on CASSANDRA-12519:
--
{quote}
I'm not familiarized with the lifecycle package so I'm not sure whether
skipping the temporary sstables when resetting the levels is right, or whether
the validation error that happens after changing the metadata is caused by a
deeper problem.
{quote}
I would need to see the full reason why the transaction rejected a record and I
wasn't able to find a full failure, but it must have failed the checksum
verification because the metadata file is changed by the standalone tools,
{{sstablelevelreset}} in our case.
The transaction is checking if anything has tampered with a file guarded by it.
This is done by {{LogFile.verify()}} and would also prevent a main Cassandra
process from starting up. This is because there is some automated cleanup done
on startup when {{LogTransaction.removeUnfinishedLeftovers()}} is called. Since
we don't want to mistakenly delete files restored by users for example, we
check using a checksum which is calculated from the files that existed when the
transaction record was created. There are more checks but this is the main one
and the one that I believe must have failed.
So if anything changes any of these files, temporary or permanent, the
transaction detects it. These two standalone tools change the sstable metadata
and hence probably triggered it.
I think it's reasonable to change {{sstablelevelreset}} to skip temporary
files, because if the transaction did not complete, it's as if these files
never existed. However, I don't think this is sufficient to fix the problem,
because changing the old existing metadata files could also trigger a checksum
error. So I may be wrong, but it seems to me that the real fix is to use the
cleanup utility in the test, before running {{sstablelevelreset}} so that there
are no left over transactions.
If these two tools are likely to be used directly from users when the process
is offline, as they seem to be, I believe that they should cleanup leftover
transactions first, or at least issue a warning if there are any. Otherwise the
main process may refuse to start for the same reason explained above. To
cleanup leftovers we can simply call
{{LifecycleTransaction.removeUnfinishedLeftovers(cfs)}} from the tool itself,
before doing any work. We should consider a follow up to do this, or fix this
directly in this ticket. If we fix this here, then we don't need to do this in
the test.
So you can either merge what you have and open a follow up, or add
{{LifecycleTransaction.removeUnfinishedLeftovers(cfs)}}, as well as kipping the
temporary files (which seems more correct to me), and see if this fixes it
without changing the test.
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12519
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Sean McCarthy
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/379/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 209, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361994#comment-17361994 ] Brandon Williams commented on CASSANDRA-16735: -- +1 to revert for 4.0.0 > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361993#comment-17361993 ] Ekaterina Dimitrova commented on CASSANDRA-16735: - [~marcuse], I am not familiar with these works but I am trying to filter the blockers for 4.0.0 Jira board and I saw this ticket. Reading your thoughts in the description, do you think we can revert 15899 to unblock 4.0.0? > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16734) Remediate Cassandra 3.11.10 JAR dependency vulnerabilities
[ https://issues.apache.org/jira/browse/CASSANDRA-16734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16734: - Resolution: Invalid Status: Resolved (was: Triage Needed) Some of these have already been brought up and resolved as not being relevant, for instance CASSANDRA-16463. In any case we aren't going to upgrade these in blanket fashion, but on a case-by-case basis, so please file tickets for the specific libraries with vulnerabilities that affect the project. > Remediate Cassandra 3.11.10 JAR dependency vulnerabilities > --- > > Key: CASSANDRA-16734 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16734 > Project: Cassandra > Issue Type: Improvement > Components: Dependencies >Reporter: Daniel Gomez >Priority: Normal > > Several JAR dependencies are flagged in Cassandra 3.11.10 as having > vulnerabilities that have been fixed in newer releases. > The following is the Cassandra 3.11.10 source tree for their JAR > dependencies: > [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] > A possible fix strategy is to simply update the JARs to their newest version. > See the JAR files available for each vulnerable library: > * See > [https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.9.10.8] > * See [https://mvnrepository.com/artifact/io.netty/netty-all/4.1.65.Final] > * See > [https://mvnrepository.com/artifact/org.apache.thrift/libthrift/0.9.3-1] > * See > [https://mvnrepository.com/artifact/com.thinkaurelius.thrift/thrift-server/0.3.9] > * See [https://mvnrepository.com/artifact/com.google.guava/guava/30.1.1-jre] > * See [https://mvnrepository.com/artifact/ch.qos.logback/logback-core/1.2.3] > * See [https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.29] > * See [https://mvnrepository.com/artifact/commons-codec/commons-codec/1.15] -- 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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361960#comment-17361960
]
Brandon Williams edited comment on CASSANDRA-16695 at 6/11/21, 6:44 PM:
This LGTM too, +1.
was (Author: brandon.williams):
This LGTM too, and I also would prefer tests.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361960#comment-17361960
]
Brandon Williams commented on CASSANDRA-16695:
--
This LGTM too, and I also would prefer tests.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361958#comment-17361958
]
Sumanth Pasupuleti commented on CASSANDRA-16669:
I am out due to emergency. [~vinaykumarcse] / [~stefan.miklosovic] /
[~e.dimitrova] please take the patch forward, thank you!
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16732) Unable to replace node if cluster is in mixed major version
[
https://issues.apache.org/jira/browse/CASSANDRA-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361957#comment-17361957
]
Sumanth Pasupuleti edited comment on CASSANDRA-16732 at 6/11/21, 6:35 PM:
--
Yeah, I also realized I was wrong when I mentioned C* on this cluster includes
fix for CASSANDRA-16692. My bad. We can close this.
was (Author: sumanth.pasupuleti):
Yeah, I also realized I was wrong when I mentioned C* on this cluster includes
fix for CASSANDRA-16692. My bad. Closing this.
> Unable to replace node if cluster is in mixed major version
> ---
>
> Key: CASSANDRA-16732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16732
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x
>
>
> This should be independent of cluster size, but in my example repro, I have a
> 6 node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing
> any of the 3.0 nodes (such that new node bootstraps from neighbors) fails
> during the bootstrap phase of the new node with the below exception.
> This version of C* includes fix for CASSANDRA-16692.
> {code:java}
> ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> {code}
--
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-16732) Unable to replace node if cluster is in mixed major version
[
https://issues.apache.org/jira/browse/CASSANDRA-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361957#comment-17361957
]
Sumanth Pasupuleti commented on CASSANDRA-16732:
Yeah, I also realized I was wrong when I mentioned C* on this cluster includes
fix for CASSANDRA-16692. My bad. Closing this.
> Unable to replace node if cluster is in mixed major version
> ---
>
> Key: CASSANDRA-16732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16732
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x
>
>
> This should be independent of cluster size, but in my example repro, I have a
> 6 node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing
> any of the 3.0 nodes (such that new node bootstraps from neighbors) fails
> during the bootstrap phase of the new node with the below exception.
> This version of C* includes fix for CASSANDRA-16692.
> {code:java}
> ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> {code}
--
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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16735: Fix Version/s: 3.11.x 3.0.x 4.0-rc2 > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 4.0-rc2, 3.0.x, 3.11.x > > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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-16735) Adding columns via ALTER TABLE can generate corrupt sstables
[ https://issues.apache.org/jira/browse/CASSANDRA-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-16735: Bug Category: Parent values: Correctness(12982)Level 1 values: Unrecoverable Corruption / Loss(13161) Complexity: Normal Discovered By: Fuzz Test Severity: Critical Status: Open (was: Triage Needed) > Adding columns via ALTER TABLE can generate corrupt sstables > > > Key: CASSANDRA-16735 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair, Local/SSTable >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > > This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 > Basically the column placeholders introduced in 15899 can get read-repaired > in to the memtable and later flushed to disk and in some cases this can > conflict with the actual column (if the actual column is a collection for > example) and cause CorruptSSTableExceptions. > Fix is probably to just revert 15899, at least until if and when we find a > solution that we can rely on. Will post that + test next week. -- 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] [Created] (CASSANDRA-16735) Adding columns via ALTER TABLE can generate corrupt sstables
Marcus Eriksson created CASSANDRA-16735: --- Summary: Adding columns via ALTER TABLE can generate corrupt sstables Key: CASSANDRA-16735 URL: https://issues.apache.org/jira/browse/CASSANDRA-16735 Project: Cassandra Issue Type: Bug Components: Consistency/Repair, Local/SSTable Reporter: Marcus Eriksson Assignee: Marcus Eriksson This is similar to CASSANDRA-13004 and was caused by CASSANDRA-15899 Basically the column placeholders introduced in 15899 can get read-repaired in to the memtable and later flushed to disk and in some cases this can conflict with the actual column (if the actual column is a collection for example) and cause CorruptSSTableExceptions. Fix is probably to just revert 15899, at least until if and when we find a solution that we can rely on. Will post that + test next week. -- 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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16733:
--
Fix Version/s: 4.0-rc
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x, 4.0-rc
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16695:
Status: Review In Progress (was: Changes Suggested)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16695:
--
Status: Changes Suggested (was: Review In Progress)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-16695:
--
Reviewers: Adam Holmberg, David Capwell (was: Adam Holmberg)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361903#comment-17361903
]
David Capwell commented on CASSANDRA-16695:
---
bq. I am in favor of adding the tests now
Same, I rather have tests now to show that this works (4.0 lets us choose what
protocols we support, so we can disable 1.0 and 1.1 on the server and make sure
the client works).
The patch looks good to me, only small nits left on the commit (free to
ignore), but I would prefer to have tests showing that this patch fixes the
issue (and without this patch fails showing the issue)
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361902#comment-17361902
]
Andres de la Peña commented on CASSANDRA-16733:
---
It seems that the flag defaults to true in 3.0 and 3.11 but not in 4.0, is
there a reason to not always defaulting to false?
There is a trivial failure in
[{{CompactStorageUpgradeTest.compactStorageUpgradeTest}}|https://app.circleci.com/pipelines/github/blerer/cassandra/148/workflows/429e34ca-0ad1-4bda-aacc-bbc3a96c7c0d/jobs/1391]
due to the disabled drop compact storage. If I'm right JVM dtests don't use
{{test/conf/cassandra.yaml}}, we should enable the flag programmatically in
that test:
{code:java}
.withConfig(config -> config.with(GOSSIP,
NETWORK).set("enable_drop_compact_storage", true))
{code}
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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] [Created] (CASSANDRA-16734) Remediate Cassandra 3.11.10 JAR dependency vulnerabilities
Daniel Gomez created CASSANDRA-16734: Summary: Remediate Cassandra 3.11.10 JAR dependency vulnerabilities Key: CASSANDRA-16734 URL: https://issues.apache.org/jira/browse/CASSANDRA-16734 Project: Cassandra Issue Type: Improvement Components: Dependencies Reporter: Daniel Gomez Several JAR dependencies are flagged in Cassandra 3.11.10 as having vulnerabilities that have been fixed in newer releases. The following is the Cassandra 3.11.10 source tree for their JAR dependencies: [https://github.com/apache/cassandra/tree/181a4969290f1c756089b2993a638fe403bc1314/lib] A possible fix strategy is to simply update the JARs to their newest version. See the JAR files available for each vulnerable library: * See [https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind/2.9.10.8] * See [https://mvnrepository.com/artifact/io.netty/netty-all/4.1.65.Final] * See [https://mvnrepository.com/artifact/org.apache.thrift/libthrift/0.9.3-1] * See [https://mvnrepository.com/artifact/com.thinkaurelius.thrift/thrift-server/0.3.9] * See [https://mvnrepository.com/artifact/com.google.guava/guava/30.1.1-jre] * See [https://mvnrepository.com/artifact/ch.qos.logback/logback-core/1.2.3] * See [https://mvnrepository.com/artifact/org.yaml/snakeyaml/1.29] * See [https://mvnrepository.com/artifact/commons-codec/commons-codec/1.15] -- 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-15588) 4.0 quality testing: Cluster Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-15588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holmberg updated CASSANDRA-15588: -- Fix Version/s: (was: 4.0-rc) 4.0.x > 4.0 quality testing: Cluster Upgrade > > > Key: CASSANDRA-15588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15588 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.x > > > We've historically had numerous bugs concerning upgrading clusters from one > version to the other. Let's establish the supported upgrade path and ensure > that users can safely perform the upgrades in production. -- 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-15588) 4.0 quality testing: Cluster Upgrade
[ https://issues.apache.org/jira/browse/CASSANDRA-15588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361894#comment-17361894 ] Adam Holmberg commented on CASSANDRA-15588: --- FixVer update: all child tickets are done and related links are both 4.0.x > 4.0 quality testing: Cluster Upgrade > > > Key: CASSANDRA-15588 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15588 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/java, Test/dtest/python >Reporter: Josh McKenzie >Assignee: David Capwell >Priority: Normal > Fix For: 4.0.x > > > We've historically had numerous bugs concerning upgrading clusters from one > version to the other. Let's establish the supported upgrade path and ensure > that users can safely perform the upgrades in production. -- 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-16695) cqlsh should prefer newer TLS version by default
[
https://issues.apache.org/jira/browse/CASSANDRA-16695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361880#comment-17361880
]
Adam Holmberg commented on CASSANDRA-16695:
---
+1 on 4.0 patch.
{quote}I am wondering whether we should add them now or improve them after 4.0
{quote}
I am in favor of adding the tests now and improving later if it becomes a
problem.
> cqlsh should prefer newer TLS version by default
>
>
> Key: CASSANDRA-16695
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16695
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/cqlsh
>Reporter: Justin Chu
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: cqlsh
> Fix For: 4.0, 2.2.x, 3.0.x, 3.11.x, 4.0-rc, 4.x
>
>
> Some new JDK releases started to disable TLSv1.0 and TLSv1.1.
> [https://www.oracle.com/java/technologies/javase/8u291-relnotes.html]
>
> However, the code in:
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/sslhandling.py#L56-L65]
> is defaulting to those rather old versions,
> which could lead to the following problem:
> {code:java}
> ('Unable to connect to any servers', {'10.101.34.89:9042': error(1, u"Tried
> connecting to [('10.101.34.89', 9042)]. Last error: [SSL:
> WRONG_VERSION_NUMBER] wrong version number (_ssl.c:618)")}) {code}
>
> Python2 default TLS protocol
> [https://docs.python.org/2/library/ssl.html#ssl.PROTOCOL_TLS]
> Python3 default TLS protocol
> [https://docs.python.org/3/library/ssl.html#ssl.PROTOCOL_TLS]
>
>
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15269:
-
Fix Version/s: (was: 4.0-rc2)
(was: 4.0)
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16642) Create release branch cassandra-4.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16642:
---
Fix Version/s: (was: 4.0-rc)
4.0.x
> Create release branch cassandra-4.0
> ---
>
> Key: CASSANDRA-16642
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16642
> Project: Cassandra
> Issue Type: Task
> Components: Build
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> Figure out what needs to be done beyond the following…
> 1. Create release branch
> {code}
> git switch -c cassandra-4.0 trunk
> git push --set-upstream origin cassandra-4.0
> {code}
> 2. Bump trunk's version
> {code}
> git switch trunk
> # increment version to 4.1
> edit build.xml debian/changelog CHANGES.txt NEWS.txt
> {code}
> 3. Add pipeline to ci-cassandra
> https://github.com/apache/cassandra-builds/blob/trunk/jenkins-dsl/cassandra_job_dsl_seed.groovy#L51
> -4. Update website versions-
> (it not needed until a release is made)
> 5. Add dtest version and upgrade paths
> -
> https://github.com/apache/cassandra-dtest/blob/trunk/upgrade_tests/upgrade_manifest.py
> - https://github.com/apache/cassandra/blob/trunk/.circleci/config.yml#L2374
> -
> https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-test.sh#L31
> 6. Update how_to_commit documentation
> https://github.com/apache/cassandra/blob/trunk/doc/source/development/how_to_commit.rst
--
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-16649) Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created)
[ https://issues.apache.org/jira/browse/CASSANDRA-16649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Semb Wever updated CASSANDRA-16649: --- Fix Version/s: (was: 4.0-rc) 4.0.x > Add Versions.Major.v4X to Java DTests (after cassandra-4.0 branch was created) > -- > > Key: CASSANDRA-16649 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16649 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/java >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Fix For: 4.0.x, 4.x > > > - > https://github.com/apache/cassandra-in-jvm-dtest-api/compare/trunk...thelastpickle:mck/16649 > - > https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/16649/trunk > -- 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] [Issue Comment Deleted] (CASSANDRA-16689) Flaky LeaveAndBootstrapTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16689:
-
Comment: was deleted
(was: I think given it's experimental we should default the option to false, to
ensure the operator is aware of what is possible if this is enabled. Otherwise
+1.)
> Flaky LeaveAndBootstrapTest
> ---
>
> Key: CASSANDRA-16689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16689
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Failing in a circle run
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/309/workflows/a645b956-dcd7-431e-b109-7857af3c523f/jobs/2937]
> {noformat}
> Testcase:
> testStateJumpToNormal(org.apache.cassandra.service.LeaveAndBootstrapTest):
> Caused an ERROR
> [junit-timeout] null
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2418)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2756)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2299)
> [junit-timeout] at
> org.apache.cassandra.Util.createInitialRing(Util.java:236)
> [junit-timeout] at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testStateJumpToNormal(LeaveAndBootstrapTest.java:550)
> {noformat}
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361862#comment-17361862
]
Brandon Williams edited comment on CASSANDRA-16733 at 6/11/21, 3:57 PM:
I think we should default the flag to false to ensure the operator is aware of
what's possible when this is enabled (and it is experimental, after all.)
Otherwise +1.
was (Author: brandon.williams):
I think we should default the flag to false to ensure the operator is aware of
what's possible when this is enabled (and it is experiemental, after all.)
Otherwise +1.
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361862#comment-17361862
]
Brandon Williams commented on CASSANDRA-16733:
--
I think we should default the flag to false to ensure the operator is aware of
what's possible when this is enabled (and it is experiemental, after all.)
Otherwise +1.
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16733:
--
Reviewers: Andres de la Peña
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16689) Flaky LeaveAndBootstrapTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361860#comment-17361860
]
Brandon Williams commented on CASSANDRA-16689:
--
I think given it's experimental we should default the option to false, to
ensure the operator is aware of what is possible if this is enabled. Otherwise
+1.
> Flaky LeaveAndBootstrapTest
> ---
>
> Key: CASSANDRA-16689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16689
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Failing in a circle run
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/309/workflows/a645b956-dcd7-431e-b109-7857af3c523f/jobs/2937]
> {noformat}
> Testcase:
> testStateJumpToNormal(org.apache.cassandra.service.LeaveAndBootstrapTest):
> Caused an ERROR
> [junit-timeout] null
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2418)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2756)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2299)
> [junit-timeout] at
> org.apache.cassandra.Util.createInitialRing(Util.java:236)
> [junit-timeout] at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testStateJumpToNormal(LeaveAndBootstrapTest.java:550)
> {noformat}
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361857#comment-17361857
]
Benjamin Lerer commented on CASSANDRA-16733:
|| Branch || CI ||
|[3.0|https://github.com/apache/cassandra/pull/1061]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/147/workflows/69eda7e1-5e16-487e-9395-673ee0cfa1ca]|
|[3.11|https://github.com/apache/cassandra/pull/1062]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/146/workflows/1e2e31e1-d46f-4fcd-b9f7-d7829f5c9b3b]|
|[4.0|https://github.com/apache/cassandra/pull/1063]|[J8|https://app.circleci.com/pipelines/github/blerer/cassandra/148/workflows/429e34ca-0ad1-4bda-aacc-bbc3a96c7c0d],
[J11|https://app.circleci.com/pipelines/github/blerer/cassandra/148/workflows/a3d47204-e2b2-4680-8550-4d81857fb3dd]|
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16733:
---
Test and Documentation Plan: The patch add a test to check the flag behavior
Status: Patch Available (was: Open)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16689) Flaky LeaveAndBootstrapTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361849#comment-17361849
]
Andres de la Peña commented on CASSANDRA-16689:
---
I haven't been able to reproduce the failure in
{{LeaveAndBootstrapTest.testStateJumpToNormal}}, but I have found the same NPE
in {{LeaveAndBootstrapTest.newTestWriteEndpointsDuringLeave}} and
{{LeaveAndBootstrapTest.testSimultaneousMove}} while running the entire class
in the multiplexer 10K times:
||[j8-j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/575/workflows/2286e1e3-f103-422d-9492-c8c951b49e01/jobs/5367]||[j8-j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/575/workflows/2286e1e3-f103-422d-9492-c8c951b49e01/jobs/5368]||[j11-j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/575/workflows/9823e967-29ca-4f2f-ac5c-623b0dfca5b9/jobs/5361]||
The failure can also be reproduced by running {{testSimultaneousMove}} in
isolation, for example
[here|https://app.circleci.com/pipelines/github/adelapena/cassandra/576/workflows/9060086d-4c2a-4689-9987-bd3354532777/jobs/5377],
so it doesn't seem a problem of interaction between tests.
> Flaky LeaveAndBootstrapTest
> ---
>
> Key: CASSANDRA-16689
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16689
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.x
>
>
> Failing in a circle run
> [here|https://app.circleci.com/pipelines/github/bereng/cassandra/309/workflows/a645b956-dcd7-431e-b109-7857af3c523f/jobs/2937]
> {noformat}
> Testcase:
> testStateJumpToNormal(org.apache.cassandra.service.LeaveAndBootstrapTest):
> Caused an ERROR
> [junit-timeout] null
> [junit-timeout] java.lang.NullPointerException
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.updatePeerInfo(StorageService.java:2418)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.handleStateNormal(StorageService.java:2756)
> [junit-timeout] at
> org.apache.cassandra.service.StorageService.onChange(StorageService.java:2299)
> [junit-timeout] at
> org.apache.cassandra.Util.createInitialRing(Util.java:236)
> [junit-timeout] at
> org.apache.cassandra.service.LeaveAndBootstrapTest.testStateJumpToNormal(LeaveAndBootstrapTest.java:550)
> {noformat}
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16262: - Change Category: Quality Assurance Complexity: Normal Status: Open (was: Triage Needed) > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361837#comment-17361837
]
Michael Semb Wever edited comment on CASSANDRA-16704 at 6/11/21, 3:13 PM:
--
Testing both patches on this
[branch|https://github.com/apache/cassandra/compare/trunk...thelastpickle:mck/4.0/16704].
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
[!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/862/pipeline]
was (Author: michaelsembwever):
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
[!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/862/pipeline]
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: cleanup-imports.patch, dedup-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361840#comment-17361840 ] Andres de la Peña commented on CASSANDRA-16262: --- Great, thanks! > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361837#comment-17361837
]
Michael Semb Wever edited comment on CASSANDRA-16704 at 6/11/21, 3:10 PM:
--
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
[!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon!|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/862/pipeline]
was (Author: michaelsembwever):
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/862/pipeline!
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: cleanup-imports.patch, dedup-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361837#comment-17361837
]
Michael Semb Wever edited comment on CASSANDRA-16704 at 6/11/21, 3:09 PM:
--
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon|https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/862/pipeline!
was (Author: michaelsembwever):
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon|id=badgeUrl!
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: cleanup-imports.patch, dedup-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361839#comment-17361839 ] Brandon Williams commented on CASSANDRA-16262: -- I have done it. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-15579) 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15579:
-
Resolution: Fixed
Status: Resolved (was: Open)
Resolving per the discussion on CASSANDRA-16262
> 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication,
> and Read Repair
>
>
> Key: CASSANDRA-15579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15579
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: {color:#de350b}None{color}*
> Testing in this area focuses on non-node-local aspects of the read-write
> path: coordination, replication, read repair, etc.
--
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-15579) 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15579:
-
Status: Open (was: Patch Available)
> 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication,
> and Read Repair
>
>
> Key: CASSANDRA-15579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15579
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: {color:#de350b}None{color}*
> Testing in this area focuses on non-node-local aspects of the read-write
> path: coordination, replication, read repair, etc.
--
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-15579) 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication, and Read Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15579:
-
Test and Documentation Plan: test
Status: Patch Available (was: In Progress)
> 4.0 quality testing: Distributed Read/Write Path: Coordination, Replication,
> and Read Repair
>
>
> Key: CASSANDRA-15579
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15579
> Project: Cassandra
> Issue Type: Task
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: {color:#de350b}None{color}*
> Testing in this area focuses on non-node-local aspects of the read-write
> path: coordination, replication, read repair, etc.
--
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-16704) Fix imports; run tests with packaged dependencies
[
https://issues.apache.org/jira/browse/CASSANDRA-16704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361837#comment-17361837
]
Michael Semb Wever commented on CASSANDRA-16704:
Testing both patches.
Between builds on cassandra-4.0.0 and these patches, the {{lib/}} and
{{build/lib/jars/}} result in identical contents.
But the {{build/test/lib/jars/}} directory contains differences:
{code:java}
❯ diff <(ls build/test/lib/jars/) <(ls ../cassandra/build/test/lib/jars/)
11d10
< assertj-core-3.15.0.jar
15,18d13
< byteman-4.0.6.jar
< byteman-bmunit-4.0.6.jar
< byteman-install-4.0.6.jar
< byteman-submit-4.0.6.jar
22d16
< compile-command-annotations-1.2.0.jar {code}
;that is those jar files no longer appear under {{build/test/lib/jars/}} which
is the intentional of the patch (as they are already "provided" and so under
{{build/lib/jars/}}).
CI:
!https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/862/badge/icon|id=badgeUrl!
> Fix imports; run tests with packaged dependencies
> -
>
> Key: CASSANDRA-16704
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16704
> Project: Cassandra
> Issue Type: Bug
> Components: Build, Test/burn, Test/unit
>Reporter: Angelo Polo
>Assignee: Angelo Polo
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Attachments: cleanup-imports.patch, dedup-deps.patch
>
>
> Tests are currently run with a classpath containing _all_ downloaded jars.
> The tests would be more reflective of the behavior of a runtime environment
> if the test classpath only contained jars that are bundled with the binary
> release, together with explicit test dependencies. Ideally we'd use the
> build/lib/ jars for the classpath since that's what gets packaged, but since
> these aren't available at test compile time and should be identical to lib/
> anyway, I've used the later.
> Doing so exposed a couple of references in src/java to
> "org.apache.commons.lang", which is not available at runtime (should be
> "org.apache.commons.lang*3*").
> Attached patch modifies the test classpath, fixes various imports in both
> test/ and src/ classes, and makes some simple substitutions in the tests such
> as using AbstractMap.SimpleEntry in place of
> org.apache.commons.collections.keyvalue.AbstractMapEntry.
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16262: - Fix Version/s: (was: 4.0-rc) 4.x > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.x > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361835#comment-17361835 ] Alex Petrov commented on CASSANDRA-16262: - Sure, I'm good with this! > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361833#comment-17361833 ] Adam Holmberg commented on CASSANDRA-16262: --- I agree. I think it's time to re-assign or clear things that we are not posing as blockers. > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361780#comment-17361780
]
Stefan Miklosovic commented on CASSANDRA-16669:
---
Hey, I am running builds, I target the merging on Monday to sleep on it.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361769#comment-17361769
]
Ekaterina Dimitrova commented on CASSANDRA-16669:
-
Thank you all! [~sumanth.pasupuleti] already updated his PR and I am starting
another round of review.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16733:
---
Description:
{{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively tested
and suffer from several issues like:
* As COMPACT tables did not have primary key liveness there empty rows
inserted AFTER the ALTER will be returned whereas the one inserted before
the ALTER will not.
* Also due to the lack of primary key liveness the amount of SSTables being
read will increase resulting in slower queries (CASSANDRA-16675)
* After DROP COMPACT it becomes possible to ALTER the table in a way that
makes all the row disappears
* There is a loss of functionality around null clustering when dropping
compact storage (CASSANDRA-16069)
To avoid running into those issues this ticket will introduce a new flag that
allow operators to disable those statements on their clusters.
see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
was:
{{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively tested
and suffer from several issues like:
* As COMPACT tables did not have primary key liveness there empty rows
inserted AFTER the ALTER will be returned whereas the one inserted before
the ALTER will not.
* Also due to the lack of primary key liveness the amount of SSTables being
read will increase resulting in slower queries (CASSANDRA-16675)
* After DROP COMPACT it becomes possible to ALTER the table in a way that
makes all the row disappears
* There is a loss of functionality around null clustering when dropping
compact storage (CASSANDRA-16069)
To avoid running into those issues this ticket will introduce a new flag that
allow operators to disable those statements on their clusters.
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
> see https://www.mail-archive.com/dev@cassandra.apache.org/msg16789.html
--
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-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16733:
---
Bug Category: Parent values: Correctness(12982)
Complexity: Normal
Discovered By: User Report
Fix Version/s: 3.11.x
3.0.x
4.0-rc2
Severity: Normal
Status: Open (was: Triage Needed)
> Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
> --
>
> Key: CASSANDRA-16733
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 3.0.x, 3.11.x
>
>
> {{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively
> tested and suffer from several issues like:
> * As COMPACT tables did not have primary key liveness there empty rows
> inserted AFTER the ALTER will be returned whereas the one inserted before
> the ALTER will not.
> * Also due to the lack of primary key liveness the amount of SSTables being
> read will increase resulting in slower queries (CASSANDRA-16675)
> * After DROP COMPACT it becomes possible to ALTER the table in a way that
> makes all the row disappears
> * There is a loss of functionality around null clustering when dropping
> compact storage (CASSANDRA-16069)
> To avoid running into those issues this ticket will introduce a new flag that
> allow operators to disable those statements on their clusters.
--
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] [Created] (CASSANDRA-16733) Allow operators to disable 'ALTER ... DROP COMPACT STORAGE' statements
Benjamin Lerer created CASSANDRA-16733:
--
Summary: Allow operators to disable 'ALTER ... DROP COMPACT
STORAGE' statements
Key: CASSANDRA-16733
URL: https://issues.apache.org/jira/browse/CASSANDRA-16733
Project: Cassandra
Issue Type: Bug
Components: Legacy/CQL
Reporter: Benjamin Lerer
Assignee: Benjamin Lerer
{{ALTER ... DROP COMPACT STORAGE}} statements have not been extensively tested
and suffer from several issues like:
* As COMPACT tables did not have primary key liveness there empty rows
inserted AFTER the ALTER will be returned whereas the one inserted before
the ALTER will not.
* Also due to the lack of primary key liveness the amount of SSTables being
read will increase resulting in slower queries (CASSANDRA-16675)
* After DROP COMPACT it becomes possible to ALTER the table in a way that
makes all the row disappears
* There is a loss of functionality around null clustering when dropping
compact storage (CASSANDRA-16069)
To avoid running into those issues this ticket will introduce a new flag that
allow operators to disable those statements on their clusters.
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361712#comment-17361712
]
Benjamin Lerer commented on CASSANDRA-15269:
You should not get: 'system._modulo[decimal, decimal]' as it is supposed to be
hidden from the user. Instead we should have 'decimal % decimal' (as it is a
bit further in the message).
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16732) Unable to replace node if cluster is in mixed major version
[
https://issues.apache.org/jira/browse/CASSANDRA-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16732:
-
Resolution: Won't Fix
Status: Resolved (was: Triage Needed)
Generally, topology changes shouldn't be done in the middle of an upgrade, and
in that vein replacing in mixed versions isn't something we've ever supported
or tested and it doesn't make sense to begin doing so now.
> Unable to replace node if cluster is in mixed major version
> ---
>
> Key: CASSANDRA-16732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16732
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x
>
>
> This should be independent of cluster size, but in my example repro, I have a
> 6 node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing
> any of the 3.0 nodes (such that new node bootstraps from neighbors) fails
> during the bootstrap phase of the new node with the below exception.
> This version of C* includes fix for CASSANDRA-16692.
> {code:java}
> ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> {code}
--
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-12519) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-12519:
--
Test and Documentation Plan: The flaky test should survive a few thousand
runs
Status: Patch Available (was: In Progress)
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12519
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Sean McCarthy
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/379/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 209, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
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-16262) 4.0 Quality: Coordination & Replication Fuzz Testing
[ https://issues.apache.org/jira/browse/CASSANDRA-16262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361673#comment-17361673 ] Andres de la Peña commented on CASSANDRA-16262: --- I think we should, given that we are (hopefully) very close to GA. If it gets ready in time for GA we can always include it, but by now I will move it to 4.x and out of CASSANDRA-15579, so we can close the latter. wdyt? > 4.0 Quality: Coordination & Replication Fuzz Testing > > > Key: CASSANDRA-16262 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16262 > Project: Cassandra > Issue Type: Task > Components: Test/fuzz >Reporter: Caleb Rackliffe >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-rc > > > CASSANDRA-16180, CASSANDRA-16181, and CASSANDRA-15977 have largely focused on > auditing the existing tests around coordination, replication, and > read-repair, respectively. We've expanded existing test cases, added coverage > around components that we've refactored along the way, and added in-JVM dtest > upgrade tests where possible. > What remains is verifying the distributed read and write paths in the face of > common operational events, namely node restarts, bootstrapping, decommission, > and cleanup. If we can find a way to simulate these events, > [Harry|https://github.com/apache/cassandra-harry] seems like a good candidate > to host the verification logic itself. > To keep things simple initially, I would propose that we start by testing > simple read-only and write-only workloads (the former without read repair). -- 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-12519) dtest failure in offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
[
https://issues.apache.org/jira/browse/CASSANDRA-12519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361668#comment-17361668
]
Andres de la Peña commented on CASSANDRA-12519:
---
It seems the problem is caused by {{sstablelevelreset}} editing the metadata of
temporary tables. When this happens the next call to
{{Directories#sstableLister}} finds the validation problem. This call happens
in the following call to {{sstableoflinerelevel}}, and it would also happen if
we called {{sstablelevelreset}} again. The problem goes away if we modify
{{sstablelevelreset}} to skip temporary tables, as it's done in [the proposed
PR|https://github.com/apache/cassandra/pull/1058].
Additionally, [the PR for
dtests|https://github.com/apache/cassandra-dtest/pull/144] cleans up the
outstanding transactions with {{sstableutil}} just because the dtest doesn't
have a way to get the levels of only the non-temporary sstables since it uses
{{sstablemetadata}}, which AFAIK doesn't have a way to skip the temporary
sstables.
I'm not familiarized with the {{lifecycle}} package so I'm not sure whether
skipping the temporary sstables when resetting the levels is right, or whether
the validation error that happens after changing the metadata is caused by a
deeper problem. [~marcuse] [~stefania_alborghetti] I think you might be more
familiarized with the related areas of the codebase, would you mind taking a
look?
Here is a CircleCI round including 2k multiplexed runs of the failing tests:
*
[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/573/workflows/0f933cad-d639-4a80-8e93-ce1d0dca]
*
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/573/workflows/2149e1ff-1dc8-4816-8678-a864722a228d]
> dtest failure in
> offline_tools_test.TestOfflineTools.sstableofflinerelevel_test
> ---
>
> Key: CASSANDRA-12519
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12519
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/dtest/python
>Reporter: Sean McCarthy
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 3.0.x, 3.11.x, 4.x
>
> Attachments: node1.log, node1_debug.log, node1_gc.log
>
>
> example failure:
> http://cassci.datastax.com/job/trunk_offheap_dtest/379/testReport/offline_tools_test/TestOfflineTools/sstableofflinerelevel_test/
> {code}
> Stacktrace
> File "/usr/lib/python2.7/unittest/case.py", line 329, in run
> testMethod()
> File "/home/automaton/cassandra-dtest/offline_tools_test.py", line 209, in
> sstableofflinerelevel_test
> self.assertGreater(max(final_levels), 1)
> File "/usr/lib/python2.7/unittest/case.py", line 942, in assertGreater
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib/python2.7/unittest/case.py", line 410, in fail
> raise self.failureException(msg)
> "1 not greater than 1
> {code}
--
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-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16671:
---
Fix Version/s: (was: 4.0-rc)
(was: 3.11.x)
(was: 4.x)
(was: 3.0.x)
4.0
4.0-rc2
3.11.11
3.0.25
Since Version: 3.11.10
Source Control Link:
https://github.com/apache/cassandra/commit/24346d17899df8610a5f425c7074ddd5dc8082bb
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 3.0 at 24346d17899df8610a5f425c7074ddd5dc8082bb and merged into
3.11, 4.0.0, 4.0 and trunk
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
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-16671) Cassandra can return no row when the row columns have been deleted.
[
https://issues.apache.org/jira/browse/CASSANDRA-16671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361562#comment-17361562
]
Benjamin Lerer commented on CASSANDRA-16671:
[~maedhroz] thanks for the fast review.
Sorry, I missed the nits in 3.0 :-(
I have a followup patch that will touch this area on 3.0. I will incorporate
them in it.
> Cassandra can return no row when the row columns have been deleted.
> ---
>
> Key: CASSANDRA-16671
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16671
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Local Write-Read Paths
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc, 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> It is the semantic of CQL that a (CQL) row exists as long as it has one
> non-null column (including the PK columns).
> To determine if a row has some *non-null primary key*, Cassandra relies on
> the row primary key liveness.
> For example:
> {code}
> CREATE TABLE test (pk int, ck int, v int, PRIMARY KEY(pk, ck));
> INSERT INTO test(pk, ck, v) VALUES (1, 1, 1);
> DELETE v FROM test WHERE pk = 1 AND ck = 1
> SELECT v FROM test;
> {code}
> will return
> {code}
> v
> ---
> null
> {code}
> {{UPDATE}} statements do not set the row primary key liveness by consequence
> if the user had used an {{UPDATE}} statement instead of an {{INSERT}} the
> {{SELECT}} query would *not have returned any rows*.
> CASSANDRA-16226 introduced a regression by stopping early in the timestamp
> ordered logic if an {{UPDATE}} statement covering all the columns was found
> in an SSTable. As the row returned did not have a primary key liveness if
> another node was also returning a column deletion, the expected row will not
> be returned.
> The problem can be reproduced with the following test:
> {code}
>@Test
> public void
> testSelectWithUpdatedColumnOnOneNodeAndColumnDeletionOnTheOther() throws
> Throwable
> {
> try (Cluster cluster = init(builder().withNodes(2).start()))
> {
> cluster.schemaChange(withKeyspace("CREATE TABLE %s.tbl (pk int,
> ck text, v int, PRIMARY KEY (pk, ck))"));
> cluster.get(1).executeInternal(withKeyspace("INSERT INTO %s.tbl
> (pk, ck, v) VALUES (1, '1', 1) USING TIMESTAMP 1000"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(1).executeInternal(withKeyspace("UPDATE %s.tbl USING
> TIMESTAMP 2000 SET v = 2 WHERE pk = 1 AND ck = '1'"));
> cluster.get(1).flush(KEYSPACE);
> cluster.get(2).executeInternal(withKeyspace("DELETE v FROM %s.tbl
> USING TIMESTAMP 3000 WHERE pk=1 AND ck='1'"));
> cluster.get(2).flush(KEYSPACE);
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT *
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row(1, "1", null)); // <-- FAIL
> assertRows(cluster.coordinator(2).execute(withKeyspace("SELECT v
> FROM %s.tbl WHERE pk=1 AND ck='1'"), ConsistencyLevel.ALL),
>row((Integer) null));
> }
> }
> {code}
> cc: [~maedhroz], [~ifesdjeen]
--
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
[cassandra] 01/01: Merge branch cassandra-4.0 into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit aaf653700febee2b6375a13387afe2dd23a349c3 Merge: d0a05b9 7d4ee38 Author: Benjamin Lerer AuthorDate: Fri Jun 11 10:57:30 2021 +0200 Merge branch cassandra-4.0 into trunk CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 143 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 772 insertions(+), 18 deletions(-) diff --cc CHANGES.txt index 637f045,a086d24..2cd9182 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -24,8 -21,9 +24,9 @@@ Merged from 3.11 * Nodetool garbagecollect should retain SSTableLevel for LCS (CASSANDRA-16634) * Ignore stale acks received in the shadow round (CASSANDRA-16588) Merged from 3.0: + * Ensure that existing empty rows are properly returned (CASSANDRA-16671) * Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked (CASSANDRA-16581) - * Don't wait on schema versions from replacement target when replacing a node (CASSANDRA-16692) + * Don't wait on schema versions from replacement target when replacing a node * StandaloneVerifier does not fail when unable to verify SSTables, it only fails if Corruption is thrown (CASSANDRA-16683) * Fix bloom filter false ratio calculation by including true negatives (CASSANDRA-15834) * Prevent loss of commit log data when moving sstables between nodes (CASSANDRA-16619) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated (a9f472c -> 24346d1)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from a9f472c Fix flaky NativeAllocatorTest.testBookKeeping test patch by Ekaterina Dimitrova; reviewed by Andres de la Pena and Berenguer Blasi for CASSANDRA-16690 add 24346d1 Ensure that existing empty rows are properly returned No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 147 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 777 insertions(+), 17 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/SinglePartitionReadCommandTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0.0 updated (14fd0ad -> 351c659)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 14fd0ad Fix StreamingMetricTests flakiness add 24346d1 Ensure that existing empty rows are properly returned add 5a7326d Merge branch cassandra-3.0 into cassandra-3.11 add 351c659 Merge branch cassandra-3.11 into cassandra-4.0.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 143 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 772 insertions(+), 18 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/SinglePartitionReadCommandTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (27f4cb6 -> 5a7326d)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 27f4cb6 Merge branch 'cassandra-3.0' into cassandra-3.11 add 24346d1 Ensure that existing empty rows are properly returned add 5a7326d Merge branch cassandra-3.0 into cassandra-3.11 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 147 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 777 insertions(+), 17 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/SinglePartitionReadCommandTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16671) Cassandra can return no row when the row columns have been deleted.
[cassandra] branch cassandra-4.0 updated (0aa3a7a -> 7d4ee38)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 0aa3a7a Merge branch cassandra-4.0.0 into cassandra-4.0 add 24346d1 Ensure that existing empty rows are properly returned add 5a7326d Merge branch cassandra-3.0 into cassandra-3.11 add 351c659 Merge branch cassandra-3.11 into cassandra-4.0.0 add 7d4ee38 Merge branch 'cassandra-4.0.0' into cassandra-4.0 No new revisions were added by this update. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 143 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 772 insertions(+), 18 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/SinglePartitionReadCommandTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (d0a05b9 -> aaf6537)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from d0a05b9 Merge branch cassandra-4.0 into trunk add 24346d1 Ensure that existing empty rows are properly returned add 5a7326d Merge branch cassandra-3.0 into cassandra-3.11 add 351c659 Merge branch cassandra-3.11 into cassandra-4.0.0 add 7d4ee38 Merge branch 'cassandra-4.0.0' into cassandra-4.0 new aaf6537 Merge branch cassandra-4.0 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: CHANGES.txt| 1 + .../cassandra/db/SinglePartitionReadCommand.java | 14 +- .../test/SinglePartitionReadCommandTest.java | 143 + .../miscellaneous/SSTablesIteratedTest.java| 632 - 4 files changed, 772 insertions(+), 18 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/test/SinglePartitionReadCommandTest.java - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-builds] branch trunk updated (be0e963 -> 84ea05d)
This is an automated email from the ASF dual-hosted git repository. mck pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git. from be0e963 more 4.0.0 additions for jdk version/dtest upgrades add d2d0d76 Clean up any "org.apache.cassandra" processes that are left dangling after jobs complete (if the agent is otherwise idle) add 84ea05d For every Jenkins job, add the nightlies location for the reports and logs in the console log No new revisions were added by this update. Summary of changes: jenkins-dsl/cassandra_job_dsl_seed.groovy | 40 --- 1 file changed, 32 insertions(+), 8 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361546#comment-17361546
]
Berenguer Blasi commented on CASSANDRA-15269:
-
Thx!
So if I didn't get things wrong is this what we're after?
{noformat}
[cqlsh 6.0.0 | Cassandra 4.0-rc2-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh> select numerator % denominator from test.d;
Traceback (most recent call last):
File "/home/bereng/work/repos/bdpWS/15269/bin/cqlsh.py", line 1076, in
perform_simple_statement
result = future.result()
File
"/home/bereng/work/repos/bdpWS/15269/bin/../lib/cassandra-driver-internal-only-3.25.0.zip/cassandra-driver-3.25.0/cassandra/cluster.py",
line 4894, in result
raise self._final_exception
cassandra.FunctionFailure: Error from server: code=1400 [User Defined Function
failure] message="execution of 'system._modulo[decimal, decimal]' failed: the
operation 'decimal % decimal' failed: Division impossible"
cqlsh> select * from test.d;
numerator| denominator
--+-
123456789112345678921234567893123456 | 2
(1 rows)
{noformat}
PR is [here|https://github.com/apache/cassandra/pull/1057] with the mentioned
revert so that it can be tested with the repro steps at the top of the ticket.
Once we agree is good I'll remove the revert.
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15269:
Status: Review In Progress (was: Changes Suggested)
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-15269:
Fix Version/s: 4.0.x
4.0
4.0-rc2
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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] [Assigned] (CASSANDRA-15269) Cassandra fails to process OperationExecutionException which causes ClassCastException
[
https://issues.apache.org/jira/browse/CASSANDRA-15269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-15269:
---
Assignee: Berenguer Blasi (was: Liudmila Kornilova)
> Cassandra fails to process OperationExecutionException which causes
> ClassCastException
> --
>
> Key: CASSANDRA-15269
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15269
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Liudmila Kornilova
>Assignee: Berenguer Blasi
>Priority: Normal
>
> While working on CASSANDRA-15232 I noticed that OperationExecutionException
> is not processed correctly.
> How to reproduce the issue:
> 1. {{create table d (numerator decimal primary key, denominator decimal);}}
> 2. {{insert into d (numerator, denominator) values
> (123456789112345678921234567893123456, 2);}}
> 3. {{select numerator % denominator from d;}}
> What happens:
> 1. remainder operation throws ArithmeticException (BigDecimal:1854)
> 2. The exception is wrapped in OperationExecutionException
> 3. ClassCastException appears (OperationExecutionException cannot be cast to
> FunctionExecutionException at ErrorMessage.java:280)
> What should happen:
> OperationExecutionException with message "the operation 'decimal % decimal'
> failed: Division impossible" should be delivered to user
> Note that after fixing CASSANDRA-15232 {{select numerator % denominator from
> d;}} will produce correct result of remainder operation.
> Currently I am not aware of other cases when OperationExecutionException may
> be treated as FunctionExecutionException
--
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-16598) Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes - org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16598:
---
Fix Version/s: (was: 4.0-rc)
4.0
4.0-rc2
> Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes -
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
> -
>
> Key: CASSANDRA-16598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16598
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: David Capwell
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/882/workflows/8e34d09d-5908-495f-baac-5402e0c8e6ee/jobs/5276
> {code}
> junit.framework.AssertionFailedError: expected:<[0]> but was:<[2]>
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithStreamingFromTwoNodes(StreamingMetricsTest.java:88)
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithRepairAndStreamingFromTwoNodes(StreamingMetricsTest.java:48)
> {code}
--
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-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16731:
--
Source Control Link:
https://github.com/apache/cassandra-website/commit/47afc100a3029f299d28824756f8b5014f96e0ba
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thanks [~mck] for merging the PR as commit
[47afc10|https://github.com/apache/cassandra-website/commit/47afc100a3029f299d28824756f8b5014f96e0ba].
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF ALEXANDER POMOSOV:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
> zsh) one of the invocations also had a missing right angle bracket
> * the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
> function {{toDate()}} is deprecated? I replaced it with the recommended
> {{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
> second error - {{1234}} is not a valid value for type "text." so I added
> single quotes and voila.
> * used a network to connect the database and shell containers because
> host.docker.internal does not work on Linux
> * added another step with a docker command to use cqlsh interactively (there
> wasn't one before, all the previous command in step 4 did was load data.cql,
> it did not start an interactive session, which was very confusing)
> * rewrote and reorganized some of the text due to the new step
> This should be tested on something other than Linux, because I haven't had a
> chance to do that.
> of course all these changes are subject to evaluation! I probably should've
> split it out into multiple commits. Hopefully the diff isn't too hard to
> read. Let me know if I forgot to mention something or you need anything
> clarified.
--
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-16598) Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes - org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-16598:
---
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/14fd0ad4e3102ec626af22e5007663526fbebbbe
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into 4.0.0 at 14fd0ad4e3102ec626af22e5007663526fbebbbe and merged
into 4.0 and trunk
> Fix flaky test testMetricsWithRepairAndStreamingFromTwoNodes -
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest
> -
>
> Key: CASSANDRA-16598
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16598
> Project: Cassandra
> Issue Type: Bug
> Components: CI, Test/dtest/java
>Reporter: David Capwell
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 4.0-rc
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/882/workflows/8e34d09d-5908-495f-baac-5402e0c8e6ee/jobs/5276
> {code}
> junit.framework.AssertionFailedError: expected:<[0]> but was:<[2]>
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithStreamingFromTwoNodes(StreamingMetricsTest.java:88)
> at
> org.apache.cassandra.distributed.test.metrics.StreamingMetricsTest.testMetricsWithRepairAndStreamingFromTwoNodes(StreamingMetricsTest.java:48)
> {code}
--
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
[cassandra] branch cassandra-4.0 updated (1676add -> 0aa3a7a)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 1676add Merge branch 'cassandra-4.0.0' into cassandra-4.0 add 14fd0ad Fix StreamingMetricTests flakiness add 0aa3a7a Merge branch cassandra-4.0.0 into cassandra-4.0 No new revisions were added by this update. Summary of changes: .../test/metrics/StreamingMetricsTest.java | 33 +++--- 1 file changed, 17 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0.0 updated (23ad7c3 -> 14fd0ad)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch cassandra-4.0.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 23ad7c3 Flaky ActiveRepairServiceTest.testRejectWhenPoolFullStrategy add 14fd0ad Fix StreamingMetricTests flakiness No new revisions were added by this update. Summary of changes: .../test/metrics/StreamingMetricsTest.java | 33 +++--- 1 file changed, 17 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch cassandra-4.0 into trunk
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d0a05b9ed727a4a228d50c37eb6b366817998082 Merge: 698078f 0aa3a7a Author: Benjamin Lerer AuthorDate: Fri Jun 11 10:02:52 2021 +0200 Merge branch cassandra-4.0 into trunk .../test/metrics/StreamingMetricsTest.java | 33 +++--- 1 file changed, 17 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (698078f -> d0a05b9)
This is an automated email from the ASF dual-hosted git repository. blerer pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 698078f Merge branch 'cassandra-4.0' into trunk add 14fd0ad Fix StreamingMetricTests flakiness add 0aa3a7a Merge branch cassandra-4.0.0 into cassandra-4.0 new d0a05b9 Merge branch cassandra-4.0 into trunk The 1 revisions listed above as "new" are entirely new to this repository and will be described in separate emails. The revisions listed as "add" were already present in the repository and have only been added to this reference. Summary of changes: .../test/metrics/StreamingMetricsTest.java | 33 +++--- 1 file changed, 17 insertions(+), 16 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16731:
--
Status: Ready to Commit (was: Review In Progress)
APPROVED – Overall, the changes look good to me.
For future reference, I'd recommend using the tag instead of so
the indentation is preserved. For example, the CQL statements in step 3 don't
display as intended in the markup. It's not a deal-breaker since these pages
will be re-published soon when Antora is productionised.
Thanks for pushing the update, Alexander. Cheers!
!CASSANDRA-16731-page_1.png|width=300!
!CASSANDRA-16731-page_2.png|width=300!
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF ALEXANDER POMOSOV:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
> zsh) one of the invocations also had a missing right angle bracket
> * the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
> function {{toDate()}} is deprecated? I replaced it with the recommended
> {{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
> second error - {{1234}} is not a valid value for type "text." so I added
> single quotes and voila.
> * used a network to connect the database and shell containers because
> host.docker.internal does not work on Linux
> * added another step with a docker command to use cqlsh interactively (there
> wasn't one before, all the previous command in step 4 did was load data.cql,
> it did not start an interactive session, which was very confusing)
> * rewrote and reorganized some of the text due to the new step
> This should be tested on something other than Linux, because I haven't had a
> chance to do that.
> of course all these changes are subject to evaluation! I probably should've
> split it out into multiple commits. Hopefully the diff isn't too hard to
> read. Let me know if I forgot to mention something or you need anything
> clarified.
--
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] [Created] (CASSANDRA-16732) Unable to replace node if cluster is in mixed major version
Sumanth Pasupuleti created CASSANDRA-16732:
--
Summary: Unable to replace node if cluster is in mixed major
version
Key: CASSANDRA-16732
URL: https://issues.apache.org/jira/browse/CASSANDRA-16732
Project: Cassandra
Issue Type: Bug
Reporter: Sumanth Pasupuleti
This should be independent of cluster size, but in my example repro, I have a 6
node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing any of
the 3.0 nodes (such that new node bootstraps from neighbors) fails during the
bootstrap phase of the new node with the below exception.
This version of C* includes fix for CASSANDRA-16692.
{code:java}
ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception
encountered during startup
java.lang.RuntimeException: Didn't receive schemas for all known versions
within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
at
org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909)
~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960)
~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374)
[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
[nf-cassandra-3.0.25.1.jar:3.0.25.1]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809)
[nf-cassandra-3.0.25.1.jar:3.0.25.1]
{code}
--
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-16732) Unable to replace node if cluster is in mixed major version
[
https://issues.apache.org/jira/browse/CASSANDRA-16732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sumanth Pasupuleti updated CASSANDRA-16732:
---
Fix Version/s: 3.0.x
> Unable to replace node if cluster is in mixed major version
> ---
>
> Key: CASSANDRA-16732
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16732
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sumanth Pasupuleti
>Priority: Normal
> Fix For: 3.0.x
>
>
> This should be independent of cluster size, but in my example repro, I have a
> 6 node cluster where 5 nodes are on 3.0, one node is on 2.1, and replacing
> any of the 3.0 nodes (such that new node bootstraps from neighbors) fails
> during the bootstrap phase of the new node with the below exception.
> This version of C* includes fix for CASSANDRA-16692.
> {code:java}
> ERROR [main] 2021-06-11 07:47:36,500 CassandraDaemon.java:822 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:909)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:960)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:659)
> ~[nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:374)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:616)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:809)
> [nf-cassandra-3.0.25.1.jar:3.0.25.1]
> {code}
--
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-16731) DOC - Refactor /quickstart guide
[
https://issues.apache.org/jira/browse/CASSANDRA-16731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Ramirez updated CASSANDRA-16731:
--
Attachment: CASSANDRA-16731-page_1.png
CASSANDRA-16731-page_2.png
> DOC - Refactor /quickstart guide
>
>
> Key: CASSANDRA-16731
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16731
> Project: Cassandra
> Issue Type: Task
> Components: Legacy/Documentation and Website
>Reporter: Erick Ramirez
>Assignee: Erick Ramirez
>Priority: Normal
> Fix For: 4.0-rc2, 4.0
>
> Attachments: CASSANDRA-16731-page_1.png, CASSANDRA-16731-page_2.png
>
>
> ON BEHALF OF ALEXANDER POMOSOV:
> It looks like whoever wrote this quickstart guide wrote it without actually
> testing. Nothing wrong with that, though! I did something like that just the
> other day. But it should probably be fixed. Cassandra sounds awesome to me
> but this didn't seem like the best way to give a first impression, so I tried
> my hand at improving it.
> list of changes:
> * removed the authentication part as the test works fine without that and is
> probably a bit out of the scope of this document
> * replaced {{#}} comments in the CQL script with the proper {{--}}
> * is now {{$(pwd)}} as the former did not work on my system (Pop_OS 20.10,
> zsh) one of the invocations also had a missing right angle bracket
> * the functions {{toTimeStamp(toDate(now))}} threw an error. Apparently, the
> function {{toDate()}} is deprecated? I replaced it with the recommended
> {{toTimeStamp(now())}} ({{now}} was also missing its {{()}}) and ran into a
> second error - {{1234}} is not a valid value for type "text." so I added
> single quotes and voila.
> * used a network to connect the database and shell containers because
> host.docker.internal does not work on Linux
> * added another step with a docker command to use cqlsh interactively (there
> wasn't one before, all the previous command in step 4 did was load data.cql,
> it did not start an interactive session, which was very confusing)
> * rewrote and reorganized some of the text due to the new step
> This should be tested on something other than Linux, because I haven't had a
> chance to do that.
> of course all these changes are subject to evaluation! I probably should've
> split it out into multiple commits. Hopefully the diff isn't too hard to
> read. Let me know if I forgot to mention something or you need anything
> clarified.
--
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
