[jira] [Comment Edited] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363396#comment-17363396
]
Vinay Chella edited comment on CASSANDRA-16669 at 6/15/21, 7:06 AM:
[~e.dimitrova] Latest changes LGTM, except for a couple of minor nitpicks at
latest [PR|https://github.com/ekaterinadimitrova2/cassandra/pull/140].
I confirm that the local testing of valid/invalid DCL statements obfuscated
passwords
*before*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049034578|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049057271|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
{code}
*after*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736337400|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD ***; bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736351148|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob1 WITH PASSWORD ***; bob1 already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736356902|type:CREATE_ROLE|category:DCL|operation:CREATE
ROLE bob12 WITH PASSWORD ***
{code}
*CircleCI Tests:*
I could not run tests due to circleci account restrictions on my side, so I am
leaning your test results.
was (Author: vinaykumarcse):
[~e.dimitrova] Latest changes LGTM, except for a couple of minor nitpicks.
I confirm that the local testing of valid/invalid DCL statements obfuscated
passwords
*before*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049034578|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049057271|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
{code}
*after*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736337400|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD ***; bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736351148|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob1 WITH PASSWORD ***; bob1 already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736356902|type:CREATE_ROLE|category:DCL|operation:CREATE
ROLE bob12 WITH PASSWORD ***
{code}
*CircleCI Tests:*
I could not run tests due to circleci account restrictions on my side, so I am
leaning your test results.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363396#comment-17363396
]
Vinay Chella commented on CASSANDRA-16669:
--
[~e.dimitrova] Latest changes LGTM, except for a couple of minor nitpicks.
I confirm that the local testing of valid/invalid DCL statements obfuscated
passwords
*before*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049034578|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:62542|timestamp:1621049057271|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD='password_b' AND LOGIN = true AND SUPERUSER = true;;
bob already exists
{code}
*after*
{code:java}
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736337400|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob WITH PASSWORD ***; bob already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736351148|type:REQUEST_FAILURE|category:ERROR|operation:CREATE
ROLE bob1 WITH PASSWORD ***; bob1 already exists
Type: audit
LogMessage:
user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:59634|timestamp:1623736356902|type:CREATE_ROLE|category:DCL|operation:CREATE
ROLE bob12 WITH PASSWORD ***
{code}
*CircleCI Tests:*
I could not run tests due to circleci account restrictions on my side, so I am
leaning your test results.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17361221#comment-17361221
]
Vinay Chella commented on CASSANDRA-16669:
--
I am on +1 on
{quote}I would suggest going back to the simplified version for 4.0.0.
{quote}
It is better than excluding DCL, and an operator mistake/oops could lead to
exposing passwords, so I feel this is better.
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17357424#comment-17357424
]
Vinay Chella commented on CASSANDRA-16669:
--
Thank you for the update [~sumanth.pasupuleti]. I left a few nitpicks (doc
updates and few more specific tests covering regex) on your PR.
{quote}1. Given that QueryEvents is a centralized common emitter of events to
all registered listeners, choosing to obfuscate password in QueryEvents would
force the obfuscation behavior to all the registered listeners vs leaving that
decision to individual listeners. This is the reason why I chose to keep this
obfuscation change localized to AuditLogging.
2. My stance on password visibility in FQL is that given FQL is meant to
replay traffic to achieve identical results, I would vote for password staying
visible in FQL.
{quote}
SGTM, thanks to [~stefan.miklosovic] for asking about FQL password obfuscation
on dev list, I would love to hear other's opinions on this,
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-16669:
-
Workflow: Cassandra Bug Workflow (was: Cassandra Default Workflow)
Issue Type: Bug (was: Improvement)
> Password obfuscation for DCL audit log statements
> -
>
> Key: CASSANDRA-16669
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16669
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/auditlogging
>Reporter: Vinay Chella
>Assignee: Sumanth Pasupuleti
>Priority: Normal
> Labels: audit, security
> Fix For: 4.0-rc, 4.0.x, 4.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354786#comment-17354786
]
Vinay Chella commented on CASSANDRA-16669:
--
Thanks for the patch [~sumanth.pasupuleti], good test coverage for the patch.
Few comments from my first glance.
* I +1 [~stefan.miklosovic] comment on the option to enable password
obfuscation. Why should obfuscate_password be an option? the database should
not allow logging passwords in plain text files.
* Why did you choose to obfuscate passwords in AuditLogging vs QueryEvents?
What is your stance on password being visible in FQL or other subscribers of
QueryEvents?
* Please update the documentation with the details of password obfuscation.
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The goal of this JIRA is to obfuscate passwords or any sensitive information
> from DCL audit log statements.
> Currently, (Cassandra version 4.0-rc1) logs query statements for any DCL
> ([ROLE|https://cassandra.apache.org/doc/latest/cql/security.html#database-roles]
> and [USER|https://cassandra.apache.org/doc/latest/cql/security.html#users] )
> queries with passwords in plaintext format in audit log files.
> The current workaround to avoid plain text passwords from being logged in
> audit log files is either by
> [excluding|https://cassandra.apache.org/doc/latest/operating/audit_logging.html#options]
> DCL statements from auditing or by excluding the user who is creating these
> roles from auditing.
> It would be ideal for Cassandra to provide an option or default to obfuscate
> passwords or any sensitive information from DCL audit log statements.
> Sample audit logs with DCL queries
> {code:sh}
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190499676|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE new_role;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190505313|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE alice WITH PASSWORD = 'password_a' AND LOGIN = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190519521|type:REQUEST_FAILURE|category:ERROR|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;; bob doesn't
> exist
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190525376|type:CREATE_ROLE|category:DCL|operation:CREATE
> ROLE bob WITH PASSWORD = 'password_b' AND LOGIN = true AND SUPERUSER = true;
> Type: audit
> LogMessage:
> user:cassandra|host:localhost/127.0.0.1:7000|source:/127.0.0.1|port:51908|timestamp:1620190532462|type:ALTER_ROLE|category:DCL|operation:ALTER
> ROLE bob WITH PASSWORD = 'PASSWORD_B' AND SUPERUSER = false;
> {code}
> It is also ideal to document this workaround or assumption in Cassandra audit
> log documentation until we close this JIRA
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16669) Password obfuscation for DCL audit log statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-16669:
-
Reviewers: Stefan Miklosovic, Vinay Chella (was: Stefan Miklosovic)
> 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-15580) 4.0 quality testing: Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-15580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17243538#comment-17243538
]
Vinay Chella commented on CASSANDRA-15580:
--
[Alexander
Dejanovski|https://issues.apache.org/jira/secure/ViewProfile.jspa?name=adejanovski],
the detailed repair test plan that you outlined looks like a great start to
me. I want to share a few techniques and methodologies that we use internally
to validate the repair functionality though many are not in an open source-able
state.
One of the things that are not covered in dtest repair test coverage is the
repair validation with dense nodes, which is often the pain point. We have
built an infrastructure and automation that helps us build large scale clusters
with dense nodes, running NdBench traffic while repairing the cluster with
continuous node restarts and terminations. This tooling and infra certainly
helped us discover a few critical repair issues and tweaks in the past (e.g.,
CASSANDRA-14096). This infra also helps generate the data in one region and
reading, validating in another region while node terminations and hints
dropping are in place. Looking at the approach you are taking, I am glad that
we are marching in a similar direction for 4.0 repair validation, which is a
positive signal.
Regarding mixed version upgrade tests, the similar approach that I outlined
above certainly works to an extent. However, in-jvm upgrade dtests might be
more feasible at this time.
{quote}Which testing framework to use?
I personally like using Gherkin syntax based frameworks such as Cucumber, but
we'd need to get a feel for the community's appetite to introduce such a
framework.
Otherwise we'd probably fallback to JUnit but my take on this is that while
it's really good for unit tests, it's no fit for integration tests.
Any input/opinion on testing framework is appreciated.{color:#172b4d} {color}
{quote}
I see a place where it makes integration tests more readable and easy to
contribute to with something like Gherkin syntax based frameworks, so I don't
see any downside and am optimistic on this unless someone has substantial
concerns.
I am happy to help with the review of these efforts. Please loop me in these
tickets as you make progress.
Thank you for taking this up.
> 4.0 quality testing: Repair
> ---
>
> Key: CASSANDRA-15580
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15580
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Alexander Dejanovski
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: Alexander Dejanovski*
> We aim for 4.0 to have the first fully functioning incremental repair
> solution (CASSANDRA-9143)! Furthermore we aim to verify that all types of
> repair: (full range, sub range, incremental) function as expected as well as
> ensuring community tools such as Reaper work. CASSANDRA-3200 adds an
> experimental option to reduce the amount of data streamed during repair, we
> should write more tests and see how it works with big nodes.
--
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-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15181: - Fix Version/s: (was: 4.0-triage) > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-beta > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- 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-14746) Ensure Netty Internode Messaging Refactor is Solid
[
https://issues.apache.org/jira/browse/CASSANDRA-14746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204328#comment-17204328
]
Vinay Chella edited comment on CASSANDRA-14746 at 9/29/20, 10:40 PM:
-
Thank you for following up on this [~pauloricardomg]
{quote}a) Is work on this issue still active?
{quote}
Yes, it was active until I took a long break from work for personal reasons, if
you see CASSANDRA-15181 and CASSANDRA-14764, I started some of this work but
had to put it on hold, I am starting to get back in motion, should be able to
make progress in coming weeks.
{quote}b) Can we complete this issue once all subtasks are completed or are
there more subtasks to be added?
{quote}
quoting from the description "The goal is that 4.0 should have better latency,
more throughput, fewer threads, fewer context switches, less GC allocation, and
faster recovery time" - I would say it is all about building the confidence in
4.0, we can add more tasks as we make progress and findings based on
CASSANDRA-14747, CASSANDRA-15181, and CASSANDRA-14764.
was (Author: vinaykumarcse):
Thank you for following up on this [~pauloricardomg]
{quote}a) Is work on this issue still active?
{quote}
Yes, it was active until I took a long break from work for personal reasons,
if you see CASSANDRA-15181 and CASSANDRA-14764, I started some of this work but
had to put it on hold, I am starting to get back in motion, should be able to
make progress in coming weeks.
{quote}
b) Can we complete this issue once all subtasks are completed or are there more
subtasks to be added?
{quote}
quoting from the description "The goal is that 4.0 should have better latency,
more throughput, fewer threads, fewer context switches, less GC allocation, and
faster recovery time" - I would say it is all about building the confidence in
4.0, I can sign up to add more tasks as we make progress and findings based on
CASSANDRA-14747, CASSANDRA-15181, and CASSANDRA-14764.
> Ensure Netty Internode Messaging Refactor is Solid
> --
>
> Key: CASSANDRA-14746
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14746
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Labels: 4.0-QA
> Fix For: 4.0-beta
>
>
> Before we release 4.0 let's ensure that the internode messaging refactor is
> 100% solid. As internode messaging is naturally used in many code paths and
> widely configurable we have a large number of cluster configurations and test
> configurations that must be vetted.
> We plan to vary the following:
> * Version of Cassandra 3.0.17 vs 4.0-alpha
> * Cluster sizes with *multi-dc* deployments ranging from 6 - 100 nodes
> * Client request rates varying between 1k QPS and 100k QPS of varying sizes
> and shapes (BATCH, INSERT, SELECT point, SELECT range, etc ...)
> * Internode compression
> * Internode SSL (as well as openssl vs jdk)
> * Internode Coalescing options
> We are looking to measure the following as appropriate:
> * Latency distributions of reads and writes (lower is better)
> * Scaling limit, aka maximum throughput before violating p99 latency
> deadline of 10ms @ LOCAL_QUORUM, on a fixed hardware deployment for 100%
> writes, 100% reads and 50-50 writes+reads (higher is better)
> * Thread counts (lower is better)
> * Context switches (lower is better)
> * On-CPU time of tasks (higher periods without context switch is better)
> * GC allocation rates / throughput for a fixed size heap (lower allocation
> better)
> * Streaming recovery time for a single node failure, i.e. can Cassandra
> saturate the NIC
>
> The goal is that 4.0 should have better latency, more throughput, fewer
> threads, fewer context switches, less GC allocation, and faster recovery
> time. I'm putting Jason Brown as the reviewer since he implemented most of
> the internode refactor.
> Current collaborators driving this QA task: Dinesh Joshi, Jordan West, Joey
> Lynch (Netflix), Vinay Chella (Netflix)
> Owning committer(s): Jason Brown
--
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-14746) Ensure Netty Internode Messaging Refactor is Solid
[
https://issues.apache.org/jira/browse/CASSANDRA-14746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17204328#comment-17204328
]
Vinay Chella commented on CASSANDRA-14746:
--
Thank you for following up on this [~pauloricardomg]
{quote}a) Is work on this issue still active?
{quote}
Yes, it was active until I took a long break from work for personal reasons,
if you see CASSANDRA-15181 and CASSANDRA-14764, I started some of this work but
had to put it on hold, I am starting to get back in motion, should be able to
make progress in coming weeks.
{quote}
b) Can we complete this issue once all subtasks are completed or are there more
subtasks to be added?
{quote}
quoting from the description "The goal is that 4.0 should have better latency,
more throughput, fewer threads, fewer context switches, less GC allocation, and
faster recovery time" - I would say it is all about building the confidence in
4.0, I can sign up to add more tasks as we make progress and findings based on
CASSANDRA-14747, CASSANDRA-15181, and CASSANDRA-14764.
> Ensure Netty Internode Messaging Refactor is Solid
> --
>
> Key: CASSANDRA-14746
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14746
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Streaming and Messaging
>Reporter: Joey Lynch
>Assignee: Joey Lynch
>Priority: Normal
> Labels: 4.0-QA
> Fix For: 4.0-beta
>
>
> Before we release 4.0 let's ensure that the internode messaging refactor is
> 100% solid. As internode messaging is naturally used in many code paths and
> widely configurable we have a large number of cluster configurations and test
> configurations that must be vetted.
> We plan to vary the following:
> * Version of Cassandra 3.0.17 vs 4.0-alpha
> * Cluster sizes with *multi-dc* deployments ranging from 6 - 100 nodes
> * Client request rates varying between 1k QPS and 100k QPS of varying sizes
> and shapes (BATCH, INSERT, SELECT point, SELECT range, etc ...)
> * Internode compression
> * Internode SSL (as well as openssl vs jdk)
> * Internode Coalescing options
> We are looking to measure the following as appropriate:
> * Latency distributions of reads and writes (lower is better)
> * Scaling limit, aka maximum throughput before violating p99 latency
> deadline of 10ms @ LOCAL_QUORUM, on a fixed hardware deployment for 100%
> writes, 100% reads and 50-50 writes+reads (higher is better)
> * Thread counts (lower is better)
> * Context switches (lower is better)
> * On-CPU time of tasks (higher periods without context switch is better)
> * GC allocation rates / throughput for a fixed size heap (lower allocation
> better)
> * Streaming recovery time for a single node failure, i.e. can Cassandra
> saturate the NIC
>
> The goal is that 4.0 should have better latency, more throughput, fewer
> threads, fewer context switches, less GC allocation, and faster recovery
> time. I'm putting Jason Brown as the reviewer since he implemented most of
> the internode refactor.
> Current collaborators driving this QA task: Dinesh Joshi, Jordan West, Joey
> Lynch (Netflix), Vinay Chella (Netflix)
> Owning committer(s): Jason Brown
--
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-16126) Blog post on Cassandra Usage Report 2020
[
https://issues.apache.org/jira/browse/CASSANDRA-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17197263#comment-17197263
]
Vinay Chella commented on CASSANDRA-16126:
--
I left a few comments on PR to improve the readability of it and also a few
observations in the usage of the term {{Cassandra}} and {{Apache Cassandra}}.
> Blog post on Cassandra Usage Report 2020
>
>
> Key: CASSANDRA-16126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16126
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Blog
>Reporter: Melissa Logan
>Assignee: Melissa Logan
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Blog post on the 2020 Cassandra Usage Report.
> ML:
> [https://lists.apache.org/thread.html/r8a91b1d63079739c8dfbdab1833c66d58326de91a659afa3fb2a41a7%40%3Cdev.cassandra.apache.org%3E]
>
> PR: [https://github.com/apache/cassandra-website/pull/21]
--
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] (CASSANDRASC-27) CDC reader in Apache Cassandra Sidecar
[ https://issues.apache.org/jira/browse/CASSANDRASC-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRASC-27: Description: Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This is further enhanced with (CASS-12148) in Cassandra 4.0. However, there’s no generally available mechanism to stream changes out of a Cassandra database; hence the utility of this feature is limited if not absent. Many applications use Cassandra as their primary data store. For various reasons(Caching, analyzing, indexing, etc), this data needs to be synchronized with derived/secondary data stores. We would like to emit change streams in real-time to consumers so that changes to Cassandra can be used for various purposes. *Goals* * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit changes in real-time. Priority for the initial implementation is safety and correctness, performance enhancements will follow in subsequent iterations *Nongoals* * Modify Cassandra storage engine to emit changes was: Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This is further enhanced with (CASS-12148) in Cassandra 4.0. However, there’s no generally available mechanism to stream changes out of a Cassandra database; hence the utility of this feature is limited if not absent. Many applications use Cassandra as their primary data store. For various reasons(Caching, analyzing, indexing, etc), this data needs to be synchronized with derived/secondary data stores. We would like to emit change streams in real-time to consumers so that changes to Cassandra can be used for various purposes. *Goals* * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit changes in real-time. Priority for the initial implementation is safety and correctness, performance enhancements will follow in subsequent iterations *Nongoals* * Modify Cassandra storage engine to emit changes > CDC reader in Apache Cassandra Sidecar > -- > > Key: CASSANDRASC-27 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-27 > Project: Sidecar for Apache Cassandra > Issue Type: New Feature >Reporter: Vinay Chella >Assignee: Tharanga Sampath Gamaethige >Priority: Normal > > Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This > is further enhanced with (CASS-12148) in Cassandra 4.0. > However, there’s no generally available mechanism to stream changes out of a > Cassandra database; hence the utility of this feature is limited if not > absent. > Many applications use Cassandra as their primary data store. For various > reasons(Caching, analyzing, indexing, etc), this data needs to be > synchronized with derived/secondary data stores. We would like to emit > change streams in real-time to consumers so that changes to Cassandra can be > used for various purposes. > *Goals* > * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit > changes in real-time. Priority for the initial implementation is safety and > correctness, performance enhancements will follow in subsequent iterations > *Nongoals* > * Modify Cassandra storage engine to emit changes > -- 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] (CASSANDRASC-27) CDC reader in Apache Cassandra Sidecar
Vinay Chella created CASSANDRASC-27: --- Summary: CDC reader in Apache Cassandra Sidecar Key: CASSANDRASC-27 URL: https://issues.apache.org/jira/browse/CASSANDRASC-27 Project: Sidecar for Apache Cassandra Issue Type: New Feature Reporter: Vinay Chella Assignee: Tharanga Sampath Gamaethige Apache Cassandra has the CDC (Change Data Capture) features since 3.8. This is further enhanced with (CASS-12148) in Cassandra 4.0. However, there’s no generally available mechanism to stream changes out of a Cassandra database; hence the utility of this feature is limited if not absent. Many applications use Cassandra as their primary data store. For various reasons(Caching, analyzing, indexing, etc), this data needs to be synchronized with derived/secondary data stores. We would like to emit change streams in real-time to consumers so that changes to Cassandra can be used for various purposes. *Goals* * Enhance Apache Cassandra sidecar with a CDC reader that can read and emit changes in real-time. Priority for the initial implementation is safety and correctness, performance enhancements will follow in subsequent iterations *Nongoals* * Modify Cassandra storage engine to emit changes -- 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-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15797:
-
Fix Version/s: (was: 4.0-alpha)
4.0-alpha5
4.0
Since Version: 4.0-alpha
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thank you for the [~yifanc]. Squashed your changes and committed into trunk at
[43c19878e38fbe260f9e6143aa43836e85cf2f44|https://github.com/apache/cassandra/commit/43c19878e38fbe260f9e6143aa43836e85cf2f44]
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0, 4.0-alpha5
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
[jira] [Commented] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112920#comment-17112920
]
Vinay Chella commented on CASSANDRA-15797:
--
Following dtests failed across java8 and java11, however these dtests are not
related to BingLogTest changes
- test_remote_query - cql_test.TestCQLSlowQuery
- test_local_query - cql_test.TestCQLSlowQuery
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation
[jira] [Commented] (CASSANDRA-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112870#comment-17112870 ] Vinay Chella commented on CASSANDRA-15748: -- Thank you [~stefan.miklosovic] for the patch, [~marcuse] for committing it. > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17112860#comment-17112860
]
Vinay Chella commented on CASSANDRA-15797:
--
circle ci tests:
https://app.circleci.com/pipelines/github/vinaykumarchella/cassandra?branch=15797-trunk
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
>
[jira] [Comment Edited] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110858#comment-17110858
]
Vinay Chella edited comment on CASSANDRA-15797 at 5/19/20, 5:23 AM:
Changes LGTM, +1. [~yifanc].
was (Author: vinaykumarcse):
Changes LGTM [~yifanc].
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
>
[jira] [Comment Edited] (CASSANDRA-15748) Provide ability to configure IAuditLogger
[
https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110859#comment-17110859
]
Vinay Chella edited comment on CASSANDRA-15748 at 5/19/20, 5:23 AM:
Latest changes LGTM, +1.
{quote}yes, this was done on purpose, I think I had this discussion with Marcus
privately, the thing is that I dont know how to propagate map
from nodetool's enableauditlogging - there is not any way to pass map from the
command line (at least the straightforward one). If you look closely into
StorageServiceMBean, that patch contains another enableAuditLog method which
can accept a map. It is there for cases somebody really wants to pass some
parameters via map there via JMX. There is as well the original method without
that map, because in tooling like JConsole, that method is not invokable
anymore if it contains a map, so there is not any way to invoke it via JMX in
JConsole, hence the original method is left there for this purpose{quote}
This sounds fair to me.
{quote}
It is there for cases somebody really wants to pass some parameters via map
there via JMX.
{quote}
Yes, let's add this to the documentation.
was (Author: vinaykumarcse):
{quote}yes, this was done on purpose, I think I had this discussion with Marcus
privately, the thing is that I dont know how to propagate map
from nodetool's enableauditlogging - there is not any way to pass map from the
command line (at least the straightforward one). If you look closely into
StorageServiceMBean, that patch contains another enableAuditLog method which
can accept a map. It is there for cases somebody really wants to pass some
parameters via map there via JMX. There is as well the original method without
that map, because in tooling like JConsole, that method is not invokable
anymore if it contains a map, so there is not any way to invoke it via JMX in
JConsole, hence the original method is left there for this purpose{quote}
This sounds fair to me.
{quote}
It is there for cases somebody really wants to pass some parameters via map
there via JMX.
{quote}
Yes, let's add this to the documentation.
> Provide ability to configure IAuditLogger
> -
>
> Key: CASSANDRA-15748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15748
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a parameterless constructor expected for IAuditLogger
> instances. There is not any way how to "inject" configuration properties from
> cassandra.yaml into these concrete classes. This would be very handy for
> custom IAuditLogger implementations.
>
> PR: [https://github.com/apache/cassandra/pull/555]
> [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748]
--
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-15748) Provide ability to configure IAuditLogger
[
https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110859#comment-17110859
]
Vinay Chella commented on CASSANDRA-15748:
--
{quote}yes, this was done on purpose, I think I had this discussion with Marcus
privately, the thing is that I dont know how to propagate map
from nodetool's enableauditlogging - there is not any way to pass map from the
command line (at least the straightforward one). If you look closely into
StorageServiceMBean, that patch contains another enableAuditLog method which
can accept a map. It is there for cases somebody really wants to pass some
parameters via map there via JMX. There is as well the original method without
that map, because in tooling like JConsole, that method is not invokable
anymore if it contains a map, so there is not any way to invoke it via JMX in
JConsole, hence the original method is left there for this purpose{quote}
This sounds fair to me.
{quote}
It is there for cases somebody really wants to pass some parameters via map
there via JMX.
{quote}
Yes, let's add this to the documentation.
> Provide ability to configure IAuditLogger
> -
>
> Key: CASSANDRA-15748
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15748
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Other
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.0-beta
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently there is a parameterless constructor expected for IAuditLogger
> instances. There is not any way how to "inject" configuration properties from
> cassandra.yaml into these concrete classes. This would be very handy for
> custom IAuditLogger implementations.
>
> PR: [https://github.com/apache/cassandra/pull/555]
> [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748]
--
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-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17110858#comment-17110858
]
Vinay Chella commented on CASSANDRA-15797:
--
Changes LGTM [~yifanc].
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
> net.openhft.chronicle.core.ReferenceCounter.newRefCountHistory(ReferenceCounter.java:45)
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15797:
-
Status: Ready to Commit (was: Review In Progress)
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
> net.openhft.chronicle.core.ReferenceCounter.newRefCountHistory(ReferenceCounter.java:45)
> [junit-timeout] at
>
[jira] [Commented] (CASSANDRA-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106065#comment-17106065 ] Vinay Chella commented on CASSANDRA-15748: -- This patch looks good to me except 1 minor nit and question related to nodetool command support. Were the changes for the NodeTool command in `EnableAuditLog.java` intentionally not included to support the new class and parameter format? If we are providing the ability to configure custom class with parameters, it is good to support the same via nodetool as well. If we decide not to support, calling it out could be a good idea > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 50m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106025#comment-17106025
]
Vinay Chella commented on CASSANDRA-15797:
--
[~yifanc] Thank you for the patch.
* BinLogTest.testPutAfterStop - Good catch on this, I was able to repro with
this assertion. LGTM
* BinLogTest.testBinLogStartStop - This change looks good to me except one nit
on assertion message and coundownlatch::await timeout, annotated these comments
in PR.
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
[jira] [Updated] (CASSANDRA-15797) Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15797:
-
Reviewers: Vinay Chella, Vinay Chella (was: Vinay Chella)
Vinay Chella, Vinay Chella
Status: Review In Progress (was: Patch Available)
> Fix flaky BinLogTest - org.apache.cassandra.utils.binlog.BinLogTest
> ---
>
> Key: CASSANDRA-15797
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15797
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Jon Meredith
>Assignee: Yifan Cai
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> An internal CI system is failing BinLogTest somewhat frequently under JDK11.
> Configuration was recently changed to reduce the number of cores the tests
> run with, however it is reproducible on an 8 core laptop.
> {code}
> [junit-timeout] OpenJDK 64-Bit Server VM warning: Option UseConcMarkSweepGC
> was deprecated in version 9.0 and will likely be removed in a future release.
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [Junit-timeout] WARNING: An illegal reflective access operation has occurred
> [junit-timeout] WARNING: Illegal reflective access by
> net.openhft.chronicle.core.Jvm (file:/.../lib/chronicle-core-1.16.4.jar) to
> field java.nio.Bits.RESERVED_MEMORY
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 13.895 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testPutAfterStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected: but
> was:
> [junit-timeout] junit.framework.AssertionFailedError: expected: but
> was:
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testPutAfterStop(BinLogTest.java:431)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [junit-timeout] at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [junit-timeout] at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> There's also a different failure under JDK8
> {code}
> junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 15.273 sec
> [junit-timeout]
> [junit-timeout] Testcase:
> testBinLogStartStop(org.apache.cassandra.utils.binlog.BinLogTest): FAILED
> [junit-timeout] expected:<2> but was:<0>
> [junit-timeout] junit.framework.AssertionFailedError: expected:<2> but was:<0>
> [junit-timeout] at
> org.apache.cassandra.utils.binlog.BinLogTest.testBinLogStartStop(BinLogTest.java:172)
> [junit-timeout]
> [junit-timeout]
> [junit-timeout] Test org.apache.cassandra.utils.binlog.BinLogTest FAILED
> {code}
> Reproducer
> {code}
> PASSED=0; time { while ant testclasslist -Dtest.classlistprefix=unit
> -Dtest.classlistfile=<(echo
> org/apache/cassandra/utils/binlog/BinLogTest.java); do PASSED=$((PASSED+1));
> echo PASSED $PASSED; done }; echo FAILED after $PASSED runs.
> {code}
> In the last four attempts it has taken 31, 38, 27 and 10 rounds respectively
> under JDK11 and took 51 under JDK8 (about 15 minutes).
> I have not tried running in a cpu-limited container or anything like that yet.
> Additionally, this went past in the logs a few times (under JDK11). No idea
> if it's just an artifact of weird test setup, or something more serious.
> {code}
> [junit-timeout] WARNING: Please consider reporting this to the maintainers of
> net.openhft.chronicle.core.Jvm
> [junit-timeout] WARNING: Use --illegal-access=warn to enable warnings of
> further illegal reflective access operations
> [junit-timeout] WARNING: All illegal access operations will be denied in a
> future release
> [junit-timeout] Testsuite: org.apache.cassandra.utils.binlog.BinLogTest Tests
> run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.839 sec
> [junit-timeout]
> [junit-timeout] java.lang.Throwable: 1e53135d-main creation ref-count=1
> [junit-timeout] at
>
[jira] [Updated] (CASSANDRA-15748) Provide ability to configure IAuditLogger
[ https://issues.apache.org/jira/browse/CASSANDRA-15748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15748: - Reviewers: Marcus Eriksson, Vinay Chella (was: Marcus Eriksson) > Provide ability to configure IAuditLogger > - > > Key: CASSANDRA-15748 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15748 > Project: Cassandra > Issue Type: Improvement > Components: Local/Other >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > Currently there is a parameterless constructor expected for IAuditLogger > instances. There is not any way how to "inject" configuration properties from > cassandra.yaml into these concrete classes. This would be very handy for > custom IAuditLogger implementations. > > PR: [https://github.com/apache/cassandra/pull/555] > [|https://github.com/smiklosovic/cassandra/tree/CASSANDRA-15748] -- 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-14747) Evaluate 200 node, compression=none, encryption=none, coalescing=off
[ https://issues.apache.org/jira/browse/CASSANDRA-14747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090760#comment-17090760 ] Vinay Chella commented on CASSANDRA-14747: -- The majority of our tests in this ticket were on the CASSANDRA-14503 branch with the goal of evaluating 4.0 (better latency, more throughput, fewer threads, fewer context switches, less GC allocation, and faster recovery time) while all internode settings off (no compression, no encryption, no coalescing), similar runs and results were recorded in CASSANDRA-15175 while internode settings on (compression and encryption). However, with CASSANDRA-15066 being merged, we might have to reevaluate these runs on the latest trunk/alpha-4. > Evaluate 200 node, compression=none, encryption=none, coalescing=off > - > > Key: CASSANDRA-14747 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14747 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Testing >Reporter: Joey Lynch >Assignee: Joey Lynch >Priority: Normal > Fix For: 4.0-beta > > Attachments: 3.0.17-QPS.png, 4.0.1-QPS.png, > 4.0.11-after-jolynch-tweaks.svg, 4.0.12-after-unconditional-flush.svg, > 4.0.15-after-sndbuf-fix.svg, 4.0.7-before-my-changes.svg, > 4.0_errors_showing_heap_pressure.txt, > 4.0_heap_histogram_showing_many_MessageOuts.txt, > i-0ed2acd2dfacab7c1-after-looping-fixes.svg, > trunk_14503_v2_cpuflamegraph.svg, trunk_vs_3.0.17_latency_under_load.png, > ttop_NettyOutbound-Thread_spinning.txt, > useast1c-i-0e1ddfe8b2f769060-mutation-flame.svg, > useast1e-i-08635fa1631601538_flamegraph_96node.svg, > useast1e-i-08635fa1631601538_ttop_netty_outbound_threads_96nodes, > useast1e-i-08635fa1631601538_uninlinedcpuflamegraph.0_96node_60sec_profile.svg > > > Tracks evaluating a 200 node cluster with all internode settings off (no > compression, no encryption, no coalescing). -- 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-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17089073#comment-17089073 ] Vinay Chella commented on CASSANDRA-15181: -- Started testing following on 4.0-alpha4 using our internal tools/automation * Can nodes successfully bootstrap? * How long does it take to bootstrap * Do nodes properly shutdown and start back up. * Are hints properly played after a node restart Test setup: * 12 node multi-region ( (6) us-east-1, (6) eu-west-1) i3.2xl * 48 node multi-region ((24) us-east-1, (24) eu-west-1) i3.xl * 192 node multi-region ((96) us-east-1, (96) eu-west-1) i3.xl I will share more details on test findings, test plan and setup with detailed test results after the runs. > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-beta > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- 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-15181) Ensure Nodes can Start and Stop
[ https://issues.apache.org/jira/browse/CASSANDRA-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17061196#comment-17061196 ] Vinay Chella commented on CASSANDRA-15181: -- Thanks for bringing it up, I shall test this again on alpha-3 and report if there are any issues. > Ensure Nodes can Start and Stop > --- > > Key: CASSANDRA-15181 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15181 > Project: Cassandra > Issue Type: Sub-task > Components: Legacy/Streaming and Messaging, Test/benchmark >Reporter: Joey Lynch >Assignee: Vinay Chella >Priority: High > Fix For: 4.0-beta > > > Let's load a cluster up with data and start killing nodes. We can do hard > failures (node terminations) and soft failures (process kills) We plan to > observe the following: > * Can nodes successfully bootstrap? > * How long does it take to bootstrap > * What are the effects of TLS on and off (e.g. on stream time) > * Are hints properly played after a node restart > * Do nodes properly shutdown and start back up. -- 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-15482) Guarantees
[ https://issues.apache.org/jira/browse/CASSANDRA-15482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15482: - Reviewers: Jon Haddad (was: Vinay Chella) > Guarantees > -- > > Key: CASSANDRA-15482 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15482 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0 > > > Added a page on Guarantees. > https://github.com/apache/cassandra/pull/411 -- 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-15474) Audit Logging - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17043838#comment-17043838 ] Vinay Chella commented on CASSANDRA-15474: -- Thank you. [~rustyrazorblade] > Audit Logging - New Feature > --- > > Key: CASSANDRA-15474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15474 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > Fix For: 4.0-alpha > > > Added a page on audit logging, a new feature. > https://github.com/apache/cassandra/pull/403 -- 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-15474) Audit Logging - New Feature
[ https://issues.apache.org/jira/browse/CASSANDRA-15474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15474: - Reviewers: Vinay Chella, Vinay Chella (was: Vinay Chella) Vinay Chella, Vinay Chella (was: Vinay Chella) Status: Review In Progress (was: Patch Available) > Audit Logging - New Feature > --- > > Key: CASSANDRA-15474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15474 > Project: Cassandra > Issue Type: Sub-task > Components: Documentation/Website >Reporter: DeepakVohra >Assignee: DeepakVohra >Priority: Normal > > Added a page on audit logging, a new feature. > https://github.com/apache/cassandra/pull/403 -- 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-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
[
https://issues.apache.org/jira/browse/CASSANDRA-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016450#comment-17016450
]
Vinay Chella commented on CASSANDRA-15314:
--
I believe these two(TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD,
TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD) are
different test cases, could be failing for the same reason.
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
> -
>
> Key: CASSANDRA-15314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: dtest
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
>
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
> system.log for remainder
> self =
> object at 0x7f6d90d43b38>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
>
[jira] [Comment Edited] (CASSANDRA-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
[
https://issues.apache.org/jira/browse/CASSANDRA-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17016450#comment-17016450
]
Vinay Chella edited comment on CASSANDRA-15314 at 1/16/20 1:33 AM:
---
I believe these two(TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD,
TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD) are
different test cases, could be failing for the same reason. I would be happy to
help with review both if you have a patch.
was (Author: vinaykumarcse):
I believe these two(TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD,
TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD) are
different test cases, could be failing for the same reason.
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
> -
>
> Key: CASSANDRA-15314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Labels: dtest
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
>
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
> system.log for remainder
> self =
> object at 0x7f6d90d43b38>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
>
[jira] [Updated] (CASSANDRA-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15309:
-
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/dd974b4b5f7770b293fdd8e4e76d7043508abec4
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Thank you for reviewing [~djoshi] and [~jolynch]. Committed as
[dd974b4b|https://github.com/apache/cassandra/commit/dd974b4b5f7770b293fdd8e4e76d7043508abec4]
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16976262#comment-16976262
]
Vinay Chella commented on CASSANDRA-15076:
--
[~marcuse] Do you have any comments on this?
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15382) Fix flaky unit test - testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15382:
-
Resolution: Duplicate
Status: Resolved (was: Triage Needed)
> Fix flaky unit test -
> testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest
> ---
>
> Key: CASSANDRA-15382
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15382
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Vinay Chella
>Priority: Normal
>
> As part of Apache Cassandra 4.0-alpha2, it is found out that
> "testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest" is
> flaky.
>
> +Failing test:+
> *testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest*
> {code:java}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.transport.IdleDisconnectTest.testIdleDisconnect(IdleDisconnectTest.java:56)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {code}
>
> +Sample failed runs:+
> *
> [https://circleci.com/gh/vinaykumarchella/cassandra/527#tests/containers/37]
> *
> [https://circleci.com/gh/vinaykumarchella/cassandra/535#tests/containers/37]
> * [https://circleci.com/gh/vinaykumarchella/cassandra/489#tests/containers/7]
> *
> [https://circleci.com/gh/vinaykumarchella/cassandra/512#tests/containers/37]
>
--
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-15382) Fix flaky unit test - testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest
Vinay Chella created CASSANDRA-15382:
Summary: Fix flaky unit test -
testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest
Key: CASSANDRA-15382
URL: https://issues.apache.org/jira/browse/CASSANDRA-15382
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Vinay Chella
As part of Apache Cassandra 4.0-alpha2, it is found out that
"testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest" is
flaky.
+Failing test:+
*testIdleDisconnect::org.apache.cassandra.transport.IdleDisconnectTest*
{code:java}
junit.framework.AssertionFailedError
at
org.apache.cassandra.transport.IdleDisconnectTest.testIdleDisconnect(IdleDisconnectTest.java:56)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
+Sample failed runs:+
* [https://circleci.com/gh/vinaykumarchella/cassandra/527#tests/containers/37]
* [https://circleci.com/gh/vinaykumarchella/cassandra/535#tests/containers/37]
* [https://circleci.com/gh/vinaykumarchella/cassandra/489#tests/containers/7]
* [https://circleci.com/gh/vinaykumarchella/cassandra/512#tests/containers/37]
--
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-15381) Failing test - testDatabaseDescriptorRef::org.apache.cassandra.config.DatabaseDescriptorRefTest
Vinay Chella created CASSANDRA-15381:
Summary: Failing test -
testDatabaseDescriptorRef::org.apache.cassandra.config.DatabaseDescriptorRefTest
Key: CASSANDRA-15381
URL: https://issues.apache.org/jira/browse/CASSANDRA-15381
Project: Cassandra
Issue Type: Bug
Components: Test/unit
Reporter: Vinay Chella
As part of Apache Cassandra 4.0-alpha2 voting, the following test is failing
across different test suites and runs.
CircleCI Run:
[https://circleci.com/gh/vinaykumarchella/cassandra/487#tests/containers/37]
*testDatabaseDescriptorRef-compression -
org.apache.cassandra.config.DatabaseDescriptorRefTest*
{code:java}
junit.framework.AssertionFailedError
at
org.apache.cassandra.config.DatabaseDescriptorRefTest.checkViolations(DatabaseDescriptorRefTest.java:293)
at
org.apache.cassandra.config.DatabaseDescriptorRefTest.testDatabaseDescriptorRef(DatabaseDescriptorRefTest.java:277){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-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16959494#comment-16959494
]
Vinay Chella commented on CASSANDRA-15309:
--
Fixed broken JAVA8_HOME in upgrade tests configurations.
Branch with fixes is
[here|https://github.com/vinaykumarchella/cassandra/tree/CASSANDRA_15309]
Successful upgrade Tests: [CircleCI
tests|https://circleci.com/workflow-run/bc17668a-becc-46c4-bc70-cad21e75e968]
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{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-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15309:
-
Test and Documentation Plan:
Branch with fixes is
[here|https://github.com/vinaykumarchella/cassandra/tree/CASSANDRA_15309]
Successful upgrade Tests: [CircleCI
tests|https://circleci.com/workflow-run/bc17668a-becc-46c4-bc70-cad21e75e968]
was:
Fixed broken JAVA8_HOME in upgrade tests configurations.
Branch with fixes is
[here|https://github.com/vinaykumarchella/cassandra/tree/CASSANDRA_15309]
Successful upgrade Tests: [CircleCI
tests|https://circleci.com/workflow-run/bc17668a-becc-46c4-bc70-cad21e75e968]
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{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-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15309:
-
Test and Documentation Plan:
Fixed broken JAVA8_HOME in upgrade tests configurations.
Branch with fixes is
[here|https://github.com/vinaykumarchella/cassandra/tree/CASSANDRA_15309]
Successful upgrade Tests: [CircleCI
tests|https://circleci.com/workflow-run/bc17668a-becc-46c4-bc70-cad21e75e968]
Status: Patch Available (was: In Progress)
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joey Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955732#comment-16955732
]
Vinay Chella commented on CASSANDRA-15076:
--
{quote}One option could be to add a new flag {{-i, --ignore}}. When used, the
auditlogviewer tool would silently skip unexpected records, try to recover and
continue on next record. That way users could at least try to read out records
from the queue even when some unexpected records are present. What do you think?
{quote}
I like this option. +1.
{quote}
On the topic of saving disk space and improving efficiency - we ran some tests
with shorter field-names, or even fieldless queues. That makes a significant
difference. But that's probably for another ticket.
{quote}
Please create a ticket so that we can follow up on this as well.
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950744#comment-16950744
]
Vinay Chella edited comment on CASSANDRA-15076 at 10/14/19 6:28 AM:
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. However, when reading log files with thousands of records, earlier
schematics were to ignore those records. Are we stopping the processing of the
audit log in new schematics? If so, It might be better to log warnings for
those specific records (_if needed)_ and move on with processing rather than
aborting the viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
was (Author: vinaykumarcse):
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are we stopping the
processing of the audit log? If so, It might be better to log warnings for
those specific records (_if needed)_ and move on rather than aborting the
viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950744#comment-16950744
]
Vinay Chella edited comment on CASSANDRA-15076 at 10/14/19 6:26 AM:
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are we stopping the
processing of the audit log? If so, It might be better to log warnings for
those if needed and move on rather than aborting the viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
was (Author: vinaykumarcse):
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are stopping the
processing of the audit log? If so, It might be better to log warnings for
those if needed and move on rather than aborting the viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950744#comment-16950744
]
Vinay Chella edited comment on CASSANDRA-15076 at 10/14/19 6:26 AM:
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are we stopping the
processing of the audit log? If so, It might be better to log warnings for
those specific records (_if needed)_ and move on rather than aborting the
viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
was (Author: vinaykumarcse):
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are we stopping the
processing of the audit log? If so, It might be better to log warnings for
those if needed and move on rather than aborting the viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16950744#comment-16950744
]
Vinay Chella commented on CASSANDRA-15076:
--
First pass of review:
* {{AuditLogViewer::verifyVersion}} and {{AuditLogViewer::readType}} are
throwing runtime exceptions in case of unexpected format and unsupported
versions. When reading log files with thousands of records, earlier schematics
were to ignore those records, but with new schematics, are stopping the
processing of the audit log? If so, It might be better to log warnings for
those if needed and move on rather than aborting the viewer.
* nitpick/idea: Would {{int16}} be the right choice for version? Can we be
aggressive to {{int8}}?
Can you also rebase your changes on the latest trunk?
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15076:
-
Reviewers: Vinay Chella, Vinay Chella (was: Vinay Chella)
Vinay Chella, Vinay Chella (was: Vinay Chella)
Status: Review In Progress (was: Patch Available)
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {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-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15309:
-
Bug Category: Parent values: Code(13163)
Complexity: Normal
Discovered By: Unit Test
Severity: Low
Status: Open (was: Triage Needed)
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15315) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trun
[
https://issues.apache.org/jira/browse/CASSANDRA-15315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15315:
-
Fix Version/s: 4.0-alpha
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD
> ---
>
> Key: CASSANDRA-15315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15315
> Project: Cassandra
> Issue Type: Bug
>Reporter: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
> [https://circleci.com/gh/vinaykumarchella/cassandra/451#tests/containers/11]
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:21:39 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:17:43,8. See
> system.log for remainder
> self =
> object at 0x7fbb75245a90>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 151813, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
> RuntimeError but I'm lazy
>
> line = f.readline()
> if line:
> reads = reads + line
> for e in tofind:
> m =
[jira] [Updated] (CASSANDRA-15315) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trun
[
https://issues.apache.org/jira/browse/CASSANDRA-15315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15315:
-
Component/s: Test/dtest
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD
> ---
>
> Key: CASSANDRA-15315
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15315
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
> [https://circleci.com/gh/vinaykumarchella/cassandra/451#tests/containers/11]
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:21:39 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:17:43,8. See
> system.log for remainder
> self =
> object at 0x7fbb75245a90>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 151813, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
> RuntimeError but I'm lazy
>
> line = f.readline()
> if line:
> reads = reads + line
> for e in tofind:
>
[jira] [Created] (CASSANDRA-15315) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trun
Vinay Chella created CASSANDRA-15315:
Summary: Fix failing test -
test_rolling_upgrade_with_internode_ssl -
upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_RandomPartitioner_EndsAt_Trunk_HEAD
Key: CASSANDRA-15315
URL: https://issues.apache.org/jira/browse/CASSANDRA-15315
Project: Cassandra
Issue Type: Bug
Reporter: Vinay Chella
Example failure:
[https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
[https://circleci.com/gh/vinaykumarchella/cassandra/451#tests/containers/11]
{code:java}
ccmlib.node.TimeoutError: 06 Sep 2019 20:21:39 [node2] Missing: ['127.0.0.1.*
now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:17:43,8. See
system.log for remainder
self =
@pytest.mark.timeout(3000)
def test_rolling_upgrade_with_internode_ssl(self):
"""
Rolling upgrade test using internode ssl.
"""
> self.upgrade_scenario(rolling=True, internode_ssl=True)
upgrade_tests/upgrade_through_versions_test.py:296:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
internode_ssl=internode_ssl)
upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
node.start(wait_other_notice=240, wait_for_binary_proto=True)
../env/src/ccm/ccmlib/node.py:751: in start
node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
exprs = ['127.0.0.1.* now UP'], from_mark = 151813, timeout = 240
process = None, verbose = False, filename = 'system.log'
def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
verbose=False, filename='system.log'):
"""
Watch the log until one or more (regular) expression are found.
This methods when all the expressions have been found or the method
timeouts (a TimeoutError is then raised). On successful completion,
a list of pair (line matched, match object) is returned.
"""
start = time.time()
tofind = [exprs] if isinstance(exprs, string_types) else exprs
tofind = [re.compile(e) for e in tofind]
matchings = []
reads = ""
if len(tofind) == 0:
return None
log_file = os.path.join(self.get_path(), 'logs', filename)
output_read = False
while not os.path.exists(log_file):
time.sleep(.5)
if start + timeout < time.time():
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
created.".format(log_file))
if process and not output_read:
process.poll()
if process.returncode is not None:
self.print_process_output(self.name, process, verbose)
output_read = True
if process.returncode != 0:
raise RuntimeError() # Shouldn't reuse RuntimeError
but I'm lazy
with open(log_file) as f:
if from_mark:
f.seek(from_mark)
while True:
# First, if we have a process to check, then check it.
# Skip on Windows - stdout/stderr is cassandra.bat
if not common.is_win() and not output_read:
if process:
process.poll()
if process.returncode is not None:
self.print_process_output(self.name, process,
verbose)
output_read = True
if process.returncode != 0:
raise RuntimeError() # Shouldn't reuse
RuntimeError but I'm lazy
line = f.readline()
if line:
reads = reads + line
for e in tofind:
m = e.search(line)
if m:
matchings.append((line, m))
tofind.remove(e)
if len(tofind) == 0:
return matchings[0] if isinstance(exprs,
string_types) else matchings
else:
# yep, it's ugly
time.sleep(1)
if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Missing: " + str([e.pattern for e in
>
[jira] [Updated] (CASSANDRA-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
[
https://issues.apache.org/jira/browse/CASSANDRA-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15314:
-
Fix Version/s: 4.0-alpha
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
> -
>
> Key: CASSANDRA-15314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
> Project: Cassandra
> Issue Type: Bug
>Reporter: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
>
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
> system.log for remainder
> self =
> object at 0x7f6d90d43b38>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
> RuntimeError but I'm lazy
>
> line = f.readline()
> if line:
> reads = reads + line
> for e in tofind:
> m = e.search(line)
> if m:
> matchings.append((line, m))
>
[jira] [Updated] (CASSANDRA-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
[
https://issues.apache.org/jira/browse/CASSANDRA-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15314:
-
Component/s: Test/dtest
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
> -
>
> Key: CASSANDRA-15314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Priority: Normal
> Labels: dtest
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
>
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
> system.log for remainder
> self =
> object at 0x7f6d90d43b38>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
> RuntimeError but I'm lazy
>
> line = f.readline()
> if line:
> reads = reads + line
> for e in tofind:
> m = e.search(line)
> if m:
>
[jira] [Created] (CASSANDRA-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
Vinay Chella created CASSANDRA-15314:
Summary: Fix failing test -
test_rolling_upgrade_with_internode_ssl -
upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
Key: CASSANDRA-15314
URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
Project: Cassandra
Issue Type: Bug
Reporter: Vinay Chella
Example failure:
[https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
{code:java}
ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
system.log for remainder
self =
@pytest.mark.timeout(3000)
def test_rolling_upgrade_with_internode_ssl(self):
"""
Rolling upgrade test using internode ssl.
"""
> self.upgrade_scenario(rolling=True, internode_ssl=True)
upgrade_tests/upgrade_through_versions_test.py:296:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
internode_ssl=internode_ssl)
upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
node.start(wait_other_notice=240, wait_for_binary_proto=True)
../env/src/ccm/ccmlib/node.py:751: in start
node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
filename=filename)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self =
exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
process = None, verbose = False, filename = 'system.log'
def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
verbose=False, filename='system.log'):
"""
Watch the log until one or more (regular) expression are found.
This methods when all the expressions have been found or the method
timeouts (a TimeoutError is then raised). On successful completion,
a list of pair (line matched, match object) is returned.
"""
start = time.time()
tofind = [exprs] if isinstance(exprs, string_types) else exprs
tofind = [re.compile(e) for e in tofind]
matchings = []
reads = ""
if len(tofind) == 0:
return None
log_file = os.path.join(self.get_path(), 'logs', filename)
output_read = False
while not os.path.exists(log_file):
time.sleep(.5)
if start + timeout < time.time():
raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
created.".format(log_file))
if process and not output_read:
process.poll()
if process.returncode is not None:
self.print_process_output(self.name, process, verbose)
output_read = True
if process.returncode != 0:
raise RuntimeError() # Shouldn't reuse RuntimeError
but I'm lazy
with open(log_file) as f:
if from_mark:
f.seek(from_mark)
while True:
# First, if we have a process to check, then check it.
# Skip on Windows - stdout/stderr is cassandra.bat
if not common.is_win() and not output_read:
if process:
process.poll()
if process.returncode is not None:
self.print_process_output(self.name, process,
verbose)
output_read = True
if process.returncode != 0:
raise RuntimeError() # Shouldn't reuse
RuntimeError but I'm lazy
line = f.readline()
if line:
reads = reads + line
for e in tofind:
m = e.search(line)
if m:
matchings.append((line, m))
tofind.remove(e)
if len(tofind) == 0:
return matchings[0] if isinstance(exprs,
string_types) else matchings
else:
# yep, it's ugly
time.sleep(1)
if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Missing: " + str([e.pattern for e in
> tofind]) + ":\n" + reads[:50] + ".\nSee {} for
> remainder".format(filename))
E
[jira] [Updated] (CASSANDRA-15314) Fix failing test - test_rolling_upgrade_with_internode_ssl - upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
[
https://issues.apache.org/jira/browse/CASSANDRA-15314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15314:
-
Labels: dtest (was: )
> Fix failing test - test_rolling_upgrade_with_internode_ssl -
> upgrade_tests.upgrade_through_versions_test.TestProtoV4Upgrade_AllVersions_EndsAt_Trunk_HEAD
> -
>
> Key: CASSANDRA-15314
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15314
> Project: Cassandra
> Issue Type: Bug
>Reporter: Vinay Chella
>Priority: Normal
> Labels: dtest
> Fix For: 4.0-alpha
>
>
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/468#tests/containers/11]
>
> {code:java}
> ccmlib.node.TimeoutError: 06 Sep 2019 20:23:57 [node2] Missing: ['127.0.0.1.*
> now UP']: INFO [HANDSHAKE-/127.0.0.1] 2019-09-06 20:20:01,7. See
> system.log for remainder
> self =
> object at 0x7f6d90d43b38>
> @pytest.mark.timeout(3000)
> def test_rolling_upgrade_with_internode_ssl(self):
> """
> Rolling upgrade test using internode ssl.
> """
> > self.upgrade_scenario(rolling=True, internode_ssl=True)
> upgrade_tests/upgrade_through_versions_test.py:296:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> upgrade_tests/upgrade_through_versions_test.py:352: in upgrade_scenario
> self.upgrade_to_version(version_meta, partial=True, nodes=(node,),
> internode_ssl=internode_ssl)
> upgrade_tests/upgrade_through_versions_test.py:456: in upgrade_to_version
> node.start(wait_other_notice=240, wait_for_binary_proto=True)
> ../env/src/ccm/ccmlib/node.py:751: in start
> node.watch_log_for_alive(self, from_mark=mark, timeout=wait_other_notice)
> ../env/src/ccm/ccmlib/node.py:568: in watch_log_for_alive
> self.watch_log_for(tofind, from_mark=from_mark, timeout=timeout,
> filename=filename)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self =
> exprs = ['127.0.0.1.* now UP'], from_mark = 150742, timeout = 240
> process = None, verbose = False, filename = 'system.log'
> def watch_log_for(self, exprs, from_mark=None, timeout=600, process=None,
> verbose=False, filename='system.log'):
> """
> Watch the log until one or more (regular) expression are found.
> This methods when all the expressions have been found or the
> method
> timeouts (a TimeoutError is then raised). On successful
> completion,
> a list of pair (line matched, match object) is returned.
> """
> start = time.time()
> tofind = [exprs] if isinstance(exprs, string_types) else exprs
> tofind = [re.compile(e) for e in tofind]
> matchings = []
> reads = ""
> if len(tofind) == 0:
> return None
>
> log_file = os.path.join(self.get_path(), 'logs', filename)
> output_read = False
> while not os.path.exists(log_file):
> time.sleep(.5)
> if start + timeout < time.time():
> raise TimeoutError(time.strftime("%d %b %Y %H:%M:%S",
> time.gmtime()) + " [" + self.name + "] Timed out waiting for {} to be
> created.".format(log_file))
> if process and not output_read:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process, verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse RuntimeError
> but I'm lazy
>
> with open(log_file) as f:
> if from_mark:
> f.seek(from_mark)
>
> while True:
> # First, if we have a process to check, then check it.
> # Skip on Windows - stdout/stderr is cassandra.bat
> if not common.is_win() and not output_read:
> if process:
> process.poll()
> if process.returncode is not None:
> self.print_process_output(self.name, process,
> verbose)
> output_read = True
> if process.returncode != 0:
> raise RuntimeError() # Shouldn't reuse
> RuntimeError but I'm lazy
>
> line = f.readline()
> if line:
> reads = reads + line
> for e in tofind:
> m = e.search(line)
> if m:
>
[jira] [Updated] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15313:
-
Fix Version/s: 4.0-alpha
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
>Reporter: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15313:
-
Component/s: Test/dtest
> Fix flaky - ChecksummingTransformerTest -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> ---
>
> Key: CASSANDRA-15313
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> During the recent runs, this test appears to be flaky.
> Example failure:
> [https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
> corruptionCausesFailure-compression -
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
> {code:java}
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
> at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
> at org.quicktheories.impl.Precursor.(Precursor.java:17)
> at
> org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
> at
> org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
> at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
> at
> org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
> at
> org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
> at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
> Source)
> at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
> at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
> Source)
> at
> org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
> at
> org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
> Source)
> at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
> at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
> at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
> at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
> Source)
> at org.quicktheories.impl.Core.generate(Core.java:150)
> at org.quicktheories.impl.Core.shrink(Core.java:103)
> at org.quicktheories.impl.Core.run(Core.java:39)
> at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
> at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
> at
> org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
> at
> org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15313?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15313:
-
Description:
During the recent runs, this test appears to be flaky.
Example failure:
[https://circleci.com/gh/vinaykumarchella/cassandra/459#tests/containers/94]
corruptionCausesFailure-compression -
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
{code:java}
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
at org.quicktheories.impl.Precursor.(Precursor.java:17)
at
org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
at
org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
at
org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
at
org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
Source)
at
org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
at
org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.impl.Core.generate(Core.java:150)
at org.quicktheories.impl.Core.shrink(Core.java:103)
at org.quicktheories.impl.Core.run(Core.java:39)
at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
at
org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
at
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
{code}
was:
During the recent runs, this test appears to be flaky.
corruptionCausesFailure-compression -
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
{code:java}
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
at org.quicktheories.impl.Precursor.(Precursor.java:17)
at
org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
at
org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
at
org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
at
org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
Source)
at
org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
at
org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
[jira] [Created] (CASSANDRA-15313) Fix flaky - ChecksummingTransformerTest - org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
Vinay Chella created CASSANDRA-15313:
Summary: Fix flaky - ChecksummingTransformerTest -
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
Key: CASSANDRA-15313
URL: https://issues.apache.org/jira/browse/CASSANDRA-15313
Project: Cassandra
Issue Type: Bug
Reporter: Vinay Chella
During the recent runs, this test appears to be flaky.
corruptionCausesFailure-compression -
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest
{code:java}
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.nio.HeapByteBuffer.(HeapByteBuffer.java:57)
at java.nio.ByteBuffer.allocate(ByteBuffer.java:335)
at org.quicktheories.impl.Precursor.(Precursor.java:17)
at
org.quicktheories.impl.ConcreteDetachedSource.(ConcreteDetachedSource.java:8)
at
org.quicktheories.impl.ConcreteDetachedSource.detach(ConcreteDetachedSource.java:23)
at org.quicktheories.generators.Retry.generate(CodePoints.java:51)
at
org.quicktheories.generators.Generate.lambda$intArrays$10(Generate.java:190)
at
org.quicktheories.generators.Generate$$Lambda$17/1847008471.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$mix$10(Gen.java:184)
at org.quicktheories.core.Gen$$Lambda$45/802243390.generate(Unknown
Source)
at org.quicktheories.core.Gen.lambda$flatMap$5(Gen.java:93)
at org.quicktheories.core.Gen$$Lambda$48/363509958.generate(Unknown
Source)
at
org.quicktheories.dsl.TheoryBuilder4.lambda$prgnToTuple$12(TheoryBuilder4.java:188)
at
org.quicktheories.dsl.TheoryBuilder4$$Lambda$40/2003496028.generate(Unknown
Source)
at org.quicktheories.core.DescribingGenerator.generate(Gen.java:255)
at org.quicktheories.core.FilteredGenerator.generate(Gen.java:225)
at org.quicktheories.core.Gen.lambda$map$0(Gen.java:36)
at org.quicktheories.core.Gen$$Lambda$20/71399214.generate(Unknown
Source)
at org.quicktheories.impl.Core.generate(Core.java:150)
at org.quicktheories.impl.Core.shrink(Core.java:103)
at org.quicktheories.impl.Core.run(Core.java:39)
at org.quicktheories.impl.TheoryRunner.check(TheoryRunner.java:35)
at org.quicktheories.dsl.TheoryBuilder4.check(TheoryBuilder4.java:150)
at
org.quicktheories.dsl.TheoryBuilder4.checkAssert(TheoryBuilder4.java:162)
at
org.apache.cassandra.transport.frame.checksum.ChecksummingTransformerTest.corruptionCausesFailure(ChecksummingTransformerTest.java:87)
{code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15310) Fix flakey - testIdleDisconnect - org.apache.cassandra.transport.IdleDisconnectTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16924550#comment-16924550
]
Vinay Chella commented on CASSANDRA-15310:
--
This test failed in my recent runs too, failed with the same exception.
https://circleci.com/gh/vinaykumarchella/cassandra/453#tests/containers/48
https://circleci.com/gh/vinaykumarchella/cassandra/463#tests/containers/86
> Fix flakey - testIdleDisconnect -
> org.apache.cassandra.transport.IdleDisconnectTest
> ---
>
> Key: CASSANDRA-15310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Joseph Lynch
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> Example run:
> [https://circleci.com/gh/jolynch/cassandra/561#tests/containers/86]
>
> {noformat}
> Your job ran 4428 tests with 1 failure
> - testIdleDisconnect -
> org.apache.cassandra.transport.IdleDisconnectTestjunit.framework.AssertionFailedError
> at
> org.apache.cassandra.transport.IdleDisconnectTest.testIdleDisconnect(IdleDisconnectTest.java:56)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15309) Make the upgrade tests run on trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-15309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella reassigned CASSANDRA-15309:
Assignee: Vinay Chella
> Make the upgrade tests run on trunk
> ---
>
> Key: CASSANDRA-15309
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15309
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Joseph Lynch
>Assignee: Vinay Chella
>Priority: Normal
> Fix For: 4.0-alpha
>
>
> It appears that the upgrade tests (j8_upgradetests-no-vnodes circleci target)
> don't really work on trunk right now, it appears to be a java home issue
> potentially. Example run: https://circleci.com/gh/jolynch/cassandra/553
> {noformat}
> Your job ran 4412 tests with 3923 failures
> - test_IN_clause_on_last_key -
> upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_xupgrade_tests/cql_tests.pymajor_version_int
> = 8
> def switch_jdks(major_version_int):
> """
> Changes the jdk version globally, by setting JAVA_HOME = JAVA[N]_HOME.
> This means the environment must have JAVA[N]_HOME set to switch to
> jdk version N.
> """
> new_java_home = 'JAVA{}_HOME'.format(major_version_int)
>
> try:
> > os.environ[new_java_home]
> upgrade_tests/upgrade_base.py:25:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> self = environ({'PYTHONUNBUFFERED': 'true', 'DEFAULT_DIR':
> '/home/cassandra/cassandra-dtest', 'CIRCLE_NODE_INDEX': '47',
> 'CIR...ade_tests/cql_tests.py::TestCQLNodes2RF1_Upgrade_current_2_1_x_To_indev_2_1_x::()::test_IN_clause_on_last_key
> (call)'})
> key = 'JAVA8_HOME'
> def __getitem__(self, key):
> try:
> value = self._data[self.encodekey(key)]
> except KeyError:
> # raise KeyError with the original key value
> > raise KeyError(key) from None
> E KeyError: 'JAVA8_HOME'{noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15105: - Authors: Per Otterström, Sumanth Pasupuleti (was: Per Otterström) Source Control Link: https://github.com/apache/cassandra/commit/225fa868884bdda1c20e0fcef61628eb6d941fbe Since Version: 4.0 Status: Resolved (was: Ready to Commit) Resolution: Fixed > Flaky unit test AuditLoggerTest > --- > > Key: CASSANDRA-15105 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15105 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Per Otterström >Assignee: Per Otterström >Priority: Normal > Fix For: 4.0 > > > Depending on execution order some tests will fail in the AuditLoggerTest > class. Any test case that happens to execute after > testExcludeSystemKeyspaces() will typically fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870016#comment-16870016
]
Vinay Chella edited comment on CASSANDRA-15105 at 6/22/19 2:21 AM:
---
Thanks for the patch [~eperott], [~sumanth.pasupuleti] for review and changes.
Following 2
[tests|https://circleci.com/gh/vinaykumarchella/cassandra/414#tests/containers/48]
have failed which seems to flaky on the trunk and not related to this change,
these tests also passed on subsequent runs ([unit
tests|https://circleci.com/gh/vinaykumarchella/cassandra/423#tests/containers/39])
{code:java}
testSendSmall - org.apache.cassandra.net.ConnectionTest
testSendLarge - org.apache.cassandra.net.ConnectionTest
{code}
Committed as
[225fa868884bdda1c20e0fcef61628eb6d941fbe|https://github.com/apache/cassandra/commit/225fa868884bdda1c20e0fcef61628eb6d941fbe]
was (Author: vinaykumarcse):
Thanks for the patch [~eperott], [~sumanth.pasupuleti] for review and changes.
Following 2
[tests|https://circleci.com/gh/vinaykumarchella/cassandra/414#tests/containers/48]
have failed which seems to flaky on the trunk and not related to this change,
these tests also passed on subsequent runs ([unit
tests|https://circleci.com/gh/vinaykumarchella/cassandra/423#tests/containers/39])
{code:java}
testSendSmall - org.apache.cassandra.net.ConnectionTest
testSendLarge - org.apache.cassandra.net.ConnectionTest
{code}
Committed as
[225fa868884bdda1c20e0fcef61628eb6d941fbe|https://github.com/apache/cassandra/commit/225fa868884bdda1c20e0fcef61628eb6d941fbe]
> Flaky unit test AuditLoggerTest
> ---
>
> Key: CASSANDRA-15105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15105
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> Depending on execution order some tests will fail in the AuditLoggerTest
> class. Any test case that happens to execute after
> testExcludeSystemKeyspaces() will typically fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16870016#comment-16870016
]
Vinay Chella commented on CASSANDRA-15105:
--
Thanks for the patch [~eperott], [~sumanth.pasupuleti] for review and changes.
Following 2
[tests|https://circleci.com/gh/vinaykumarchella/cassandra/414#tests/containers/48]
have failed which seems to flaky on the trunk and not related to this change,
these tests also passed on subsequent runs ([unit
tests|https://circleci.com/gh/vinaykumarchella/cassandra/423#tests/containers/39])
{code:java}
testSendSmall - org.apache.cassandra.net.ConnectionTest
testSendLarge - org.apache.cassandra.net.ConnectionTest
{code}
Committed as
[225fa868884bdda1c20e0fcef61628eb6d941fbe|https://github.com/apache/cassandra/commit/225fa868884bdda1c20e0fcef61628eb6d941fbe]
> Flaky unit test AuditLoggerTest
> ---
>
> Key: CASSANDRA-15105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15105
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> Depending on execution order some tests will fail in the AuditLoggerTest
> class. Any test case that happens to execute after
> testExcludeSystemKeyspaces() will typically fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15105: - Status: Ready to Commit (was: Review In Progress) > Flaky unit test AuditLoggerTest > --- > > Key: CASSANDRA-15105 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15105 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Per Otterström >Assignee: Per Otterström >Priority: Normal > Fix For: 4.0 > > > Depending on execution order some tests will fail in the AuditLoggerTest > class. Any test case that happens to execute after > testExcludeSystemKeyspaces() will typically fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853622#comment-16853622
]
Vinay Chella edited comment on CASSANDRA-15105 at 6/1/19 8:06 AM:
--
Thanks for the patch [~eperott], [~sumanth.pasupuleti] for review and changes.
We might need to exclude {{system_virtual_schema}} also from
{{AuditLoggerTest::testIncludeSystemKeyspaces()}} and
{{AuditLoggerTest::testExcludeSystemKeyspaces}} methods for future readiness
when and if {{system_virtual_schema}} is also quried from control connection,
this also keeps us in sync with defaults behavior. I pushed this change in my
brnach
[here|https://github.com/vinaykumarchella/cassandra/commits/CASSANDRA-15105]. I
will commit this as soon
[tests|https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/CASSANDRA-15105]
pass.
was (Author: vinaykumarcse):
Thanks for the patch [~eperott], [~sumanth.pasupuleti] and review.
We might need to exclude {{system_virtual_schema}} also from
{{AuditLoggerTest::testIncludeSystemKeyspaces()}} and
{{AuditLoggerTest::testExcludeSystemKeyspaces}} methods for future readiness
when and if {{system_virtual_schema}} is also quried from control connection,
this also keeps us in sync with defaults behavior. I pushed this change in my
brnach
[here|https://github.com/vinaykumarchella/cassandra/commits/CASSANDRA-15105]. I
will commit this as soon
[tests|https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/CASSANDRA-15105]
pass.
> Flaky unit test AuditLoggerTest
> ---
>
> Key: CASSANDRA-15105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15105
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> Depending on execution order some tests will fail in the AuditLoggerTest
> class. Any test case that happens to execute after
> testExcludeSystemKeyspaces() will typically fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16853622#comment-16853622
]
Vinay Chella commented on CASSANDRA-15105:
--
Thanks for the patch [~eperott], [~sumanth.pasupuleti] and review.
We might need to exclude {{system_virtual_schema}} also from
{{AuditLoggerTest::testIncludeSystemKeyspaces()}} and
{{AuditLoggerTest::testExcludeSystemKeyspaces}} methods for future readiness
when and if {{system_virtual_schema}} is also quried from control connection,
this also keeps us in sync with defaults behavior. I pushed this change in my
brnach
[here|https://github.com/vinaykumarchella/cassandra/commits/CASSANDRA-15105]. I
will commit this as soon
[tests|https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/CASSANDRA-15105]
pass.
> Flaky unit test AuditLoggerTest
> ---
>
> Key: CASSANDRA-15105
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15105
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL
>Reporter: Per Otterström
>Assignee: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> Depending on execution order some tests will fail in the AuditLoggerTest
> class. Any test case that happens to execute after
> testExcludeSystemKeyspaces() will typically fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837589#comment-16837589 ] Vinay Chella edited comment on CASSANDRA-15105 at 5/10/19 8:35 PM: --- [~eperott] Thank you for the patch, it is next on my list, will probably get to it next week. was (Author: vinaykumarcse): [~eperott] Thank you for the patch, I will get to it next week. > Flaky unit test AuditLoggerTest > --- > > Key: CASSANDRA-15105 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15105 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Per Otterström >Assignee: Per Otterström >Priority: Normal > Fix For: 4.0 > > > Depending on execution order some tests will fail in the AuditLoggerTest > class. Any test case that happens to execute after > testExcludeSystemKeyspaces() will typically fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15105) Flaky unit test AuditLoggerTest
[ https://issues.apache.org/jira/browse/CASSANDRA-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837589#comment-16837589 ] Vinay Chella commented on CASSANDRA-15105: -- [~eperott] Thank you for the patch, I will get to it next week. > Flaky unit test AuditLoggerTest > --- > > Key: CASSANDRA-15105 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15105 > Project: Cassandra > Issue Type: Bug > Components: Legacy/CQL >Reporter: Per Otterström >Assignee: Per Otterström >Priority: Normal > Fix For: 4.0 > > > Depending on execution order some tests will fail in the AuditLoggerTest > class. Any test case that happens to execute after > testExcludeSystemKeyspaces() will typically fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16819786#comment-16819786
]
Vinay Chella commented on CASSANDRA-15076:
--
Sure. Happy to help you with the review on this.
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Tools, Tool/fql
>Reporter: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15076) Align record header of FQL and audit binary log
[
https://issues.apache.org/jira/browse/CASSANDRA-15076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16816021#comment-16816021
]
Vinay Chella commented on CASSANDRA-15076:
--
Adding {{version}} field to {{BinAuditLogger}} entry sounds like a good idea to
me.
{quote}
But we could also consider to change audit type value from AuditLog to audit.
{quote}
+1.
> Align record header of FQL and audit binary log
> ---
>
> Key: CASSANDRA-15076
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15076
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/fql
>Reporter: Per Otterström
>Priority: Normal
> Fix For: 4.0
>
>
> The new full query logger and the audit logger support logging into binary
> Chronicle logs. Both create records with a small header to indicate what
> follows, but the two features have adopted different header formats. Let's
> align the record header format with this ticket.
> * Both features should use the same header layout. This makes it possible to
> give more user friendly error messages in the {{fqltool}} and
> {{auditlogviewr}} commands.
> * The record header should have a distinct {{type}} to indicate the type of
> record.
> * The record header should have a {{version}} so that the record format can
> evolve.
> Current record header format of the FQL is:
> {noformat}
> version:0(int16)
> type:(text)
> {noformat}
> where {{}} can be either {{batch}} or {{single-query}}.
> Current record header format of the binary audit log is:
> {noformat}
> type:AuditLog(text)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14772) Fix issues in audit / full query log interactions
[
https://issues.apache.org/jira/browse/CASSANDRA-14772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16809284#comment-16809284
]
Vinay Chella commented on CASSANDRA-14772:
--
Sounds reasonable to me [~eperott], please open a separate Jira, so that we can
discuss more on this idea and take it forward.
> Fix issues in audit / full query log interactions
> -
>
> Key: CASSANDRA-14772
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14772
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/CQL, Legacy/Tools
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 4.0
>
>
> There are some problems with the audit + full query log code that need to be
> resolved before 4.0 is released:
> * Fix performance regression in FQL that makes it less usable than it should
> be.
> * move full query log specific code to a separate package
> * do some audit log class renames (I keep reading {{BinLogAuditLogger}} vs
> {{BinAuditLogger}} wrong for example)
> * avoid parsing the CQL queries twice in {{QueryMessage}} when audit log is
> enabled.
> * add a new tool to dump audit logs (ie, let fqltool be full query log
> specific). fqltool crashes when pointed to them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-15056) SimpleClient should pass connection properties as options
[ https://issues.apache.org/jira/browse/CASSANDRA-15056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella reassigned CASSANDRA-15056: Assignee: Sumanth Pasupuleti > SimpleClient should pass connection properties as options > - > > Key: CASSANDRA-15056 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15056 > Project: Cassandra > Issue Type: Bug >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Labels: pull-request-available > Fix For: 4.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > As of today. SimpleClient does not pass CHECKSUM or COMPRESSION as options to > the server. In order for these parameters to take effect on the server side, > they should be passed as options. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
[
https://issues.apache.org/jira/browse/CASSANDRA-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15021:
-
Fix Version/s: 3.11.4
Since Version: 3.11.0
Status: Resolved (was: Ready to Commit)
Thanks for the review Ariel Weisberg
Committed as
[35b22f57a03ce9e14865e335b4eb30fc11645a5c|https://github.com/apache/cassandra-dtest/commit/35b22f57a03ce9e14865e335b4eb30fc11645a5c]
to cassandra-dtest repo
> TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade
> test is failing with TypeError
>
>
> Key: CASSANDRA-15021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
> Fix For: 3.11.4
>
>
> While running upgrade tests for 3.11.4 candidate I noticed that
> {{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
> is failing with TypeError.
> Example run with error:
> {code:java}
> self = object at 0x7f8db9908240>
> @since('3.0', max_version='3.99')
> def test_upgrade_with_range_tombstone_eoc_0(self):
> """
> Check sstable upgrading when the sstable contains a range
> tombstone with EOC=0.
>
> @jira_ticket CASSANDRA-12423
> """
> session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
>
> session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
> PRIMARY KEY (id, c1, c2)) "
> "with compact storage and compression =
> {'sstable_compression': ''};")
>
> range_delete = {
> i32(1): {
> 'rt': [Mutation(deletion=Deletion(2470761440040513,
>
> predicate=SlicePredicate(slice_range=SliceRange(
> > start=composite('a',
> > eoc='\x00'),
> finish=composite('asd',
> eoc='\x00')]
> }
> }
> upgrade_tests/storage_engine_upgrade_test.py:434:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> item1 = b'a', item2 = None, eoc = '\x00'
> def composite(item1, item2=None, eoc=b'\x00'):
> if isinstance(item1, str):
> item1 = utf8encode(item1)
> if isinstance(item2, str):
> item2 = utf8encode(item2)
>
> > packed = _i16(len(item1)) + item1 + eoc
> E TypeError: can't concat str to bytes
> thrift_test.py:153: TypeError
> {code}
> This TypeError is from Python3 migration. Python 3's standard string type is
> Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
> automatic coercion between bytes and unicode strings is provided -
> [context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
> This change in python3 is leading to "TypeError: can't concat str to bytes"
> while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793290#comment-16793290
]
Vinay Chella commented on CASSANDRA-15016:
--
Thanks for the review [~aweisberg]
Squashed and committed as
[9c6aa8a76de24df75de73218c917571346cc509c|https://github.com/apache/cassandra-dtest/commit/9c6aa8a76de24df75de73218c917571346cc509c]
to cassandra-dtest
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15016:
-
Fix Version/s: 3.11.4
Since Version: 3.11.0
Status: Resolved (was: Ready to Commit)
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Low
> Labels: dtest, test, upgrade-dtest
> Fix For: 3.11.4
>
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15043) Add heap dump inspections to sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-15043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15043: - Reviewers: Dinesh Joshi, Vinay Chella (was: Dinesh Joshi) > Add heap dump inspections to sidecar > > > Key: CASSANDRA-15043 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15043 > Project: Cassandra > Issue Type: New Feature > Components: Sidecar >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Major > > Add to ui a tool to view heap dumps cassandra produces when OOM to identify > the issue that caused it. Three views > 1. C* inspections - useful inspections like a list of the largest partitions, > most active partitions, largest (and most by table and partition) mutations. > 2. Threads - their stack traces, heap size, and values of things in local > processing scope (that can be clicked through and explored) > 3. Metrics - view state of all the metrics at time of heap dump > Additional requirement: since this runs on cassandra sidecar it should use > very low memory (ie sub 100mb) and not consume massive cpu -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16785049#comment-16785049 ] Vinay Chella edited comment on CASSANDRA-15020 at 3/5/19 11:52 PM: --- +1 I also applied this patch on 2.2 as well since this issue exists on 2.2 too. Committed to 2.2 and up as [53db417b3cd918d61b9ca1a3662495c8a32605f1|https://github.com/apache/cassandra/commit/53db417b3cd918d61b9ca1a3662495c8a32605f1] Thank you [~lucinda] and [~cscotta]. Thank you [~zznate] for reviewing it offline. was (Author: vinaykumarcse): +1 I also applied this patch on 2.2 as well since this issue exists on 2.2 too. Committed to 2.2 and up as [53db417b3cd918d61b9ca1a3662495c8a32605f1|https://github.com/apache/cassandra/commit/53db417b3cd918d61b9ca1a3662495c8a32605f1] > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15020: - Resolution: Fixed Fix Version/s: 4.0 3.11.5 3.0.19 2.2.15 Status: Resolved (was: Ready to Commit) +1 I also applied this patch on 2.2 as well since this issue exists on 2.2 too. Committed to 2.2 and up as [53db417b3cd918d61b9ca1a3662495c8a32605f1|https://github.com/apache/cassandra/commit/53db417b3cd918d61b9ca1a3662495c8a32605f1] > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Fix For: 2.2.15, 3.0.19, 3.11.5, 4.0 > > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15020: - Status: Ready to Commit (was: Patch Available) > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15020) Invalid CQL in documentation
[ https://issues.apache.org/jira/browse/CASSANDRA-15020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15020: - Reviewer: Vinay Chella (was: Nate McCall) > Invalid CQL in documentation > > > Key: CASSANDRA-15020 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15020 > Project: Cassandra > Issue Type: Improvement > Components: Documentation/Website >Reporter: Liudmila Kornilova >Assignee: C. Scott Andreas >Priority: Trivial > Attachments: CASSANDRA-15020-3.0.patch, > CASSANDRA-15020-trunk-3.11.patch > > > [http://cassandra.apache.org/doc/4.0/cql/security.html] > 1. > Wrong: > CREATE USER *IF EXISTS* alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE *IF EXISTS* alice WITH PASSWORD = 'password_a' AND LOGIN = true > AND SUPERUSER = true; > Correct: > CREATE USER IF *NOT* EXISTS alice WITH PASSWORD 'password_a' SUPERUSER; > CREATE ROLE IF *NOT* EXISTS alice WITH PASSWORD = 'password_a' AND LOGIN = > true AND SUPERUSER = true; > > 2. > Wrong: > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *WITH* LOGIN = true; > Correct: > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > CREATE ROLE alice WITH PASSWORD = 'password_a' *AND* LOGIN = true; > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15030) Add support for SSL and bindable address to sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-15030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774858#comment-16774858 ] Vinay Chella commented on CASSANDRA-15030: -- The latest change looks good and it accepts both keystore and truststore, looks good. > Add support for SSL and bindable address to sidecar > --- > > Key: CASSANDRA-15030 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15030 > Project: Cassandra > Issue Type: New Feature > Components: Sidecar >Reporter: Dinesh Joshi >Assignee: Dinesh Joshi >Priority: Minor > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We need to support SSL for the sidecar's REST interface. We should also have > the ability to bind the sidecar's API to a specific network interface. This > patch adds support for both. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15030) Add support for SSL and bindable address to sidecar
[
https://issues.apache.org/jira/browse/CASSANDRA-15030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16774650#comment-16774650
]
Vinay Chella commented on CASSANDRA-15030:
--
First pass review:
AbstractHealthServiceTest:
* Unused references
* Unused {{Router router = injector.getInstance(Router.class);}}
* Avoid {{sout}}, use of loggers might be a good idea here
TestModule:
* {{bind(CassandraSidecarDaemon.class).in(Singleton.class)}}, you can simplify
this by using class level scope @Singleton
MainModule:
* Should we also add truststore context
[here|https://github.com/dineshjoshi/cassandra-sidecar/commit/d9cdb088f2efdb8e537d35f3f9c492e51f55c3d1#diff-a54ca631e55a83c55242baa44ed6e271R42]?
I believe this
[path|https://github.com/dineshjoshi/cassandra-sidecar/commit/d9cdb088f2efdb8e537d35f3f9c492e51f55c3d1#diff-a54ca631e55a83c55242baa44ed6e271R64]
can be either truststore or keystore here?
Also, you might want to run code style formatting on this changeset.
> Add support for SSL and bindable address to sidecar
> ---
>
> Key: CASSANDRA-15030
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15030
> Project: Cassandra
> Issue Type: New Feature
> Components: Sidecar
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to support SSL for the sidecar's REST interface. We should also have
> the ability to bind the sidecar's API to a specific network interface. This
> patch adds support for both.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15031) Add integration tests task to sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-15031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15031: - Component/s: Sidecar > Add integration tests task to sidecar > - > > Key: CASSANDRA-15031 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15031 > Project: Cassandra > Issue Type: Improvement > Components: Sidecar >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Major > > Add support to run longer run tasks, and include some tests for existing > health service -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15028) Autogenerate api docs in sidecar
[ https://issues.apache.org/jira/browse/CASSANDRA-15028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinay Chella updated CASSANDRA-15028: - Component/s: Sidecar > Autogenerate api docs in sidecar > > > Key: CASSANDRA-15028 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15028 > Project: Cassandra > Issue Type: New Feature > Components: Sidecar >Reporter: Chris Lohfink >Assignee: Chris Lohfink >Priority: Minor > Labels: pull-request-available > Attachments: screenshot-1.png, screenshot-2.png > > Time Spent: 10m > Remaining Estimate: 0h > > Swagger can provide us a way to define the api and autogenerate nice looking > docs and have interactive UI for trying the APIs. This can also be used to > autogenerate client libraries in many different libraries. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16769173#comment-16769173
]
Vinay Chella commented on CASSANDRA-15016:
--
Thank you for the review [~aweisberg]
{quote}Why did you remove this assertion?
{quote}
[assert_almost_equal
|https://github.com/vinaykumarchella/cassandra-dtest/commit/adcc84d71de6f727d05647b21ff6c48d7bf6920b#diff-0b30b9f097df89d74be1d1af8205ac7eL115]
is flaky across the versions. I tried to change this to achieve a more
fine-grained size check. Context: this
[check|https://github.com/vinaykumarchella/cassandra-dtest/commit/adcc84d71de6f727d05647b21ff6c48d7bf6920b#diff-0b30b9f097df89d74be1d1af8205ac7eL115]
is to ensure that cleanup and compact did their job, but we end up checking
the entire node size which might be varying as additional tables that we *may*
introduce in new releases or already introduced ones from across the versions.
We also don't put in enough data to make that the dominant cost for test
keyspaces.
Based on our offline discussion and suggestions, I added table specific data
size check, and this enables to do data size check for tables that we are
interested in, with this change now we achieve our goal of size checking
without depending on external factors of system tables and their size.
{quote}Do you need check bootstrap_from_version? Seems like it is enough to
just check compatibility_flag_on.
{quote}
I made this better now, instead of exposing it as a {{compatibility_flag_on}},
now passing {{bootstrap}} function with compatibility_flag, this makes the
better use of
[bootstrap|https://github.com/apache/cassandra-dtest/blob/master/bootstrap_test.py#L46]
parameter in {{_base_bootstrap_test}}
{quote}Can you better document what is going on and why the compatibility flag
is being set in the tests, so the next person knows what is going on?
{quote}
I tried to add context in code and also referenced CASSANDRA-13004 in comments.
||dtest||upgrade-test||
|[dtest-fix-branch|https://github.com/vinaykumarchella/cassandra-dtest/tree/fix_failing_upgradetest]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.11.4-tentative.svg?circle-token=237fa63201f848ed64789902be862015f74bec9b!|https://circleci.com/gh/vinaykumarchella/cassandra/352]|
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
>
[jira] [Updated] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
[
https://issues.apache.org/jira/browse/CASSANDRA-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15021:
-
Status: Patch Available (was: Open)
I went ahead and made
[composite|https://github.com/apache/cassandra-dtest/blob/master/thrift_test.py#L147]
function compatible with python2 and python3, this should fix the
{{TypeError}} in {{test_upgrade_with_range_tombstone_eoc_0}}
||dtest||upgrade-test||
|[dtest-fix-branch|https://github.com/vinaykumarchella/cassandra-dtest/tree/CASSANDRA-15021]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.11.4-tentative.svg?circle-token=237fa63201f848ed64789902be862015f74bec9b!|https://circleci.com/gh/vinaykumarchella/cassandra/358]|
> TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade
> test is failing with TypeError
>
>
> Key: CASSANDRA-15021
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> While running upgrade tests for 3.11.4 candidate I noticed that
> {{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
> is failing with TypeError.
> Example run with error:
> {code:java}
> self = object at 0x7f8db9908240>
> @since('3.0', max_version='3.99')
> def test_upgrade_with_range_tombstone_eoc_0(self):
> """
> Check sstable upgrading when the sstable contains a range
> tombstone with EOC=0.
>
> @jira_ticket CASSANDRA-12423
> """
> session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
>
> session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
> PRIMARY KEY (id, c1, c2)) "
> "with compact storage and compression =
> {'sstable_compression': ''};")
>
> range_delete = {
> i32(1): {
> 'rt': [Mutation(deletion=Deletion(2470761440040513,
>
> predicate=SlicePredicate(slice_range=SliceRange(
> > start=composite('a',
> > eoc='\x00'),
> finish=composite('asd',
> eoc='\x00')]
> }
> }
> upgrade_tests/storage_engine_upgrade_test.py:434:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> item1 = b'a', item2 = None, eoc = '\x00'
> def composite(item1, item2=None, eoc=b'\x00'):
> if isinstance(item1, str):
> item1 = utf8encode(item1)
> if isinstance(item2, str):
> item2 = utf8encode(item2)
>
> > packed = _i16(len(item1)) + item1 + eoc
> E TypeError: can't concat str to bytes
> thrift_test.py:153: TypeError
> {code}
> This TypeError is from Python3 migration. Python 3's standard string type is
> Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
> automatic coercion between bytes and unicode strings is provided -
> [context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
> This change in python3 is leading to "TypeError: can't concat str to bytes"
> while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15023) Scheduled tasks in management process
Vinay Chella created CASSANDRA-15023:
Summary: Scheduled tasks in management process
Key: CASSANDRA-15023
URL: https://issues.apache.org/jira/browse/CASSANDRA-15023
Project: Cassandra
Issue Type: Sub-task
Components: Tool/nodetool
Reporter: Vinay Chella
Assignee: Vinay Chella
Scheduled tasks in a management process operate some task on a periodic or
scheduled basis (e.g. periodic cleanups, compactions, flushes, backups etc…).
We propose pluggable scheduled jobs which allow users to achieve simple yet
powerful operations activities that are frequently required in Cassandra.
Basically, these are cron jobs.
*Proposed Scope*
* _GET /v1/scheduled/node_: Shows the scheduled tasks that run on the local
host by the sidecar. These are determined via the configuration of the
management process.
* _Cleanup_ of tables (nodetool cleanup) in Cassandra will be implemented as
part of this JIRA. This maintenance activity is an important task when your
environment is prone to lose nodes and move nodes all the time. Having
{{cleanup}} activity scheduled on a regular basis helps to maintain the
fidelity of the database.
{code:java}
# View scheduled tasks on a node
curl -i -XGET 'localhost:5000/v1/scheduled/node'
HTTP/1.0 200 OK
{
"tasks": {
"cleanup": {
"exclude_kfs": "*system*",
"cron_schedule": "1 12 * * *"
}
}
}
{code}
Reference from CIP-1: [Scheduled
Management|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652224#CIP-1:ApacheCassandraManagementProcess(es)-5.Scheduledmanagement]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14395) C* Management process
[
https://issues.apache.org/jira/browse/CASSANDRA-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768853#comment-16768853
]
Vinay Chella commented on CASSANDRA-14395:
--
{quote}I had to check in jolokia as I couldn't find a great way to get it
included in the distro using gradle. I think Vinay Chella has a way of doing it
and can send it part of the follow on PR.
{quote}
Yes, I am building on top your patch, will send it as a followup PR.
* You might want to avoid [deleting all contents of lib
directory|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-c197962302397baf3a4cc36463dce5eaR81],
as {{clean}} task would delete the jolokia agent that you are [adding as part
of this commit
|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-429500bdfb9752a754bc71eb1dd9e0af].
* {{runApp}} task does not exist on {{application}} gradle plugin, {{run}} task
would be the ideal one to get what you are looking for.
> C* Management process
> -
>
> Key: CASSANDRA-14395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14395
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
> Attachments: Looking towards an Official Cassandra Sidecar -
> Netflix.pdf
>
>
> I would like to propose amending Cassandra's architecture to include a
> management process. The detailed description is here:
> https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY3s/edit
> I'd like to propose seeding this with a few simple use-cases such as Health
> Checks, Bulk Commands with a simple REST API interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14395) C* Management process
[
https://issues.apache.org/jira/browse/CASSANDRA-14395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16768853#comment-16768853
]
Vinay Chella edited comment on CASSANDRA-14395 at 2/15/19 1:54 AM:
---
{quote}I had to check in jolokia as I couldn't find a great way to get it
included in the distro using gradle. I think Vinay Chella has a way of doing it
and can send it part of the follow on PR.
{quote}
Yes, I am building on top your patch, will send it as a followup PR.
* You might want to avoid [deleting all contents of lib
directory|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-c197962302397baf3a4cc36463dce5eaR81],
as {{clean}} task would delete the jolokia agent that you are [adding as part
of this commit
|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-429500bdfb9752a754bc71eb1dd9e0af].
* {{runApp}}
[task|https://github.com/dineshjoshi/cassandra-sidecar/commit/fff99699000b933c6523fef600c49b761f4b6d7b#diff-04c6e90faac2675aa89e2176d2eec7d8R19]
does not exist on {{application}} gradle plugin, {{run}} task would be the
ideal one to get what you are looking for.
was (Author: vinaykumarcse):
{quote}I had to check in jolokia as I couldn't find a great way to get it
included in the distro using gradle. I think Vinay Chella has a way of doing it
and can send it part of the follow on PR.
{quote}
Yes, I am building on top your patch, will send it as a followup PR.
* You might want to avoid [deleting all contents of lib
directory|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-c197962302397baf3a4cc36463dce5eaR81],
as {{clean}} task would delete the jolokia agent that you are [adding as part
of this commit
|https://github.com/dineshjoshi/cassandra-sidecar/commit/0e918c7a9a43205a21b3e3b183c695d832cf931d#diff-429500bdfb9752a754bc71eb1dd9e0af].
* {{runApp}} task does not exist on {{application}} gradle plugin, {{run}} task
would be the ideal one to get what you are looking for.
> C* Management process
> -
>
> Key: CASSANDRA-14395
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14395
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Dinesh Joshi
>Assignee: Dinesh Joshi
>Priority: Major
> Attachments: Looking towards an Official Cassandra Sidecar -
> Netflix.pdf
>
>
> I would like to propose amending Cassandra's architecture to include a
> management process. The detailed description is here:
> https://docs.google.com/document/d/1UV9pE81NaIUF3g4L1wxq09nT11AkSQcMijgLFwGsY3s/edit
> I'd like to propose seeding this with a few simple use-cases such as Health
> Checks, Bulk Commands with a simple REST API interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-15021) TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test is failing with TypeError
Vinay Chella created CASSANDRA-15021:
Summary:
TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0 upgrade test
is failing with TypeError
Key: CASSANDRA-15021
URL: https://issues.apache.org/jira/browse/CASSANDRA-15021
Project: Cassandra
Issue Type: Bug
Components: Test/dtest
Reporter: Vinay Chella
Assignee: Vinay Chella
While running upgrade tests for 3.11.4 candidate I noticed that
{{upgrade_tests.storage_engine_upgrade_test.TestBootstrapAfterUpgrade.test_upgrade_with_range_tombstone_eoc_0}}
is failing with TypeError.
Example run with error:
{code:java}
self =
@since('3.0', max_version='3.99')
def test_upgrade_with_range_tombstone_eoc_0(self):
"""
Check sstable upgrading when the sstable contains a range tombstone
with EOC=0.
@jira_ticket CASSANDRA-12423
"""
session = self._setup_cluster(cluster_options={'start_rpc': 'true'})
session.execute("CREATE TABLE rt (id INT, c1 TEXT, c2 TEXT, v INT,
PRIMARY KEY (id, c1, c2)) "
"with compact storage and compression =
{'sstable_compression': ''};")
range_delete = {
i32(1): {
'rt': [Mutation(deletion=Deletion(2470761440040513,
predicate=SlicePredicate(slice_range=SliceRange(
> start=composite('a',
> eoc='\x00'),
finish=composite('asd',
eoc='\x00')]
}
}
upgrade_tests/storage_engine_upgrade_test.py:434:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
item1 = b'a', item2 = None, eoc = '\x00'
def composite(item1, item2=None, eoc=b'\x00'):
if isinstance(item1, str):
item1 = utf8encode(item1)
if isinstance(item2, str):
item2 = utf8encode(item2)
> packed = _i16(len(item1)) + item1 + eoc
E TypeError: can't concat str to bytes
thrift_test.py:153: TypeError
{code}
This TypeError is from Python3 migration. Python 3's standard string type is
Unicode based, and Python 3 adds a dedicated bytes type, but critically, no
automatic coercion between bytes and unicode strings is provided -
[context|https://www.python.org/dev/peps/pep-0404/#strings-and-bytes]
This change in python3 is leading to "TypeError: can't concat str to bytes"
while appending bytes to string.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinay Chella updated CASSANDRA-15016:
-
Reviewer: Ariel Weisberg
Status: Patch Available (was: Open)
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-15016) bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on 3.11.4
[
https://issues.apache.org/jira/browse/CASSANDRA-15016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16763255#comment-16763255
]
Vinay Chella commented on CASSANDRA-15016:
--
Fixed this issue by adding {{compatibility_flag}} to
test_simple_bootstrap_mixed_versions. This adds
{{cassandra.force_3_0_protocol_version}} flag to the new bootstrapping node
beforing joining the cluster.
Here are the updated dtest and upgrade tests run with that branch
||dtest||upgrade-test||
|[dtest-fix-branch|https://github.com/vinaykumarchella/cassandra-dtest/tree/fix_failing_upgradetest]|[!https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.11.4-tentative.svg?circle-token=237fa63201f848ed64789902be862015f74bec9b!|https://circleci.com/gh/vinaykumarchella/cassandra/345]|
> bootstrap_upgrade_test.py::test_simple_bootstrap_mixed_versions is failing on
> 3.11.4
>
>
> Key: CASSANDRA-15016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15016
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest
>Reporter: Vinay Chella
>Assignee: Vinay Chella
>Priority: Minor
> Labels: dtest, test, upgrade-dtest
>
> {{test_simple_bootstrap_mixed_versions}} is failing due to CASSANDRA-13004,
> which introduced "cassandra.force_3_0_protocol_version" for schema migrations
> during upgrades from 3.0.14 upwards. This flag is missing in
> `test_simple_bootstrap_mixed_versions` while we are adding/bootstrapping
> 3.11.4 node to an existing 3.5 version of C* node, which resulted in {{ks}}
> keyspace schema/data not being bootstrapped to the new node.
> I debugged and confirmed that
> [MigrationManager::is30Compatible|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L181-L185]
> is returning false which is forcing
> [MigrationManager::shouldPullSchemaFrom|https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/service/MigrationManager.java#L168-L177]
> to return false as well.
> *from debug logs:*
> {code:java}
> DEBUG [GossipStage:1] 2019-02-06 23:20:47,392 MigrationManager.java:115 - Not
> pulling schema because versions match or shouldPullSchemaFrom returned fal
> {code}
> *Failed upgrade tests:
> [https://circleci.com/gh/aweisberg/cassandra/2593#tests/containers/11]*
> *From failed dtest:*
> {code:java}
> self = 0x7f1bec192eb8>
> @pytest.mark.no_vnodes
> @since('3.10', max_version='3.99')
> def test_simple_bootstrap_mixed_versions(self):
> > self._base_bootstrap_test(bootstrap_from_version="3.5")
> upgrade_tests/bootstrap_upgrade_test.py:20:
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> bootstrap_test.py:114: in _base_bootstrap_test
> assert_almost_equal(size1, size2, error=0.3)
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> _
> args = (429.36, 133.1), kwargs = {'error': 0.3}, error = 0.3, vmax = 429.36
> vmin = 133.1, error_message = ''
> def assert_almost_equal(*args, **kwargs):
> """
> Assert variable number of arguments all fall within a margin of error.
> @params *args variable number of numerical arguments to check
> @params error Optional margin of error. Default 0.16
> @params error_message Optional error message to print. Default ''
>
> Examples:
> assert_almost_equal(sizes[2], init_size)
> assert_almost_equal(ttl_session1, ttl_session2[0][0], error=0.005)
> """
> error = kwargs['error'] if 'error' in kwargs else 0.16
> vmax = max(args)
> vmin = min(args)
> error_message = '' if 'error_message' not in kwargs else
> kwargs['error_message']
> assert vmin > vmax * (1.0 - error) or vmin == vmax, \
> > "values not within {:.2f}% of the max: {} ({})".format(error *
> > 100, args, error_message)
> E AssertionError: values not within 30.00% of the max: (429.36, 133.1)
> ()
> tools/assertions.py:206: AssertionError
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
