[jira] [Assigned] (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
]
Sumanth Pasupuleti reassigned CASSANDRA-16669:
--
Assignee: Sumanth Pasupuleti
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
>
> 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
]
Vinay Chella updated CASSANDRA-16669:
-
Description:
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
was:
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}
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Priority: Normal
> Labels: audit, security
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit
[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
[
https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344947#comment-17344947
]
Vinay Chella commented on CASSANDRA-12151:
--
{quote}going though this, this still does not have password obfuscation as
[~vinaykumarcse] mentioned (together with [~eanujwa]).
{quote}
That is correct [~stefan.miklosovic], CASSANDRA-16669 to track the same.
> Audit logging for database activity
> ---
>
> Key: CASSANDRA-12151
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12151
> Project: Cassandra
> Issue Type: New Feature
>Reporter: stefan setyadi
>Assignee: Vinay Chella
>Priority: Normal
> Labels: fqltool
> Fix For: 4.0, 4.0-alpha1
>
> Attachments: 12151.txt, CASSANDRA_12151-benchmark.html,
> DesignProposal_AuditingFeature_ApacheCassandra_v1.docx
>
>
> we would like a way to enable cassandra to log database activity being done
> on our server.
> It should show username, remote address, timestamp, action type, keyspace,
> column family, and the query statement.
> it should also be able to log connection attempt and changes to the
> user/roles.
> I was thinking of making a new keyspace and insert an entry for every
> activity that occurs.
> Then It would be possible to query for specific activity or a query targeting
> a specific keyspace and column family.
--
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
]
Vinay Chella updated CASSANDRA-16669:
-
Description:
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}
was:
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.
Workaround to avoid plain text passwords from being logged in audit log files:
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}
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Priority: Normal
> Labels: audit, security
>
> 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
>
[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
]
Vinay Chella updated CASSANDRA-16669:
-
Labels: audit security (was: )
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Priority: Normal
> Labels: audit, security
>
> 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.
> Workaround to avoid plain text passwords from being logged in audit log
> files: 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}
--
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-16669) Password obfuscation for DCL audit log statements
Vinay Chella created CASSANDRA-16669:
Summary: Password obfuscation for DCL audit log statements
Key: CASSANDRA-16669
URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
Project: Cassandra
Issue Type: Improvement
Components: Tool/auditlogging
Reporter: Vinay Chella
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.
Workaround to avoid plain text passwords from being logged in audit log files:
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}
--
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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344927#comment-17344927 ] David Capwell commented on CASSANDRA-16581: --- [~samt] tests are stable now with the latest commit and python dtest changes; will work on back porting the changes > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344919#comment-17344919
]
Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/14/21, 11:26 PM:
[4.0 patch|
https://github.com/apache/cassandra/commit/3257230e32223cae3edcdfdd15fd5cfdd47d2ca7]
is merged to
[trunk|https://github.com/apache/cassandra/pull/1008/commits/c53226d1279f3606edcc258b8499f69c056b91c8].
Last CI runs:
4.0: [Java 8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/f6d8aeee-48c1-44a8-b79f-be3ca4085781]
| [Java 11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/1742730b-a0ea-4a84-bcfc-2fad18d6315a]
trunk: [Java 8
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/0e39bfe8-f4a3-455a-93f8-5a3c744cb0f9]
| [Java 11
|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/f4385c8b-7ef3-4e6d-93ef-4ebd6f8acb78]
NOTE: The trunk branch name says different Jira number by mistake, but the
content is there, don't get confused. I saw the mistake only after I pushed the
branch to CI
was (Author: e.dimitrova):
[4.0 patch| ] is merged to [trunk|].
Last CI runs:
4.0: [Java 8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/f6d8aeee-48c1-44a8-b79f-be3ca4085781]
| [Java 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/1742730b-a0ea-4a84-bcfc-2fad18d6315a]
trunk: [Java 8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/0e39bfe8-f4a3-455a-93f8-5a3c744cb0f9]
| [Java 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/f4385c8b-7ef3-4e6d-93ef-4ebd6f8acb78]
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344919#comment-17344919
]
Ekaterina Dimitrova commented on CASSANDRA-16659:
-
[4.0 patch| ] is merged to [trunk|].
Last CI runs:
4.0: [Java 8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/f6d8aeee-48c1-44a8-b79f-be3ca4085781]
| [Java 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/826/workflows/1742730b-a0ea-4a84-bcfc-2fad18d6315a]
trunk: [Java 8 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/0e39bfe8-f4a3-455a-93f8-5a3c744cb0f9]
| [Java 11 |
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/828/workflows/f4385c8b-7ef3-4e6d-93ef-4ebd6f8acb78]
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This message was sent by Atlassian Jira
[jira] [Updated] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16659:
Status: Ready to Commit (was: Review In Progress)
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16619) Loss of commit log data possible after sstable ingest
[ https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344917#comment-17344917 ] Ekaterina Dimitrova commented on CASSANDRA-16619: - Thank you [~jlewandowski], I will review the patch on Monday > Loss of commit log data possible after sstable ingest > - > > Key: CASSANDRA-16619 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16619 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0 > > Time Spent: 40m > Remaining Estimate: 0h > > SSTable metadata contains commit log positions of the sstable. These > positions are used to filter out mutations from the commit log on restart and > only make sense for the node on which the data was flushed. > If an SSTable is moved between nodes they may cover regions that the > receiving node has not yet flushed, and result in valid data being lost > should these sections of the commit log need to be replayed. > Solution: > The chosen solution introduces a new sstable metadata (StatsMetadata) - > originatingHostId (UUID), which is the local host id of the node on which the > sstable was created, or null if not known. Commit log intervals from an > sstable are taken into account during Commit Log replay only when the > originatingHostId of the sstable matches the local node's hostId. > For new sstables the originatingHostId is set according to StorageService's > local hostId. > For compacted sstables the originatingHostId set according to > StorageService's local hostId, and only commit log intervals from local > sstables is preserved in the resulting sstable. > discovered by [~jakubzytka] -- 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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344909#comment-17344909 ] David Capwell commented on CASSANDRA-16581: --- added patch for python dtest to ignore those errors > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16658:
Since Version: (was: 4.0-rc1)
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-16658:
Fix Version/s: (was: 4.0-rc)
4.0.x
4.0
4.0-rc2
Since Version: 4.0-rc1
Source Control Link:
https://github.com/apache/cassandra/commit/9783d47b9fe3e370f4ccddbb8eae5a065a9cf3a5
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.0.x
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344903#comment-17344903
]
Ekaterina Dimitrova commented on CASSANDRA-16658:
-
Committed:
[4.0|https://github.com/apache/cassandra/commit/9783d47b9fe3e370f4ccddbb8eae5a065a9cf3a5]
and merged to trunk
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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
[cassandra] 01/01: Merge branch 'cassandra-4.0' into trunk
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 9d57d216f5530e5b80adb753e5daa0d469ae0944 Merge: f91418b 9783d47 Author: Ekaterina Dimitrova AuthorDate: Fri May 14 18:04:42 2021 -0400 Merge branch 'cassandra-4.0' into trunk CHANGES.txt | 1 + bin/cqlsh.py | 26 +++--- 2 files changed, 12 insertions(+), 15 deletions(-) diff --cc CHANGES.txt index e89e056,68f418d..9ec0f98 --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,6 -1,5 +1,7 @@@ -4.0-rc2 +4.1 + * GossiperTest.testHasVersion3Nodes didn't take into account trunk version changes, fixed to rely on latest version (CASSANDRA-16651) +Merged from 4.0: + * Fix in-browser "help", Python 3 (CASSANDRA-16658) * Fix DROP COMPACT STORAGE for counters (CASSANDRA-16653) * Add back validation for AlterTableStatements (CASSANDRA-16643) * Fix cqlsh encoding error with unicode in multi-line statement (CASSANDRA-16539) - 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 (98b449f -> 9783d47)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git. from 98b449f Merge branch 'cassandra-3.11' into cassandra-4.0 add 9783d47 Fix in-browser "help", Python 3 authored Adam Holmberg, reviewed by Ekaterina Dimitrova and Andres de la Pena for CASSANDRA-16658 No new revisions were added by this update. Summary of changes: CHANGES.txt | 1 + bin/cqlsh.py | 26 +++--- 2 files changed, 12 insertions(+), 15 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (f91418b -> 9d57d21)
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git. from f91418b Move CASSANDRA-14559s bootstrap_test.py::TestBootstrap::test_node_cannot_join_as_hibernating_node_without_replace_address into a jvm-dtest add 9783d47 Fix in-browser "help", Python 3 authored Adam Holmberg, reviewed by Ekaterina Dimitrova and Andres de la Pena for CASSANDRA-16658 new 9d57d21 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 + bin/cqlsh.py | 26 +++--- 2 files changed, 12 insertions(+), 15 deletions(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344902#comment-17344902
]
David Capwell commented on CASSANDRA-16581:
---
tests are passing, but seems our SSL tests are failing as the "unknown" log
added is showing the following
{code}
Caused by: javax.net.ssl.SSLHandshakeException: error:10f7:SSL
routines:OPENSSL_internal:WRONG_VERSION_NUMBER
at
io.netty.handler.ssl.ReferenceCountedOpenSslEngine.sslReadErrorResult(ReferenceCountedOpenSslEngine.java:1309)
at
io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1270)
at
io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1346)
at
io.netty.handler.ssl.ReferenceCountedOpenSslEngine.unwrap(ReferenceCountedOpenSslEngine.java:1389)
at
io.netty.handler.ssl.SslHandler$SslEngineType$1.unwrap(SslHandler.java:206)
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1387)
at
io.netty.handler.ssl.SslHandler.decodeNonJdkCompatible(SslHandler.java:1294)
at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:1331)
at
io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:508)
at
io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:447)
... 15 common frames omitted]
{code}
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344865#comment-17344865 ] David Capwell commented on CASSANDRA-16581: --- Looking into this and talking to [~aholmber] it turns out Server can not reply back with a preferred version(s), instead client keeps trying but "downgrades" the version to the next in a list... for this reason there isn't something I can really do to avoid this other than avoid logging when the version is DSE. Given that adding a "handshake" is out of scope (and too late at this point of a release) the only solution I can think of is to avoid logging in these cases. > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16658:
--
Status: Ready to Commit (was: Review In Progress)
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344812#comment-17344812
]
Andres de la Peña commented on CASSANDRA-16658:
---
Looks good to me too, +1.
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344811#comment-17344811
]
David Capwell commented on CASSANDRA-16581:
---
Found the root cause
https://github.com/datastax/python-driver/blob/15d715f4e686032b02ce785eca1d176d2b25e32b/cassandra/cluster.py#L614
The default version tried is ProtocolVersion.DSE_V2, then falls back to V1
{code}
DSE_V1 = 0x41
"""
DSE private protocol v1, supported in DSE 5.1+
"""
DSE_V2 = 0x42
"""
DSE private protocol v2, supported in DSE 6.0+
"""
SUPPORTED_VERSIONS = (DSE_V2, DSE_V1, V6, V5, V4, V3, V2, V1)
"""
A tuple of all supported protocol versions
"""
{code}
0x42 = 66, 0x41 = 65
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[ https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344806#comment-17344806 ] David Capwell commented on CASSANDRA-16581: --- What I see is the first message is 65 or 66 (changes some times) and that after our error is sent back the client resends with v5 and the connection moves forward just fine. > Failure to execute queries should emit a KPI other than read > timeout/unavailable so it can be alerted/tracked > - > > Key: CASSANDRA-16581 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16581 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client, Observability/Metrics >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-rc > > > When we are unable to parse a message we do not have a way to detect this > from a monitoring point of view so can get into situations where we believe > the database is fine but the clients are on-fire. This case popped up in the > 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe. -- 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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344804#comment-17344804
]
David Capwell commented on CASSANDRA-16581:
---
testing java
{code}
try (Cluster cluster =
Cluster.builder().addContactPoint("127.0.0.1").withoutJMXReporting().build();
Session session = cluster.newSession())
{
for (Row row : session.execute("select * from system.local"))
{
System.out.println(row);
}
}
{code}
I see that the first byte is 5 and works as expected without any logs
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344800#comment-17344800
]
David Capwell commented on CASSANDRA-16581:
---
What I see is org.apache.cassandra.transport.InitialConnectionHandler#decode
gets "firstByte" to be 66, and applying the PROTOCOL_VERSION_MASK doesn't
change the value.
When I run
{code}
./bin/cqlsh --protocol-version 4
{code}
the first byte is 4 and versionNum is also 4 (the same is true with
--protocol-version 3, but first byte is 3)
This looks like cqlsh is missing this?
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344799#comment-17344799
]
Adam Holmberg commented on CASSANDRA-16659:
---
+1 no concerns, better solution. Thanks.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16581) Failure to execute queries should emit a KPI other than read timeout/unavailable so it can be alerted/tracked
[
https://issues.apache.org/jira/browse/CASSANDRA-16581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344794#comment-17344794
]
David Capwell commented on CASSANDRA-16581:
---
the python details are failing now that we no longer fall back to highest
supported protocol version when an unknown protocol version is seen...
{code}
Unexpected error found in node logs (see stdout for full details). Errors:
[WARN [epollEventLoopGroup-5-5] 2021-05-14 16:59:18,418 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (66); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta),
WARN [epollEventLoopGroup-5-6] 2021-05-14 16:59:18,418 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (65); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta),
WARN [epollEventLoopGroup-5-5] 2021-05-14 16:59:18,418 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (66); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta)]
{code}
I can replicate this when the following is done
{code}
$ ./bin/cqlsh
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.1-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>
{code}
{code}
WARN [nioEventLoopGroup-5-10] 2021-05-14 10:56:18,366 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (65); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta)
{code}
but this doesn't happen when I specify a specific version
{code}
$ ./bin/cqlsh --protocol-version 1
Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
DriverException('ProtocolError returned from server while using explicitly set
client protocol_version 1')})
$ ./bin/cqlsh --protocol-version 2
Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
DriverException('ProtocolError returned from server while using explicitly set
client protocol_version 2')})
$ ./bin/cqlsh --protocol-version 3
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.1-SNAPSHOT | CQL spec 3.4.5 | Native protocol v3]
Use HELP for help.
cqlsh>
$ ./bin/cqlsh --protocol-version 4
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.1-SNAPSHOT | CQL spec 3.4.5 | Native protocol v4]
Use HELP for help.
cqlsh>
$ ./bin/cqlsh --protocol-version 5
Connected to Test Cluster at 127.0.0.1:9042
[cqlsh 6.0.0 | Cassandra 4.1-SNAPSHOT | CQL spec 3.4.5 | Native protocol v5]
Use HELP for help.
cqlsh>
$ ./bin/cqlsh --protocol-version 6
Connection error: ('Unable to connect to any servers', {'127.0.0.1:9042':
})
{code}
{code}
WARN [nioEventLoopGroup-5-13] 2021-05-14 10:57:27,019 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (1); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta)
WARN [nioEventLoopGroup-5-14] 2021-05-14 10:57:30,967 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Invalid or unsupported
protocol version (2); supported versions are (3/v3, 4/v4, 5/v5, 6/v6-beta)
WARN [nioEventLoopGroup-5-21] 2021-05-14 10:57:42,520 NoSpamLogger.java:95 -
Protocol exception with client networking:
org.apache.cassandra.transport.ProtocolException: Beta version of the protocol
used (6/v6-beta), but USE_BETA flag is unset
{code}
> Failure to execute queries should emit a KPI other than read
> timeout/unavailable so it can be alerted/tracked
> -
>
> Key: CASSANDRA-16581
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16581
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client, Observability/Metrics
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> When we are unable to parse a message we do not have a way to detect this
> from a monitoring point of view so can get into situations where we believe
> the database is fine but the clients are on-fire. This case popped up in the
> 2.1 to 3.0 upgrade as paging state wasn’t mixed-mode safe.
--
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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344786#comment-17344786
]
Ekaterina Dimitrova commented on CASSANDRA-16659:
-
I am fine with this idea for maintainability as soon as this file is read only
once during initialization. If [~aholmber] confirms he doesn't have any
concerns, I will pull, squash, run final CI and commit. Thank you both!
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-16658:
--
Reviewers: Andres de la Peña, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344773#comment-17344773
]
Andres de la Peña commented on CASSANDRA-16659:
---
[~aholmber] I'm fine with leaving it as it is. I think there isn't an obvious
place to put that file with the reserved keywords once the project is
distributed without sources, so getting rid of the duplicated lists is not as
easy as I initially thought.
However, what can be done quite easily instead is placing the Java's list of
keywords in a resources file, so both {{ReservedKeywords}} and the
{{test_constants.py}} test (but not {{cqlhandling.py}}) read that file,
avoiding the need of parsing Java code. I gave it a go [in this
commit|https://github.com/adelapena/cassandra/commit/ef6870e3f0ff0033ee422b75e4cfb2b5c20ff25b].
Please feel free of just ignoring it if you don't like it, I'm fine with both
approaches.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344705#comment-17344705
]
Ekaterina Dimitrova commented on CASSANDRA-16659:
-
Good catch [~adelapena] and maintainability is a great topic, I am wondering
whether we have to do that as part of this ticket or leave it as a required
improvement in another one?
CI is mandatory and a new comment added can easily be caught and corrected.
Also, I saw that this list was changed 5 times in 5 years. I personally do not
expect many changes and comments added. That is why I thought that this test is
good enough at this point in time.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344653#comment-17344653
]
Adam Holmberg commented on CASSANDRA-16659:
---
I agree it's a bit brittle, but thought it would be okay as a sanity check.
Totally cool making it a text file. Less sure about how that should be
organized in-tree. Would it be a resource to be embedded in the jar and read at
runtime? Happy to have you show or tell me how to do that.
Another thing I considered was just adding a utility "main" to the class that
the test would invoke to dump the keywords. Originally did not opt for that
because I didn't think it was worth the complexity for such a simple check.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail:
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344650#comment-17344650
]
Andres de la Peña commented on CASSANDRA-16659:
---
Now I'm reading the right PR, sorry for the confusion. Having the test to
verify that the two lists of reserved keywords is nice. However I'm a bit
concerned about parsing the Java file since it might be a bit brittle, a single
line comment on {{ReservedKeywords}} might break it, for example:
{code:java}
@VisibleForTesting
static final String[] reservedKeywords = new String[]
{
"SELECT", // this is the
most important keyword
"FROM",
"WHERE",
{code}
or
{code:java}
@VisibleForTesting
static final String[] reservedKeywords = new String[]
{
"SELECT",
// "JOIN",
"FROM",
"WHERE",
{code}
would break it, and it wouldn't be detected until the test is run. This is
unlikely to happen and not very hard to fix if it happens, but we could add a
comment mentioning the existence of {{test_cql_reserved_keywords}} in
{{ReservedKeywords}} to warn maintainers.
Alternatively, I wonder if we could just place the list of reserved keywords in
a unique plain text file, so both {{cqlhandling.py}} and {{ReservedKeywords}}
can read it. That way we wouldn't need to maintain two copies of the same list
and a test to detect inconsistencies between them. Indeed the test parsing code
wouldn't even be necessary, wdyt?
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in
[jira] [Commented] (CASSANDRA-16658) Broken "help" command on cqlsh 6.0.0
[
https://issues.apache.org/jira/browse/CASSANDRA-16658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344585#comment-17344585
]
Ekaterina Dimitrova commented on CASSANDRA-16658:
-
[~adelapena], [~Bereng], will anyone of you have time to check this one, please?
> Broken "help" command on cqlsh 6.0.0
>
>
> Key: CASSANDRA-16658
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16658
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Adam Holmberg
>Priority: Normal
> Fix For: 4.0-rc
>
>
> On cqlsh 5.0.1, "help select" command prints this:
> {noformat}
> cqlsh> help select
> *** No browser to display CQL help. URL for help topic select :
> https://cassandra.apache.org/doc/cql3/CQL-3.2.html#selectStmt
> {noformat}
> However, on cqlsh 6.0.0, "help select" command prints this:
> {noformat}
> cqlsh> help select
> object of type 'NoneType' has no len()
> {noformat}
> Steps to reproduce:
> # Create and start a Cassandra 4 docker container
> {noformat}
> ~ $ docker create --name cassandra4 cassandra:4.0
> ~ $ docker start cassandra4{noformat}
> # Get a shell inside the docker container
> {noformat}
> docker exec -ti CONTAINER_NAME bash{noformat}
> # Start a cqlsh and run the "help" command inside it (you have to wait for
> the Cassandra server starting, I had to run "nodetool enablebinary" too, not
> sure why)
> {noformat}
> root@b03a20987964:/# cqlsh
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> help select
> object of type 'NoneType' has no len()
> cqlsh>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344570#comment-17344570
]
Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/14/21, 1:03 PM:
---
Hey [~adelapena] , I think you probably looked at my PR and missed Adam's
latest comments.
Test and fix of the mentioned by you issue are already in place
[here|https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
was (Author: e.dimitrova):
Hey [~adelapena] , I think you probably looked at my PR and missed Adam's
latest comments.
Test and fix of the mentioned by you issue is already in place
[here|https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344575#comment-17344575
]
Andres de la Peña commented on CASSANDRA-16659:
---
My fault, I missed the last comments, I'll review the new PR in a bit.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344570#comment-17344570
]
Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/14/21, 12:49 PM:
Hey [~adelapena] , I think you probably looked at my PR and missed Adam's
latest comments.
Test and fix of the mentioned by you issue is already in place [here|
[https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
was (Author: e.dimitrova):
Hey Andres, I think you probably looked at my PR and missed Adam's latest
comment.
Test and fix of the mentioned by you issue is already in place [here|
[https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
[jira] [Comment Edited] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344570#comment-17344570
]
Ekaterina Dimitrova edited comment on CASSANDRA-16659 at 5/14/21, 12:49 PM:
Hey [~adelapena] , I think you probably looked at my PR and missed Adam's
latest comments.
Test and fix of the mentioned by you issue is already in place
[here|https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
was (Author: e.dimitrova):
Hey [~adelapena] , I think you probably looked at my PR and missed Adam's
latest comments.
Test and fix of the mentioned by you issue is already in place [here|
[https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc
[jira] [Commented] (CASSANDRA-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344570#comment-17344570
]
Ekaterina Dimitrova commented on CASSANDRA-16659:
-
Hey Andres, I think you probably looked at my PR and missed Adam's latest
comment.
Test and fix of the mentioned by you issue is already in place [here|
[https://github.com/aholmberg/cassandra/pull/61/commits]
[ci|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=16659-4.0]
I had to change the PR link with his one, I am sorry for the confusion.
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344567#comment-17344567
]
Ekaterina Dimitrova commented on CASSANDRA-16644:
-
When I mentioned the long tests, I didn't mean that this is the case here but I
wanted to give an example of another class where there was different solution
to timeout problems and we should verify those we see now why they appear and
start from there.
Thank you, everything looks good to me!
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344546#comment-17344546
]
Andres de la Peña commented on CASSANDRA-16659:
---
I see that the list of reserved keywords in {{cqlhandling.py}} contains some
keywords that are present in {{Parser.g}}'s {{basic_unreserved_keyword}} and
absent from {{ReservedKeywords}}:
* default
* mbean
* mbeans
* replace
* unset
I understand that those are not reserved keywords in 4.0 so they shouldn't be
in the {{cqlhandling.py}} list, is this right?
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {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-16659) cqlsh 6.0.0 treats "config" as a reserved keyword
[
https://issues.apache.org/jira/browse/CASSANDRA-16659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344539#comment-17344539
]
Andres de la Peña commented on CASSANDRA-16659:
---
The patch looks good to me, it's probably better to not get the list of
keywords from the driver.
{quote}A separate thought: what would you think of a unit test that makes sure
this list is in sync with the antlr files in-tree? I'm experimenting with that
locally. I can share if you think it's worth doing.
{quote}
It would be nice to have that test to detect future inconsistencies between the
lists of reserved keywords, probably something similar to Java's
[{{ReservedKeywordsTest}}|https://github.com/apache/cassandra/blob/cassandra-4.0/test/unit/org/apache/cassandra/cql3/ReservedKeywordsTest.java].
[~aholmber] did you make a prototype of this?
> cqlsh 6.0.0 treats "config" as a reserved keyword
> -
>
> Key: CASSANDRA-16659
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16659
> Project: Cassandra
> Issue Type: Bug
> Components: CQL/Interpreter
>Reporter: Bowen Song
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Based on the information
> [here|https://github.com/apache/cassandra/blob/cassandra-4.0-rc1/doc/source/cql/appendices.rst]
> from the Cassandra 4.0 RC1, "config" is not a keyword, and certainly is not
> a reserved keyword.
> However, Cassandra 4.0 RC1 / cqlsh 6.0.0 cannot fully agree:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config> desc "config";
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
> For reference:
> * Non-reserved keywords, such as "all", don't have the above problem. They
> can be used as keyspace name in any statement without quoting.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use all;
> cqlsh:all> desc all;
> CREATE KEYSPACE all WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:all>
> {noformat}
> * Reserved keywords, such as "add", can be used as keyspace name but
> requires quoting wherever it's used.
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 4.0-rc1 | CQL spec 3.4.5 | Native protocol v5]
> Use HELP for help.
> cqlsh> create keyspace add WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> SyntaxException: line 1:16 no viable alternative at input 'add' (create
> keyspace [add]...)
> cqlsh> create keyspace "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use add;
> Improper use command.
> cqlsh> use "add";
> cqlsh:add> desc add;
> Improper desc command.
> cqlsh:add> desc "add";
> CREATE KEYSPACE "add" WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {noformat}
> The treating of "config" in cqlsh 6.0.0 is somewhere in between, it can be
> used in the "create keyspace" statement without quoting, but requires quoting
> in the "use" and "desc" statements.
>
> I believe this is a bug in cqlsh 6.0.0, because it behaves the same way when
> it's connected to a Cassandra 3.11 cluster:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042
> [cqlsh 6.0.0 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> Improper use command.
> cqlsh> desc config;
> Improper desc command.
> cqlsh> use "config";
> cqlsh:config>
> {noformat}
> Yet cqlsh 5.0.1 doesn't have any issue at all:
> {noformat}
> Connected to Test Cluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.10 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cqlsh> create keyspace config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'};
> cqlsh> use config;
> cqlsh:config> desc config;
> CREATE KEYSPACE config WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> cqlsh:config>
> {noformat}
--
This message was
[jira] [Commented] (CASSANDRA-16654) Junit RepeatableRunner flaky tests helper
[
https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344515#comment-17344515
]
Andres de la Peña commented on CASSANDRA-16654:
---
{quote}There's no easy way to make ant take a runner as a parameter. You have
to create a plugin etc etc. Alternatives are also quite involved. If I have not
lost track of the things I think what we have is the most reasonable option.
{quote}
Agree, I played a bit with {{JUnitTask}}/{{JStackJUnitTask}} while working on
the CircleCI multiplexer and it seems probably more involved than we need right
now. I think it's better if we commit this as it is, so it starts to help us
with 4.0 immediately. We can always come back later to add the repetitions as
an Ant parameter.
{quote}Edit: Added doc notes.
{quote}
The new section about flaky tests is nice, thanks. I've left a couple of very
minor suggestions in the PR that can be addressed during commit.
I think we are ready to commit. IMO it would be nice if we added the runner
also to 3.0 and 3.11, it should be a straightforward merge.
Also, just a reminder to remove the usages of {{RepeatableRunner}} that we have
added as examples ({{DirectoriesTest}}, {{ColumnFilterTest}},
{{AssureSufficientLiveNodesTest}} and {{SpeculativeRetryParseTest}})
> Junit RepeatableRunner flaky tests helper
> -
>
> Key: CASSANDRA-16654
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16654
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc2, 4.0, 4.1
>
>
> Some flakies only fail when the full suite is ran. If it's a quick test you
> can do thousands of runs if a few seconds. Looping at the sh level is not an
> option as every loop takes a few seconds.
> As I have found this very useful I am proposing committing it
--
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-16619) Loss of commit log data possible after sstable ingest
[
https://issues.apache.org/jira/browse/CASSANDRA-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344513#comment-17344513
]
Jacek Lewandowski commented on CASSANDRA-16619:
---
[~e.dimitrova] I've missed regenerating {{nb}} in legacy sstables after the
change - fixed that and rerun the tests:
https://jenkins-cm4.apache.org/view/patches/job/Cassandra-devbranch-test/524/
> Loss of commit log data possible after sstable ingest
> -
>
> Key: CASSANDRA-16619
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16619
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Commit Log
>Reporter: Jacek Lewandowski
>Assignee: Jacek Lewandowski
>Priority: Normal
> Fix For: 3.0.25, 3.11.11, 4.0-rc2, 4.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> SSTable metadata contains commit log positions of the sstable. These
> positions are used to filter out mutations from the commit log on restart and
> only make sense for the node on which the data was flushed.
> If an SSTable is moved between nodes they may cover regions that the
> receiving node has not yet flushed, and result in valid data being lost
> should these sections of the commit log need to be replayed.
> Solution:
> The chosen solution introduces a new sstable metadata (StatsMetadata) -
> originatingHostId (UUID), which is the local host id of the node on which the
> sstable was created, or null if not known. Commit log intervals from an
> sstable are taken into account during Commit Log replay only when the
> originatingHostId of the sstable matches the local node's hostId.
> For new sstables the originatingHostId is set according to StorageService's
> local hostId.
> For compacted sstables the originatingHostId set according to
> StorageService's local hostId, and only commit log intervals from local
> sstables is preserved in the resulting sstable.
> discovered by [~jakubzytka]
--
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-16654) Junit RepeatableRunner flaky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344461#comment-17344461 ] Berenguer Blasi edited comment on CASSANDRA-16654 at 5/14/21, 8:46 AM: --- There's no easy way to make ant take a runner as a parameter. You have to create a plugin etc etc. Alternatives are also quite involved. If I have not lost track of the things I think what we have is the most reasonable option. Edit: Added doc notes. was (Author: bereng): There's no easy way to make ant take a runner as a parameter. You have to create a plugin etc etc. Alternatives are also quite involved. If I have not lost track of the things I think what we have is the most reasonable option. > Junit RepeatableRunner flaky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- 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-16654) Junit RepeatableRunner flaky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-16654: Authors: Andres de la Peña, Berenguer Blasi (was: Berenguer Blasi) > Junit RepeatableRunner flaky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- 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-16654) Junit RepeatableRunner flaky tests helper
[ https://issues.apache.org/jira/browse/CASSANDRA-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344461#comment-17344461 ] Berenguer Blasi commented on CASSANDRA-16654: - There's no easy way to make ant take a runner as a parameter. You have to create a plugin etc etc. Alternatives are also quite involved. If I have not lost track of the things I think what we have is the most reasonable option. > Junit RepeatableRunner flaky tests helper > - > > Key: CASSANDRA-16654 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16654 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Berenguer Blasi >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.0-rc2, 4.0, 4.1 > > > Some flakies only fail when the full suite is ran. If it's a quick test you > can do thousands of runs if a few seconds. Looping at the sh level is not an > option as every loop takes a few seconds. > As I have found this very useful I am proposing committing it -- 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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344383#comment-17344383
]
Berenguer Blasi edited comment on CASSANDRA-16644 at 5/14/21, 8:30 AM:
---
I did a last multiplex CI run and it
[lgtm|https://app.circleci.com/pipelines/github/bereng/cassandra/287/workflows/7d1e15b7-9d2d-4347-80ee-ab8cb1166155/jobs/2723]
Timeouts imo are not related to having expanded the test so now it better fits
into some other 'long' category as it was your case. I just think we're close
to the timeouts but time will tell. We don't have to decide that now. If you're
+1 I'll revert the requirements.txt change and then we can commit.
EDIT: Let me run the whole dtests suite on MID with the ccm patch just to be
extra sure...
[j11|https://app.circleci.com/pipelines/github/bereng/cassandra/289/workflows/6e7f5171-2403-4318-be44-cc177655240c]
and
[j8|https://app.circleci.com/pipelines/github/bereng/cassandra/289/workflows/9c82de81-ffac-4db3-b044-75c7294aa7f7]
lgtm
was (Author: bereng):
I did a last multiplex CI run and it
[lgtm|https://app.circleci.com/pipelines/github/bereng/cassandra/287/workflows/7d1e15b7-9d2d-4347-80ee-ab8cb1166155/jobs/2723]
Timeouts imo are not related to having expanded the test so now it better fits
into some other 'long' category as it was your case. I just think we're close
to the timeouts but time will tell. We don't have to decide that now. If you're
+1 I'll revert the requirements.txt change and then we can commit.
EDIT: Let me run the whole dtests suite on MID with the ccm patch just to be
extra sure...
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
>
[jira] [Comment Edited] (CASSANDRA-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344383#comment-17344383
]
Berenguer Blasi edited comment on CASSANDRA-16644 at 5/14/21, 7:45 AM:
---
I did a last multiplex CI run and it
[lgtm|https://app.circleci.com/pipelines/github/bereng/cassandra/287/workflows/7d1e15b7-9d2d-4347-80ee-ab8cb1166155/jobs/2723]
Timeouts imo are not related to having expanded the test so now it better fits
into some other 'long' category as it was your case. I just think we're close
to the timeouts but time will tell. We don't have to decide that now. If you're
+1 I'll revert the requirements.txt change and then we can commit.
EDIT: Let me run the whole dtests suite on MID with the ccm patch just to be
extra sure...
was (Author: bereng):
I did a last CI run and it
[lgtm|https://app.circleci.com/pipelines/github/bereng/cassandra/287/workflows/7d1e15b7-9d2d-4347-80ee-ab8cb1166155/jobs/2723]
Timeouts imo are not related to having expanded the test so now it better fits
into some other 'long' category as it was your case. I just think we're close
to the timeouts but time will tell. We don't have to decide that now. If you're
+1 I'll revert the requirements.txt change and then we can commit.
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {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-16644) Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
[
https://issues.apache.org/jira/browse/CASSANDRA-16644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17344383#comment-17344383
]
Berenguer Blasi commented on CASSANDRA-16644:
-
I did a last CI run and it
[lgtm|https://app.circleci.com/pipelines/github/bereng/cassandra/287/workflows/7d1e15b7-9d2d-4347-80ee-ab8cb1166155/jobs/2723]
Timeouts imo are not related to having expanded the test so now it better fits
into some other 'long' category as it was your case. I just think we're close
to the timeouts but time will tell. We don't have to decide that now. If you're
+1 I'll revert the requirements.txt change and then we can commit.
> Flaky TestTransientReplicationRing.test_move_backwards_and_cleanup
> --
>
> Key: CASSANDRA-16644
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16644
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Failure
> [here|https://ci-cassandra.apache.org/job/Cassandra-trunk/472/testReport/junit/dtest-novnode.transient_replication_ring_test/TestTransientReplicationRing/test_move_backwards_and_cleanup/]
> {noformat}
> Error Message
> ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after 90.11/90 seconds
> Missing: ['Starting listening for CQL clients'] not found in system.log:
> Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> Stacktrace
> self = at 0x7f66c51ebd90>
> @flaky(max_runs=1)
> @pytest.mark.no_vnodes
> def test_move_backwards_and_cleanup(self):
> """Test moving a node backwards without moving past a neighbor
> token"""
> move_token = '5'
> expected_after_move = [gen_expected(range(0, 6), range(31, 40)),
>gen_expected(range(0, 21, 2)),
>gen_expected(range(1, 6, 2), range(6, 31)),
>gen_expected(range(7, 20, 2), range(21, 40))]
> expected_after_repair = [gen_expected(range(0, 6), range(31, 40)),
> gen_expected(range(0, 21)),
> gen_expected(range(6, 31)),
> gen_expected(range(21, 40))]
> > self.move_test(move_token, expected_after_move, expected_after_repair)
> transient_replication_ring_test.py:333:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> transient_replication_ring_test.py:235: in move_test
> node4.start(wait_for_binary_proto=True)
> transient_replication_ring_test.py:50: in new_start
> return old_start(*args, **kwargs)
> ../venv/src/ccm/ccmlib/node.py:901: in start
> self.wait_for_binary_interface(from_mark=self.mark)
> ../venv/src/ccm/ccmlib/node.py:687: in wait_for_binary_interface
> self.watch_log_for("Starting listening for CQL clients", **kwargs)
> ../venv/src/ccm/ccmlib/node.py:588: in watch_log_for
> TimeoutError.raise_if_passed(start=start, timeout=timeout, node=self.name,
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> start = 1619481570.0236456, timeout = 90
> msg = "Missing: ['Starting listening for CQL clients'] not found in
> system.log:\nTail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura"
> node = 'node4'
> @staticmethod
> def raise_if_passed(start, timeout, msg, node=None):
> if start + timeout < time.time():
> > raise TimeoutError.create(start, timeout, msg, node)
> E ccmlib.node.TimeoutError: 27 Apr 2021 00:01:00 [node4] after
> 90.11/90 seconds Missing: ['Starting listening for CQL clients'] not found in
> system.log:
> E Tail: INFO [main] 2021-04-26 23:59:22,590 YamlConfigura
> ../venv/src/ccm/ccmlib/node.py:56: TimeoutError
> {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
