[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17498315#comment-17498315 ] Aleksei Zotov commented on CASSANDRA-17338: --- No, I feel "1 of 38" is clear as well. I just misread your original message, sorry for confusion. > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.27, 3.11.13 > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17495771#comment-17495771 ] Aleksei Zotov commented on CASSANDRA-17338: --- [~jmckenzie] > I doubt a test fix ticket is going to give rise to any of those "1 of 38" > failures below, but worth the basic visibility to author / reviewer. Nice report! I feel these changes are not related to the test failures because the idea of the fix is to port some changes from 4.0 to 3.0/3.11. So nothing in 4.0/trunk has been actually changed (apart from _CHANGES.txt_ file). Is 38 a typo? I can see 12 failures only. > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.27, 3.11.13 > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/d17b16c9b1bf3e325d415b3777c2a7bd24c764ce Resolution: Fixed Status: Resolved (was: Ready to Commit) Merged as [https://github.com/apache/cassandra/commit/d17b16c9b1bf3e325d415b3777c2a7bd24c764ce.] Thanks for quick review! > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Fix Version/s: 3.0.27 3.11.13 (was: 3.0.x) (was: 3.11.x) > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.27, 3.11.13 > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Test and Documentation Plan: The test has been fix and run 10 times locally. No documentation changes are required. Status: Patch Available (was: In Progress) > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494717#comment-17494717 ] Aleksei Zotov commented on CASSANDRA-17338: --- The fix seems to be working locally. Kicked of CI and raised a PR. ||Item||Link|| |PR|[https://github.com/apache/cassandra/pull/1460]| |CI|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1432/]| > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17338: -- Fix Version/s: 3.0.x > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17494711#comment-17494711 ] Aleksei Zotov commented on CASSANDRA-17338: --- I can see failures for 3.0 as well: * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/301/#showFailuresLink] * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/302/#showFailuresLink] * [https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/306/#showFailuresLink] Similarly to CASSANDRA-17386 the issue is reproducible locally and seems to be fixed in [https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79]. I'll backport necessary changes to 3.0 branch. > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17338) Fix flaky test - test_cqlsh_completion.TestCqlshCompletion
[ https://issues.apache.org/jira/browse/CASSANDRA-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov reassigned CASSANDRA-17338: - Assignee: Aleksei Zotov > Fix flaky test - test_cqlsh_completion.TestCqlshCompletion > -- > > Key: CASSANDRA-17338 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17338 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Brandon Williams >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > Failed 4 times in the last 24 runs. Flakiness: 30%, Stability: 83% > A bunch of the test_completion_* tests fail occasionally with an eyebleed > inducing mismatched output. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Fix Version/s: 3.0.27 3.11.13 (was: 3.0.x) (was: 3.11.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/63788661cb637ec0e80158dd7636d9f35256ccfd Resolution: Fixed Status: Resolved (was: Ready to Commit) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.27, 3.11.13 > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Reviewers: Brandon Williams Status: Review In Progress (was: Needs Committer) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Status: Ready to Commit (was: Review In Progress) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Fix Version/s: 3.0.x > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493701#comment-17493701 ] Aleksei Zotov commented on CASSANDRA-17386: --- Good catch! In the meantime all the builds look good: ||Item||Link|| |PR 3.11|[https://github.com/apache/cassandra/pull/1450/]| |CI 3.11|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]| |CI 3.11 CQLSH|[https://ci-cassandra.apache.org/job/Cassandra-devbranch-cqlsh-tests/1281/]| |PR 3.0|[https://github.com/apache/cassandra/pull/1451/]| |CI 3.0|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1431/]| |CI 3.0 CQLSH|[https://ci-cassandra.apache.org/job/Cassandra-devbranch-cqlsh-tests/1283/]| > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493408#comment-17493408
]
Aleksei Zotov edited comment on CASSANDRA-17386 at 2/16/22, 6:33 PM:
-
Good point [~brandon.williams]! For 4.0 and 4.x the issue has been fixed in
[this
PR|https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-4f28d77309cd96fadc18b2e74fb7a0c2c040ec6e68e551e1198eb2361c8a56a7R56].
I additionally checked 3.0 and looks like it has the same issue, however, it is
not being reported.
Here are the details:
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/consoleFull]
(latest 3.0):
{code:java}
14:42:08 Starting building: Cassandra-3.0-cqlsh-tests #305
{code}
and in
[https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/305/#showFailuresLink]
there are _TestCqlshOutput_ failures. Any idea why these failures are not
being reported as failures at
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/#showFailuresLink]?
I was able to reproduce the issue for 3.0 locally. Hence I ported the same fix
to 3.0 branch, tested locally and triggered CI.
||Item||Link||
|PR 3.11|[https://github.com/apache/cassandra/pull/1450]|
|CI
3.11|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]
(looks good)|
|PR 3.0|[https://github.com/apache/cassandra/pull/1451/]|
|CI
3.0|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1431/]
(running now)|
was (Author: azotcsit):
Good point [~brandon.williams]! For 4.0 and 4.x the issue has been fixed in
[this
PR|https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-4f28d77309cd96fadc18b2e74fb7a0c2c040ec6e68e551e1198eb2361c8a56a7R56].
I additionally checked 3.0 and looks like it has the same issue, however, it is
not being reported.
Here are the details:
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/consoleFull]
(latest 3.0):
{code:java}
14:42:08 Starting building: Cassandra-3.0-cqlsh-tests #305
{code}
and in
[https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/305/#showFailuresLink]
there are _TestCqlshOutput_ failures. Any idea why these failures are not
being reported as failures at
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/#showFailuresLink]?
I was able to reproduce the issue for 3.0 locally. Hence I ported the same fix
to 3.0 branch, tested locally and triggered CI.
||Item||Link||
|PR 3.11|[https://github.com/apache/cassandra/pull/1450]|
|CI
3.11|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]
(looks good)|
|PR 3.0|[https://github.com/apache/cassandra/pull/1451/]|
|CI
3.0|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1431/]
(running now)|
> Test failure: TestCqlshOutput failing tests
>
>
> Key: CASSANDRA-17386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17386
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x
>
>
> The following TestCqlshOutput tests are failing consistently on 3.11 and as
> far as Butler goes, since the very beginning it started collecting data so I
> am not able to say at this point what exactly broke them:
> Test_static_cf_output, test_boolean_output, test_count_output,
> test_string_output_ascii, test_null_output, test_columness_key_output,
> test_numeric_output
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493408#comment-17493408
]
Aleksei Zotov commented on CASSANDRA-17386:
---
Good point [~brandon.williams]! For 4.0 and 4.x the issue has been fixed in
[this
PR|https://github.com/apache/cassandra/commit/bf9a1d487b9ba469e8d740cf7d1cd419535a7e79#diff-4f28d77309cd96fadc18b2e74fb7a0c2c040ec6e68e551e1198eb2361c8a56a7R56].
I additionally checked 3.0 and looks like it has the same issue, however, it is
not being reported.
Here are the details:
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/consoleFull]
(latest 3.0):
{code:java}
14:42:08 Starting building: Cassandra-3.0-cqlsh-tests #305
{code}
and in
[https://ci-cassandra.apache.org/job/Cassandra-3.0-cqlsh-tests/305/#showFailuresLink]
there are _TestCqlshOutput_ failures. Any idea why these failures are not
being reported as failures at
[https://ci-cassandra.apache.org/view/Cassandra%203.0/job/Cassandra-3.0/248/#showFailuresLink]?
I was able to reproduce the issue for 3.0 locally. Hence I ported the same fix
to 3.0 branch, tested locally and triggered CI.
||Item||Link||
|PR 3.11|[https://github.com/apache/cassandra/pull/1450]|
|CI
3.11|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]
(looks good)|
|PR 3.0|[https://github.com/apache/cassandra/pull/1451/]|
|CI
3.0|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1431/]
(running now)|
> Test failure: TestCqlshOutput failing tests
>
>
> Key: CASSANDRA-17386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17386
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x
>
>
> The following TestCqlshOutput tests are failing consistently on 3.11 and as
> far as Butler goes, since the very beginning it started collecting data so I
> am not able to say at this point what exactly broke them:
> Test_static_cf_output, test_boolean_output, test_count_output,
> test_string_output_ascii, test_null_output, test_columness_key_output,
> test_numeric_output
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Status: Needs Committer (was: Patch Available) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493179#comment-17493179 ] Aleksei Zotov edited comment on CASSANDRA-17386 at 2/16/22, 6:00 PM: - Looks like I found the issue in tests configuration. CI looks good. ||Item||Link|| |PR|[https://github.com/apache/cassandra/pull/1450]| |CI|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]| [~e.dimitrova] would you mind reviewing the changes. was (Author: azotcsit): Looks like I found the issue in tests configuration. Raised a PR and triggered CI, let's wait and see. ||Item||Link|| |PR|[https://github.com/apache/cassandra/pull/1450]| |CI|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]| > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17386: -- Test and Documentation Plan: I fixed test issue. No documentation updates are required. Status: Patch Available (was: In Progress) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493179#comment-17493179 ] Aleksei Zotov edited comment on CASSANDRA-17386 at 2/16/22, 11:19 AM: -- Looks like I found the issue in tests configuration. Raised a PR and triggered CI, let's wait and see. ||Item||Link|| |PR|[https://github.com/apache/cassandra/pull/1450]| |CI|[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/]| was (Author: azotcsit): Looks like I found the issue in tests configuration. Raised a PR and triggered CI, let's wait and see. ||Item||Link|| |PR|https://github.com/apache/cassandra/pull/1450| |CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/| > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493179#comment-17493179 ] Aleksei Zotov commented on CASSANDRA-17386: --- Looks like I found the issue in tests configuration. Raised a PR and triggered CI, let's wait and see. ||Item||Link|| |PR|https://github.com/apache/cassandra/pull/1450| |CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1429/| > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov reassigned CASSANDRA-17386: - Assignee: Aleksei Zotov > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17493057#comment-17493057 ] Aleksei Zotov commented on CASSANDRA-17386: --- Thanks [~e.dimitrova]! I'm trying to find out the root cause for the second day and I'm not even close :D I'm fighting with my local environment in order to run these tests and get the same failures as we have in Jenkins... The only thing I can say so far is that tests do not work with 2.7.18 because of [https://github.com/pypa/pip/commit/ca832b2836e0bffa7cf95589acdcd71230f5834e#diff-e58ec0adb9172e63c4f31031fb5a5b364fe9471e332bff30114233a002ee9d1eR142.] In order to run smth the tests you need Python <= 2.7.17. I feel at some point our CI may break because of this (I hope no-one will update Python to the latest version). I'll keep this ticket updated with the results of my research. > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17382) Flaky Test - LongLeveledCompactionStrategyCQLTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17382:
--
Component/s: Test/unit
> Flaky Test - LongLeveledCompactionStrategyCQLTest
> --
>
> Key: CASSANDRA-17382
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17382
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS, Test/unit
>Reporter: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x
>
>
> The test fails on 3.11 with such an issue:
> {code}
> ERROR [CompactionExecutor:2] 2022-02-07 13:29:52,856 CQLTester.java:184 -
> Fatal exception in thread Thread[CompactionExecutor:2,1,main]
> java.lang.AssertionError: Got unexpected overlap in level 2 at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:159)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:132)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:351)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:216)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:393)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:356)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:579)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTablesChanged(Tracker.java:429)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doCommit(LifecycleTransaction.java:234)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.commit(Transactional.java:113)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doCommit(SSTableRewriter.java:207)
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/316/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/318/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17382) Flaky Test - LongLeveledCompactionStrategyCQLTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17382:
--
Fix Version/s: 3.11.x
> Flaky Test - LongLeveledCompactionStrategyCQLTest
> --
>
> Key: CASSANDRA-17382
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17382
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x
>
>
> The test fails on 3.11 with such an issue:
> {code}
> ERROR [CompactionExecutor:2] 2022-02-07 13:29:52,856 CQLTester.java:184 -
> Fatal exception in thread Thread[CompactionExecutor:2,1,main]
> java.lang.AssertionError: Got unexpected overlap in level 2 at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:159)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:132)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:351)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:216)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:393)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:356)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:579)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTablesChanged(Tracker.java:429)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doCommit(LifecycleTransaction.java:234)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.commit(Transactional.java:113)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doCommit(SSTableRewriter.java:207)
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/316/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/318/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17382) Flaky Test - LongLeveledCompactionStrategyCQLTest
Aleksei Zotov created CASSANDRA-17382:
-
Summary: Flaky Test - LongLeveledCompactionStrategyCQLTest
Key: CASSANDRA-17382
URL: https://issues.apache.org/jira/browse/CASSANDRA-17382
Project: Cassandra
Issue Type: Bug
Components: Local/Compaction/LCS
Reporter: Aleksei Zotov
The test fails on 3.11 with such an issue:
{code}
ERROR [CompactionExecutor:2] 2022-02-07 13:29:52,856 CQLTester.java:184 - Fatal
exception in thread Thread[CompactionExecutor:2,1,main]
java.lang.AssertionError: Got unexpected overlap in level 2 at
org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:159)
at
org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:132)
at
org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:351)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:216)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:393)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:356)
at
org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:579)
at
org.apache.cassandra.db.lifecycle.Tracker.notifySSTablesChanged(Tracker.java:429)
at
org.apache.cassandra.db.lifecycle.LifecycleTransaction.doCommit(LifecycleTransaction.java:234)
at
org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.commit(Transactional.java:113)
at
org.apache.cassandra.io.sstable.SSTableRewriter.doCommit(SSTableRewriter.java:207)
{code}
[https://ci-cassandra.apache.org/job/Cassandra-3.11/316/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
[https://ci-cassandra.apache.org/job/Cassandra-3.11/318/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17366) Fix flaky test - upgrade_tests.gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17366:
--
Workflow: Copy of Cassandra Bug Workflow (was: Copy of Cassandra Default
Workflow)
Issue Type: Bug (was: Task)
> Fix flaky test - upgrade_tests.gossip_test.TestGossip
> -
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
>Reporter: Aleksei Zotov
>Priority: Normal
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17366) Fix flaky test - upgrade_tests.gossip_test.TestGossip
Aleksei Zotov created CASSANDRA-17366:
-
Summary: Fix flaky test - upgrade_tests.gossip_test.TestGossip
Key: CASSANDRA-17366
URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
Project: Cassandra
Issue Type: Task
Reporter: Aleksei Zotov
We can see many failures for 4.x branch:
test_2dc_parallel_startup_one_seed
([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
[920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
test_2dc_parallel_startup
([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
[931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
[936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
test_2dc_parallel_startup_one_seed
([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
[920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
The error is always the same:
{code:java}
Unexpected error found in node logs (see stdout for full details). Errors:
[ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
encountered during startup
java.lang.RuntimeException: Didn't receive schemas for all known versions
within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
at
org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
at
org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
encountered during startup
java.lang.RuntimeException: Didn't receive schemas for all known versions
within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
at
org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
at
org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
at
org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
at
org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
at
org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489386#comment-17489386 ] Aleksei Zotov commented on CASSANDRA-16677: --- Also I can see that [https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/org.apache.cassandra.net/ConnectionTest/testTimeout/] failed once for trunk. However, the error message is pretty much the same, so linking to this ticket as well. > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489383#comment-17489383 ] Aleksei Zotov commented on CASSANDRA-16677: --- I can see it failed again for [935|https://ci-cassandra.apache.org/job/Cassandra-trunk/935/testReport/org.apache.cassandra.net/ConnectionTest] and [937|https://ci-cassandra.apache.org/job/Cassandra-trunk/937/testReport/org.apache.cassandra.net/ConnectionTest/] builds. I linked this ticket to the failure Butler. Attaching the full log for 937 build (in case someone may want to check that in the future): [^TEST-org.apache.cassandra.net.ConnectionTest.log.xz] > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16677) Fix flaky ConnectionTest
[ https://issues.apache.org/jira/browse/CASSANDRA-16677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-16677: -- Attachment: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > Fix flaky ConnectionTest > > > Key: CASSANDRA-16677 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16677 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Internode >Reporter: Brandon Williams >Priority: Normal > Fix For: 4.0.x > > Attachments: TEST-org.apache.cassandra.net.ConnectionTest.log.xz > > > https://ci-cassandra.apache.org/job/Cassandra-devbranch/785/testReport/junit/org.apache.cassandra.net/ConnectionTest/testMessageDeliveryOnReconnect_compression/ > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/cf7dcec6-612c-45d1-8471-623bde481dca/jobs/4069 > https://app.circleci.com/pipelines/github/adelapena/cassandra/460/workflows/b750cd38-0263-4b5e-9bb8-a8be98214378/jobs/4065 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17244) Fix org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
[ https://issues.apache.org/jira/browse/CASSANDRA-17244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489375#comment-17489375 ] Aleksei Zotov commented on CASSANDRA-17244: --- I linked the failed tests in Butler with this ticket. Here is the detailed log from 935 build: https://ci-cassandra.apache.org/job/Cassandra-trunk-jvm-dtest/1072/jdk=jdk_11_latest,label=cassandra,split=1/consoleFull > Fix > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > -- > > Key: CASSANDRA-17244 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17244 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition > failed > [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1354/testReport/junit/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/] > I didn't find any other occurrences but seems to me legit failure. > CC [~dcapwell] as I think you were working on those and probably you will > make better assessment than me. :) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17244) Fix org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
[
https://issues.apache.org/jira/browse/CASSANDRA-17244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489243#comment-17489243
]
Aleksei Zotov commented on CASSANDRA-17244:
---
It failed in
[928|https://ci-cassandra.apache.org/job/Cassandra-trunk/928/testReport/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest]
and
[935|https://ci-cassandra.apache.org/job/Cassandra-trunk/935/testReport/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/]
builds.
{code:java}
java.lang.NullPointerException
at
com.google.common.collect.Iterables.getOnlyElement(Iterables.java:254)
at
org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThreshold(TombstoneCountWarningTest.java:273)
at
org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition(TombstoneCountWarningTest.java:186)
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}
Looks like sometimes warnings can be unexpectedly empty. I'm not really
familiar with all these classes and test utilities, however, I have a guess
that it somehow maybe related to the fact which node really acts as a
coordinator for
{code:java}
QueryProcessor.execute(cql, org.apache.cassandra.db.ConsistencyLevel.ALL,
QueryState.forInternalCalls()); {code}
command. With that idea in mind, I feel we may need to introduce
CoordinatorWarning init/done/reset logic as it was done in
[https://github.com/apache/cassandra/pull/1180/files#diff-e14e42b9f28baf531cfe0fd4d79794617959d63e26e03bed54e0e1636e55d890R200.]
But this is a pure speculation because I do not really understand the whole
logic :) I hope [~dcapwell] can comment on this.
If it does not seem to be the right direction I'd postpone working on this
ticket because I have a bunch of other test failures on Jenkins to take a look
to.
> Fix
> org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
> --
>
> Key: CASSANDRA-17244
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17244
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> org.apache.cassandra.distributed.test.trackwarnings.TombstoneCountWarningTest.failThresholdSinglePartition
> failed
> [here|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1354/testReport/junit/org.apache.cassandra.distributed.test.trackwarnings/TombstoneCountWarningTest/failThresholdSinglePartition/]
> I didn't find any other occurrences but seems to me legit failure.
> CC [~dcapwell] as I think you were working on those and probably you will
> make better assessment than me. :)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17078) Fix failing test: SSTableReaderTest.testPersistentStatistics
[
https://issues.apache.org/jira/browse/CASSANDRA-17078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488252#comment-17488252
]
Aleksei Zotov commented on CASSANDRA-17078:
---
The changes LGTM, +1
Should we backport them to 4.0 and 3.x branches?
> Fix failing test: SSTableReaderTest.testPersistentStatistics
>
>
> Key: CASSANDRA-17078
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17078
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> JDK8 unit test failure
> See it on CircleCI but not on Jenkins ASF infra right now.
> {code:java}
> java.lang.RuntimeException: Failed importing sstables
> at
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:164)
> at
> org.apache.cassandra.db.ColumnFamilyStore.loadNewSSTables(ColumnFamilyStore.java:734)
> at
> org.apache.cassandra.io.sstable.SSTableReaderTest.clearAndLoad(SSTableReaderTest.java:222)
> at
> org.apache.cassandra.io.sstable.SSTableReaderTest.testPersistentStatistics(SSTableReaderTest.java:215)
> Caused by: java.lang.RuntimeException: Failed to rename
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
> to
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
> at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:385)
> at org.apache.cassandra.io.util.File.move(File.java:227)
> at
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:704)
> at
> org.apache.cassandra.io.util.FileUtils.renameWithConfirm(FileUtils.java:698)
> at
> org.apache.cassandra.io.sstable.format.SSTableWriter.rename(SSTableWriter.java:337)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.moveAndOpenSSTable(SSTableReader.java:2339)
> at
> org.apache.cassandra.db.SSTableImporter.importNewSSTables(SSTableImporter.java:139)
> Caused by: java.nio.file.NoSuchFileException:
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-9-big-Digest.crc32
> ->
> /tmp/cassandra/build/test/cassandra/data/SSTableReaderTest/Standard1-da581e50380611ecaad41173773221f9/nb-13-big-Digest.crc32
> at
> sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
> at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> at sun.nio.fs.UnixCopyFile.move(UnixCopyFile.java:396)
> at
> sun.nio.fs.UnixFileSystemProvider.move(UnixFileSystemProvider.java:262)
> at java.nio.file.Files.move(Files.java:1395)
> at
> org.apache.cassandra.io.util.PathUtils.atomicMoveWithFallback(PathUtils.java:396)
> at org.apache.cassandra.io.util.PathUtils.rename(PathUtils.java:377)
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17062) Expose Auth Caches metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481851#comment-17481851
]
Aleksei Zotov edited comment on CASSANDRA-17062 at 1/25/22, 2:16 PM:
-
Thanks for the feedback [~samt]!
{quote}I don't see any harm in the all cache metrics including a
{{{}weightedSize{}}}, for unweighted caches this is just equal to {{size}} and
simply isn't included in the VT/nodetool output.
{quote}
I think MBeans are also a part of the presentation layer (not only VT and
nodetool) since they are exposed to end users. I find "conditional MBean
attributes" (meaning they can be populated conditionally or treated
differently) to be very confusing. So I think having different entities for
different MBeans ({{{}CacheMetrics{}}} and {{{}UnweightedCacheMetrics{}}}) is
smth clearer to the end user. WDYT?
I've intentionally not brought {{{}CacheSize{}}}/{{{}UnweightedCacheSize{}}}
into this discussion. Let's come to a consensus on Mbeans at first.
{quote}The only real difference between the types at this level is the units of
size/capacity, which are not explicit and only referenced in comments.
{quote}
Ideally I'd make a bigger refactoring with more expressive naming, etc, but I
do not feel it is justifiable to make a bigger change for such a simple ticket.
Especially I'm concerned with renaming old classes (possible conflicts
resolution going further) while keeping MBeans compatible (which is possible
though).
{quote}As implemented, the mechanism of tracking hits/misses isn't correct.
{quote}
Great catch! I was referencing to the logic implemented in
{{{}InstrumentingCache{}}}. However, it turned out that it uses uses
{{getIfPresent}} instead of {{get}} method, so does not experience the problem
you described. Your fix seems to be necessary and correct!
was (Author: azotcsit):
Thanks for the feedback [~samt]!
> I don't see any harm in the all cache metrics including a
> {{{}weightedSize{}}}, for unweighted caches this is just equal to {{size}}
> and simply isn't included in the VT/nodetool output.
I think MBeans are also a part of the presentation layer (not only VT and
nodetool) since they are exposed to end users. I find "conditional MBean
attributes" (meaning they can be populated conditionally or treated
differently) to be very confusing. So I think having different entities for
different MBeans (`CacheMetrics` and `UnweightedCacheMetrics`) is smth clearer
to the end user. WDYT?
I've intentionally not brought `CacheSize`/`UnweightedCacheSize` into this
discussion. Let's come to a consensus on Mbeans at first.
> The only real difference between the types at this level is the units of
> size/capacity, which are not explicit and only referenced in comments.
Ideally I'd make a bigger refactoring with more expressive naming, etc, but I
do not feel it is justifiable to make a bigger change for such a simple ticket.
Especially I'm concerned with renaming old classes (possible conflicts
resolution going further) while keeping MBeans compatible (which is possible
though).
> As implemented, the mechanism of tracking hits/misses isn't correct.
Great catch! I was referencing to the logic implemented in
`InstrumentingCache`. However, it turned out that it uses uses `getIfPresent`
instead of `get` method, so does not experience the problem you described. Your
fix seems to be necessary and correct!
> Expose Auth Caches metrics
> --
>
> Key: CASSANDRA-17062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17062
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics,
> Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Unlike to other caches (row, key, counter), Auth Caches lack some monitoring
> capabilities. Here are a few particular changes to get this inequity fixed:
> # Add auth caches to _system_views.caches_ VT
> # Expose auth caches metrics via JMX
> # Add auth caches details to _nodetool info_
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17062) Expose Auth Caches metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17481851#comment-17481851
]
Aleksei Zotov commented on CASSANDRA-17062:
---
Thanks for the feedback [~samt]!
> I don't see any harm in the all cache metrics including a
> {{{}weightedSize{}}}, for unweighted caches this is just equal to {{size}}
> and simply isn't included in the VT/nodetool output.
I think MBeans are also a part of the presentation layer (not only VT and
nodetool) since they are exposed to end users. I find "conditional MBean
attributes" (meaning they can be populated conditionally or treated
differently) to be very confusing. So I think having different entities for
different MBeans (`CacheMetrics` and `UnweightedCacheMetrics`) is smth clearer
to the end user. WDYT?
I've intentionally not brought `CacheSize`/`UnweightedCacheSize` into this
discussion. Let's come to a consensus on Mbeans at first.
> The only real difference between the types at this level is the units of
> size/capacity, which are not explicit and only referenced in comments.
Ideally I'd make a bigger refactoring with more expressive naming, etc, but I
do not feel it is justifiable to make a bigger change for such a simple ticket.
Especially I'm concerned with renaming old classes (possible conflicts
resolution going further) while keeping MBeans compatible (which is possible
though).
> As implemented, the mechanism of tracking hits/misses isn't correct.
Great catch! I was referencing to the logic implemented in
`InstrumentingCache`. However, it turned out that it uses uses `getIfPresent`
instead of `get` method, so does not experience the problem you described. Your
fix seems to be necessary and correct!
> Expose Auth Caches metrics
> --
>
> Key: CASSANDRA-17062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17062
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics,
> Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Unlike to other caches (row, key, counter), Auth Caches lack some monitoring
> capabilities. Here are a few particular changes to get this inequity fixed:
> # Add auth caches to _system_views.caches_ VT
> # Expose auth caches metrics via JMX
> # Add auth caches details to _nodetool info_
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/bc20bddcebd6a37b14cfbdd50c359be4c9743f73
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.1
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17471512#comment-17471512
]
Aleksei Zotov commented on CASSANDRA-17063:
---
Thanks [~jmckenzie]! I addressed the nits and updated {_}CHANGES.txt{_}.
I triggered CI for the updated version:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1355/].
If the tests pass, I'll merge the PR tomorrow.
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17062: -- Test and Documentation Plan: The changes include new unit tests and documentation updates. Status: Patch Available (was: In Progress) > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464319#comment-17464319 ] Aleksei Zotov commented on CASSANDRA-17062: --- CI build: [https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1331/] The failures do not seem to be related to this change. > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464097#comment-17464097
]
Aleksei Zotov commented on CASSANDRA-16630:
---
[~e.dimitrova] [~brandon.williams]
Thanks for your input! Looks like we cannot get rid of "perTest" mode. We rely
on _timeout_ functionality which is tied to a JVM instance. In order to keep it
working as previously we'll need either to re-write _build.xml_ in the way it
always use a separate element for every test suite (i.e. emulate
"perTest" mode) or to natively support it in _junitlauncher_ task. I raised
[https://github.com/apache/ant/pull/174] with adding such a logic to ant.
Also I raised [https://github.com/apache/ant/pull/171] to support "useFile"
functionality. However, I found a workaround, so this one is not a blocker for
us.
I sent a message to ant-dev mail list, let's see what they respond.
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Status: Needs Committer (was: Patch Available)
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Description:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecconfig_ and _nodetool
getauthcachecconfig_ commands.
Also we could think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
was:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
getauthcachecconfig_ commands.
Also we could think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Test and Documentation Plan: The new nodetool commands are covered with
tests. Documentation does not require changes.
Status: Patch Available (was: In Progress)
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17464060#comment-17464060
]
Aleksei Zotov commented on CASSANDRA-17063:
---
Here is a link to CI:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1330/]
The failed tests do not seem to be related to the current changes.
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Description:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
getauthcachecconfig_ commands.
Also we could think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
was:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecapacity_ command.
Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecconfig_ and __ _nodetool
> getauthcachecconfig_ commands.
> Also we could think of some VT-based alternative to {_}nodetool{_}. But I
> feel there is no need to have a separate table for Auth Caches configs. It
> would be an overhead. Ideally we need to have a separate VT that shows/sets
> all the configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17062) Expose Auth Caches metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463799#comment-17463799
]
Aleksei Zotov commented on CASSANDRA-17062:
---
[~samt]
I made the changes. Could you, please, check the PR and let me know your
thoughts.
Summary:
* created new interfaces for unweighted caches
* kept existing naming for weighted caches, however added corresponding
javadocs
* created _UnweightedCache_ metric type
* updated {{nodetool info}} output
* created _unweighted_caches_ VT
* updated documentation
cc: [~blerer]
> Expose Auth Caches metrics
> --
>
> Key: CASSANDRA-17062
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17062
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics,
> Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Unlike to other caches (row, key, counter), Auth Caches lack some monitoring
> capabilities. Here are a few particular changes to get this inequity fixed:
> # Add auth caches to _system_views.caches_ VT
> # Expose auth caches metrics via JMX
> # Add auth caches details to _nodetool info_
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17185) Contrilbulyze: Generate contributors reports based on git history
[ https://issues.apache.org/jira/browse/CASSANDRA-17185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453660#comment-17453660 ] Aleksei Zotov commented on CASSANDRA-17185: --- +1 > Contrilbulyze: Generate contributors reports based on git history > - > > Key: CASSANDRA-17185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17185 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > > Create metrics providing top lists of contributors for different time > periods. Listing patches, reviews, and who has worked with who. > Intention is to give insight into the people who are > contributing code to the project. > https://nightlies.apache.org/cassandra/devbranch/misc/contribulyze/html/ > It's generated from the contribulyze.py script (copied and evolved from the > Subversion project) running against our repositories, taking advantage of > our community's commit message style. > dev@ ML: https://lists.apache.org/thread/48wgvo5mstoy3ozyqj45s293ddpf86pr > PR: https://github.com/apache/cassandra-builds/pull/54 -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447981#comment-17447981
]
Aleksei Zotov commented on CASSANDRA-16630:
---
Thanks [~e.dimitrova]!
A small notice on _cql_ targets:
Aleksei:
{quote}Now here is a question on the matter. I can see that cql-test-some and
cql-test targets (unlikely to the other) use junit instead of junit-timeout
(which has a support of jstack on timeout).
{quote}
Mick:
{quote}I don't know of any usages of either. At least not in either CircleCI or
ci-cassandra.a.o
In trunk I am in favour of removing them both.
{quote}
In the meantime I double checked the source of _cql-test_ and _cql-test-some_
targets. They were introduced as a part of CASSANDRA-7248. Looks like that was
done just for convenience and it probably made sense then. Now these target do
not seem to be useful, so I'm going to remove them.
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444372#comment-17444372
]
Aleksei Zotov edited comment on CASSANDRA-16630 at 11/23/21, 12:16 PM:
---
[~e.dimitrova]
I'd like to share an update on the current progress. I got a working prototype
with JUnit 5 ([https://github.com/apache/cassandra/pull/1337]; whatever exists
in "junitlauncher2" package will be updated in ant project and removed from the
PR). It is still pending full blown validation, but I was able to run one test
:)
Looks like currently _ant-junitlauncher_ (ant JUnit5 implementation) misses
many features available in {_}ant-junit{_}. That's why I raised two more PRs
to the ant project:
* [https://github.com/apache/ant/pull/168] (completed)
* [https://github.com/apache/ant/pull/169] (it is a draft version since I need
to validate that all use cases are handled before passing it for review)
With that being said, I do not believe we can get all this work done soon
because of dependencies to another project. JFYI.
Now regarding the validation I've done so far. I was able to check xml
formatter only. Here is the list of differences I still have in the output
(compared old and new implementation):
1. Different way of closing of "testcase" tag:
{code:java}
{code}
{code:java}
{code}
It not an issue since the format is still valid.
2. "errors" attribute in "testsuite" tag was renamed to "aborted":
{code:java}
{code}
{code:java}
{code}
Theoretically it can be fixed, but I do not think it is required.
3. New line escape character got changed from " " to "":
{code:java}
{code}
{code:java}
{code}
In fact it is related to the internal implementation changes of DOM and Stax
XML parsers. I did not dig really deep since it does not seem to be a problem
at all.
4. "failure" tag body now contains non-filtered stacktrace:
{code:java}
junit.framework.AssertionFailedError:
Expected failure
at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:37)
{code}
{code:java}
java.lang.AssertionError: Expected failure
at org.junit.Assert.fail(Assert.java:89) at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
org.junit.runner.JUnitCore.run(JUnitCore.java:115) at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116) at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447538#comment-17447538
]
Aleksei Zotov commented on CASSANDRA-16630:
---
[~mck] [~e.dimitrova]
I made testing for "brief" formatter too. Their formats are a bit different as
well:
# "Testsuite" vs "Testcase" spelling
# Slightly different way of printing stats
# Non-truncated stack trace (as I mentioned previously for "xml" formatter)
# Different order of printing stderr/stdout (before/after test summary)
Before (JUnit 4):
{code:java}
[junit-timeout] Testsuite: org.apache.cassandra.Junit4SampleTest-mytag
[junit-timeout] Testsuite: org.apache.cassandra.Junit4SampleTest-mytag Tests
run: 2, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.128 sec
[junit-timeout]
[junit-timeout] - Standard Output ---
[junit-timeout] CUSTOM StdOut
[junit-timeout] - ---
[junit-timeout] - Standard Error -
[junit-timeout] CUSTOM StdErr
[junit-timeout] - ---
[junit-timeout] Testcase:
testFailure(org.apache.cassandra.Junit4SampleTest)-mytag: FAILED
[junit-timeout] Expected failure
[junit-timeout] junit.framework.AssertionFailedError: Expected failure
[junit-timeout] at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:39)
[junit-timeout]
[junit-timeout]
[junit-timeout] Test org.apache.cassandra.Junit4SampleTest FAILED {code}
Before (JUnit 5):
{code:java}
[junitlauncher] Running org.apache.cassandra.Junit4SampleTest
[junitlauncher] Testcase: org.apache.cassandra.Junit4SampleTest-mytag
[junitlauncher] Test: testFailure-mytag took 10 milli sec(s) FAILED: Expected
failure
[junitlauncher] java.lang.AssertionError: Expected failure
[junitlauncher] at org.junit.Assert.fail(Assert.java:89)
[junitlauncher] at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:39)
[junitlauncher] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[junitlauncher] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junitlauncher] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junitlauncher] at java.lang.reflect.Method.invoke(Method.java:498)
[junitlauncher] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
[junitlauncher] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
[junitlauncher] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
[junitlauncher] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
[junitlauncher] at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
[junitlauncher] at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
[junitlauncher] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
[junitlauncher] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
[junitlauncher] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
[junitlauncher] at
org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
[junitlauncher] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
[junitlauncher] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
[junitlauncher] at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
[junitlauncher] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
[junitlauncher] at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
[junitlauncher] at
org.junit.runners.ParentRunner.run(ParentRunner.java:413)
[junitlauncher] at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
[junitlauncher] at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
[junitlauncher] at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
[junitlauncher] at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
[junitlauncher] at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
[junitlauncher] at
java.util.Iterator.forEachRemaining(Iterator.java:116)
[junitlauncher] at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
[junitlauncher] at
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
[junitlauncher] at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
[junitlauncher] at
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447534#comment-17447534
]
Aleksei Zotov commented on CASSANDRA-16630:
---
[~mck]
Done, thanks for noticing and your help!
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447392#comment-17447392
]
Aleksei Zotov commented on CASSANDRA-16630:
---
[~bereng]
Thanks for noticing this, I removed the branch, my bad!
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447389#comment-17447389 ] Aleksei Zotov commented on CASSANDRA-17062: --- [~bereng] Thanks for noticing this, I removed the branch, my bad! > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444372#comment-17444372
]
Aleksei Zotov commented on CASSANDRA-16630:
---
[~e.dimitrova]
I'd like to share an update on the current progress. I got a working prototype
with JUnit 5 ([https://github.com/apache/cassandra/pull/1322/]; whatever exists
in "junitlauncher2" package will be updated in ant project and removed from the
PR). It is still pending full blown validation, but I was able to run one test
:)
Looks like currently _ant-junitlauncher_ (ant JUnit5 implementation) misses
many features available in {_}ant-junit{_}. That's why I raised two more PRs
to the ant project:
* [https://github.com/apache/ant/pull/168] (completed)
* [https://github.com/apache/ant/pull/169] (it is a draft version since I need
to validate that all use cases are handled before passing it for review)
With that being said, I do not believe we can get all this work done soon
because of dependencies to another project. JFYI.
Now regarding the validation I've done so far. I was able to check xml
formatter only. Here is the list of differences I still have in the output
(compared old and new implementation):
1. Different way of closing of "testcase" tag:
{code:java}
{code}
{code:java}
{code}
It not an issue since the format is still valid.
2. "errors" attribute in "testsuite" tag was renamed to "aborted":
{code:java}
{code}
{code:java}
{code}
Theoretically it can be fixed, but I do not think it is required.
3. New line escape character got changed from "" to "#xa;":
{code:java}
{code}
{code:java}
{code}
In fact it is related to the internal implementation changes of DOM and Stax
XML parsers. I did not dig really deep since it does not seem to be a problem
at all.
4. "failure" tag body now contains non-filtered stacktrace:
{code:java}
junit.framework.AssertionFailedError:
Expected failure
at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:37)
{code}
{code:java}
java.lang.AssertionError: Expected failure
at org.junit.Assert.fail(Assert.java:89) at
org.apache.cassandra.Junit4SampleTest.testFailure(Junit4SampleTest.java:39)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498) at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at
org.junit.runners.ParentRunner.run(ParentRunner.java:413) at
org.junit.runner.JUnitCore.run(JUnitCore.java:137) at
org.junit.runner.JUnitCore.run(JUnitCore.java:115) at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116) at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
[jira] [Commented] (CASSANDRA-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443143#comment-17443143 ] Aleksei Zotov commented on CASSANDRA-17062: --- [~samt] [~blerer] I've started working on this and mentioned a discrepancy between non-auth (key, row, counter, chunk) and auth caches. The non-auth caches are weighted (they do care about weight of a single entry) whereas the auth caches are non-weighted. Particularly it affects _Capacity_ and _Size_ attributes of the MBeans. For weighted caches they represent size of entries in bytes, for non-weighted caches they represent number of entries. Current changes do not particularly handle this logical discrepancy (the only thing I've done is renaming of capacity_bytes -> capacity and size_bytes -> size in the corresponding VT). What can be actually done to make the logic a bit clearer: # Introduce "weighted" column to the VT and add corresponding notes to the documentation on how to treat capacity and size for weighted/non-weighted caches. But we can mention that without having the new column. # Make auth caches weighted. I feel it would make things even worse because it is not really required from logical standpoint (and it would be hard to precisely calculate used memory for auth caches). # Completely separate metrics for weighted and non-weighted caches. It is opposite to unification I supposed to achieve by this ticket. However, it should make things clear and precise. Please, share your thoughts (maybe you have other ideas). I linked a draft PR for your reference. > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Summary: Make capacity/validity/updateinterval/activeupdate for Auth Caches
configurable via nodetool (was: Make
capacity/validity/updateinterval/active_update for Auth Caches configurable via
nodetool)
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/active_update) exposed via JMX or yaml
> only. We need to introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
> there is no need to have a separate table for Auth Caches configs. It would
> be an overhead. Ideally we need to have a separate VT that shows/sets all the
> configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/activeupdate for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Description:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecapacity_ command.
Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
was:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/active_update) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecapacity_ command.
Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
> Make capacity/validity/updateinterval/activeupdate for Auth Caches
> configurable via nodetool
>
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/activeupdate) exposed via JMX or yaml only.
> We need to introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
> there is no need to have a separate table for Auth Caches configs. It would
> be an overhead. Ideally we need to have a separate VT that shows/sets all the
> configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17063) Make capacity/validity/updateinterval/active_update for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441571#comment-17441571
]
Aleksei Zotov commented on CASSANDRA-17063:
---
Added "active_update" introduced by CASSANDRA-16957 to the scope if this ticket.
> Make capacity/validity/updateinterval/active_update for Auth Caches
> configurable via nodetool
> -
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/active_update) exposed via JMX or yaml
> only. We need to introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
> there is no need to have a separate table for Auth Caches configs. It would
> be an overhead. Ideally we need to have a separate VT that shows/sets all the
> configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/active_update for Auth Caches configurable via nodetool
[
https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17063:
--
Description:
Currently Auth Caches configuration options
(capacity/validity/updateinterval/active_update) exposed via JMX or yaml only.
We need to introduce a _nodetool setauthcachecapacity_ command.
Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
there is no need to have a separate table for Auth Caches configs. It would be
an overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
was:
Currently Auth Caches configuration options (capacity/validity/updateinterval)
exposed via JMX or yaml only. We need to introduce a _nodetool
setauthcachecapacity_ command.
Also we can think of some VT-based alternative to _nodetool_. But I feel there
is no need to have a separate table for Auth Caches configs. It would be an
overhead. Ideally we need to have a separate VT that shows/sets all the
configs, but it is out of the scope.
> Make capacity/validity/updateinterval/active_update for Auth Caches
> configurable via nodetool
> -
>
> Key: CASSANDRA-17063
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17063
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently Auth Caches configuration options
> (capacity/validity/updateinterval/active_update) exposed via JMX or yaml
> only. We need to introduce a _nodetool setauthcachecapacity_ command.
> Also we can think of some VT-based alternative to {_}nodetool{_}. But I feel
> there is no need to have a separate table for Auth Caches configs. It would
> be an overhead. Ideally we need to have a separate VT that shows/sets all the
> configs, but it is out of the scope.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17063) Make capacity/validity/updateinterval/active_update for Auth Caches configurable via nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17063: -- Summary: Make capacity/validity/updateinterval/active_update for Auth Caches configurable via nodetool (was: Make capacity/validity/updateinterval for Auth Caches configurable via nodetool) > Make capacity/validity/updateinterval/active_update for Auth Caches > configurable via nodetool > - > > Key: CASSANDRA-17063 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Currently Auth Caches configuration options > (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to > introduce a _nodetool setauthcachecapacity_ command. > Also we can think of some VT-based alternative to _nodetool_. But I feel > there is no need to have a separate table for Auth Caches configs. It would > be an overhead. Ideally we need to have a separate VT that shows/sets all the > configs, but it is out of the scope. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16914:
--
Fix Version/s: 4.1
(was: 4.x)
Source Control Link:
https://github.com/apache/cassandra/commit/63292292b8dbe3bb4f691f82823dcdc0172d2291
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441569#comment-17441569
]
Aleksei Zotov commented on CASSANDRA-16914:
---
Committed. Thanks [~samt] and [~blerer]!
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16914:
--
Status: Ready to Commit (was: Review In Progress)
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441547#comment-17441547
]
Aleksei Zotov commented on CASSANDRA-16914:
---
The latest CI:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1271/].
The failure are not related to the code changes and almost exactly match the
latest trunk build: [https://ci-cassandra.apache.org/job/Cassandra-trunk/815/].
I'll commit soon.
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16630) Migrate to JUnit5
[
https://issues.apache.org/jira/browse/CASSANDRA-16630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440417#comment-17440417
]
Aleksei Zotov commented on CASSANDRA-16630:
---
Hi [~e.dimitrova],
Quick summary on the current state:
* I agree with Benedict that migrating existing tests makes no much sense (it
is complicated and tiresome process that leads to conflicts). The plan for this
ticket is just to support JUnit5 for tests without any tests migration.
* There were two important concepts missing in ant's Junit5 support: ability
to create own wrapper (I fixed it in
[https://github.com/apache/ant/pull/147|https://github.com/apache/ant/pull/147)])
and fork modes support. In
[junit|https://ant.apache.org/manual/Tasks/junit.html] task there was possible
to configure different fork modes: perTest, perBatch and once whereas
[junitlauncher|https://ant.apache.org/manual/Tasks/junitlauncher.html] supports
once mode only (see
[this|https://stackoverflow.com/questions/63294995/running-junit-tests-and-forking-the-jvm-correctly-ant]).
I was going to implement such a support in ant but it turned out to be
complicated since they do not even have proper test coverage.
* I parked the activity at this stage assuming that the migration would be
easier after having Maven/Gradle in place.
* Anyway, I feel it is still possible (I have an idea on a workaround) to
achieve Junit5 with ant.
As far as I understand it is a blocker for Java 17, so let me give a try with
ant. Is there any particular reason why some tests require "perTest" mode? I
believe it just helps to prevent any issues with shared state (configs,
statics, system properties, etc).
> Migrate to JUnit5
> -
>
> Key: CASSANDRA-16630
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16630
> Project: Cassandra
> Issue Type: Improvement
> Components: Test/unit
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
>
> h3. Overview
> Currently C* uses JUnit4 (version 4.12) which is obsolete. There is a newer
> version 4.13.2 which we could update to. However, JUnit4 is generally
> considered to be outdated and it is reasonable to migrate to JUnit5.
> Despite of having a syntax sugar in JUnit5 (assertThrow, lamda's support,
> ect), there are no blockers that push us to move from JUnit4. The main
> motivation for this initiative is rule of thumb to use up-to-date versions of
> the dependencies.
> Obviously this change is not backward compatible with the open PRs and
> previous C* versions. Therefore, it will require an additional effort for
> backporting the changes and updating PRs that have tests. However, I believe
> it should not be a blocker for this initiative.
> h3. Scope (preliminary list)
> # change JUnit4 to JUnit5 dependencies and make necessary changes in ant
> tasks (https://ant.apache.org/manual/Tasks/junitlauncher.html)
> # update syntax in all tests (imports, Before/After annotations, etc)
> # update parameterized tests
> # create a new version of {{OrderedJUnit4ClassRunner}} and update
> corresponding tests
> # update tests that use {{BMUnitRunner}} (as per
> https://developer.jboss.org/docs/DOC-52953 it supports JUnit5)
> # update tests with {{@Rule}}
> # update tests with expected exceptions
> # update {{JStackJUnitTask}}
> # update formatters
> # create a separate ticket to migrate to {{ant-junitlauncher-1.10.11}} (once
> it is released) and simplify {{JStackJUnitTask}} after
> https://github.com/apache/ant/pull/147
> h3. Order of operations
> In order to make the transition more smooth we want to use a phased approach:
> # migrate to JUnit5 with [Vintage
> Engine|https://junit.org/junit5/docs/current/user-guide/#dependency-metadata-junit-vintage],
> so all JUnit4 tests work as is
> # update tests in a few bunches (to not have a huge single PR with numerous
> conflicts)
> # disable (remove dependency) Vintage Engine, so only JUnit5 tests work
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17434530#comment-17434530
]
Aleksei Zotov commented on CASSANDRA-16902:
---
The updated patch LGTM, +1.
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-17063) Make capacity/validity/updateinterval for Auth Caches configurable via nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433613#comment-17433613 ] Aleksei Zotov commented on CASSANDRA-17063: --- Great, thanks [~blerer]! That's exactly what I was looking for. > Make capacity/validity/updateinterval for Auth Caches configurable via > nodetool > --- > > Key: CASSANDRA-17063 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Currently Auth Caches configuration options > (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to > introduce a _nodetool setauthcachecapacity_ command. > Also we can think of some VT-based alternative to _nodetool_. But I feel > there is no need to have a separate table for Auth Caches configs. It would > be an overhead. Ideally we need to have a separate VT that shows/sets all the > configs, but it is out of the scope. -- 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-16914) Implement Virtual Tables for Auth Caches
[
https://issues.apache.org/jira/browse/CASSANDRA-16914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433509#comment-17433509
]
Aleksei Zotov commented on CASSANDRA-16914:
---
I raised the tickets for further Auth Caches improvements:
* CASSANDRA-17062 (metrics)
* CASSANDRA-17063 (configuration)
Please, do not hesitate to comment there if you feel that something else needs
to be brought into their scope.
> Implement Virtual Tables for Auth Caches
>
>
> Key: CASSANDRA-16914
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16914
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization, Feature/Virtual Tables
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> {{NodeTool}} commands for Auth Caches invalidation were implemented as a part
> of CASSANDRA-16404 ticket. While discussing that ticket it was agreed that
> there is a need to develop the same kind of functionality through Vitrual
> Tables. Unfortunately, VT did not have {{TRUNCATE}} and {{DELETE}} support.
> And CASSANDRA-16806 was created for that reason. Once it is completed,
> further work can be started.
> The goal of this ticket is to create VTs for the following caches:
> * {{CredentialsCache}}
> * {{JmxPermissionsCache}}
> * {{NetworkPermissionsCache}}
> * {{PermissionsCache}}
> * {{RolesCache}}
> The VTs should support reading from and modification of the in the Auth
> Caches.
--
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-17063) Make capacity/validity/updateinterval for Auth Caches configurable via nodetool
[ https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17063: -- Summary: Make capacity/validity/updateinterval for Auth Caches configurable via nodetool (was: Make capacity/validity/updateinterval for Auth Caches configurable) > Make capacity/validity/updateinterval for Auth Caches configurable via > nodetool > --- > > Key: CASSANDRA-17063 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Currently Auth Caches configuration options > (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to > introduce a _nodetool setauthcachecapacity_ command. > Also we can think of some VT-based alternative to _nodetool_. But I feel > there is no need to have a separate table for Auth Caches configs. It would > be an overhead. Ideally we need to have a separate VT that shows/sets all the > configs, but it is out of the scope. -- 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-17062) Expose Auth Caches metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-17062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17062: -- Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > Expose Auth Caches metrics > -- > > Key: CASSANDRA-17062 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Virtual Tables, Observability/Metrics, > Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Unlike to other caches (row, key, counter), Auth Caches lack some monitoring > capabilities. Here are a few particular changes to get this inequity fixed: > # Add auth caches to _system_views.caches_ VT > # Expose auth caches metrics via JMX > # Add auth caches details to _nodetool info_ > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17063) Make capacity/validity/updateinterval for Auth Caches configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov reassigned CASSANDRA-17063: - Assignee: Aleksei Zotov > Make capacity/validity/updateinterval for Auth Caches configurable > -- > > Key: CASSANDRA-17063 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > > Currently Auth Caches configuration options > (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to > introduce a _nodetool setauthcachecapacity_ command. > Also we can think of some VT-based alternative to _nodetool_. But I feel > there is no need to have a separate table for Auth Caches configs. It would > be an overhead. Ideally we need to have a separate VT that shows/sets all the > configs, but it is out of the scope. -- 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-17063) Make capacity/validity/updateinterval for Auth Caches configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-17063: -- Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 4.x Status: Open (was: Triage Needed) > Make capacity/validity/updateinterval for Auth Caches configurable > -- > > Key: CASSANDRA-17063 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Aleksei Zotov >Assignee: Aleksei Zotov >Priority: Normal > Fix For: 4.x > > > Currently Auth Caches configuration options > (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to > introduce a _nodetool setauthcachecapacity_ command. > Also we can think of some VT-based alternative to _nodetool_. But I feel > there is no need to have a separate table for Auth Caches configs. It would > be an overhead. Ideally we need to have a separate VT that shows/sets all the > configs, but it is out of the scope. -- 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-17063) Make capacity/validity/updateinterval for Auth Caches configurable
Aleksei Zotov created CASSANDRA-17063: - Summary: Make capacity/validity/updateinterval for Auth Caches configurable Key: CASSANDRA-17063 URL: https://issues.apache.org/jira/browse/CASSANDRA-17063 Project: Cassandra Issue Type: Improvement Components: Tool/nodetool Reporter: Aleksei Zotov Currently Auth Caches configuration options (capacity/validity/updateinterval) exposed via JMX or yaml only. We need to introduce a _nodetool setauthcachecapacity_ command. Also we can think of some VT-based alternative to _nodetool_. But I feel there is no need to have a separate table for Auth Caches configs. It would be an overhead. Ideally we need to have a separate VT that shows/sets all the configs, but it is out of the scope. -- 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-17062) Expose Auth Caches metrics
Aleksei Zotov created CASSANDRA-17062: - Summary: Expose Auth Caches metrics Key: CASSANDRA-17062 URL: https://issues.apache.org/jira/browse/CASSANDRA-17062 Project: Cassandra Issue Type: Improvement Components: Feature/Virtual Tables, Observability/Metrics, Tool/nodetool Reporter: Aleksei Zotov Assignee: Aleksei Zotov Unlike to other caches (row, key, counter), Auth Caches lack some monitoring capabilities. Here are a few particular changes to get this inequity fixed: # Add auth caches to _system_views.caches_ VT # Expose auth caches metrics via JMX # Add auth caches details to _nodetool info_ -- 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-17061) DOC - Fix multiple headers, formatting on Monitoring page
[ https://issues.apache.org/jira/browse/CASSANDRA-17061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17433441#comment-17433441 ] Aleksei Zotov commented on CASSANDRA-17061: --- [~flightc] Thanks for raising the ticket! It looks like the issue is actual for 3.11 as well: https://cassandra.apache.org/doc/3.11/cassandra/operating/metrics.html > DOC - Fix multiple headers, formatting on Monitoring page > - > > Key: CASSANDRA-17061 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17061 > Project: Cassandra > Issue Type: Task > Components: Documentation/Website >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > Fix For: 4.x > > Attachments: website-monitoring-01-table_metrics.png, > website-monitoring-02-keyspace_metrics.png > > > [~azotcsit] reported on [ASF > Slack|https://the-asf.slack.com/archives/C01RY1LUPD5/p1635066428010900] that > several sections are formatted incorrectly on the > [Monitoring|https://cassandra.apache.org/doc/latest/cassandra/operating/metrics.html] > page. > For example, the *Table Metrics* section appears as: > !website-monitoring-01-table_metrics.png|width=300! > The following sections don't render correctly: > * Keyspace Metrics > * Threadpool Metrics > * Client Request Metrics > * Cache Metrics > For example: > !website-monitoring-02-keyspace_metrics.png|width=300! -- 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-14385) Fix Some Potential NPE
[
https://issues.apache.org/jira/browse/CASSANDRA-14385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14385:
--
Resolution: Incomplete
Status: Resolved (was: Open)
[~xiaoheipangzi] We got no reply from your side, so I'm closing this ticket for
now. Please, do not hesitate to re-open it if you feel that the proposed
changes are still actual.
Thank you for the desire to improve the project! We look forward to getting
more contributions.
> Fix Some Potential NPE
> ---
>
> Key: CASSANDRA-14385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14385
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Materialized Views
>Reporter: lujie
>Priority: Normal
> Attachments: CA-14385_1.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have developed a static analysis tool
> [NPEDetector|https://github.com/lujiefsi/NPEDetector] to find some potential
> NPE. Our analysis shows that some callees may return null in corner case(e.g.
> node crash , IO exception), some of their callers have _!=null_ check but
> some do not have. In this issue we post a patch which can add !=null based
> on existed !=null check. For example:
> Calle Schema#getView may return null:
> {code:java}
> public ViewMetadata getView(String keyspaceName, String viewName)
> {
> assert keyspaceName != null;
> KeyspaceMetadata ksm = keyspaces.getNullable(keyspaceName);
> return (ksm == null) ? null : ksm.views.getNullable(viewName);//may
> return null
> }
> {code}
> it have 4 callers, 3 of them have !=null check, like its caller
> MigrationManager#announceViewDrop have !=null check()
> {code:java}
> public static void announceViewDrop(String ksName, String viewName, boolean
> announceLocally) throws ConfigurationException
> {
>ViewMetadata view = Schema.instance.getView(ksName, viewName);
> if (view == null)//null pointer checker
> throw new ConfigurationException(String.format("Cannot drop non
> existing materialized view '%s' in keyspace '%s'.", viewName, ksName));
>KeyspaceMetadata ksm = Schema.instance.getKeyspaceMetadata(ksName);
>logger.info("Drop table '{}/{}'", view.keyspace, view.name);
>announce(SchemaKeyspace.makeDropViewMutation(ksm, view,
> FBUtilities.timestampMicros()), announceLocally);
> }
> {code}
> but caller MigrationManager#announceMigration does not have
> We add !=null check based on MigrationManager#announceViewDrop:
> {code:java}
> if (current == null)
> throw new InvalidRequestException("There is no materialized view in
> keyspace " + keyspace());
> {code}
> But due to we are not very familiar with CASSANDRA, hope some expert can
> review it.
> Thanks
>
--
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-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16976:
--
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/460ae341f5628bbf65498e693fb61ac77d4d6c5b
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
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-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16976:
--
Status: Ready to Commit (was: Review In Progress)
CI looks good, will commit soon.
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
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-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16976:
--
Status: Review In Progress (was: Needs Committer)
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
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-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428247#comment-17428247
]
Aleksei Zotov commented on CASSANDRA-16902:
---
[~blerer]
Oh ok, got it. I did not know it is blocked by something else. Sorry for
disturbing!
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-16976) Make nodetool compactionstats and sstable_tasks consistent
[
https://issues.apache.org/jira/browse/CASSANDRA-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16976:
--
Test and Documentation Plan: I wrote unit tests to cover both existing and
new logic. Also I updated documentation.
Status: Patch Available (was: Open)
[~brandon.williams] [~stefan.miklosovic]
I created tests to validate outputs of the nodetool command and the VT. Could
you please check the PR. In the meantime, I've triggered
[CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1206/].
PS:
After checking the suggested dtest, I came to conclusion that it would be an
overhead to generate a bunch of data to ensure that we catch compaction in
progress. So I just start/finish compaction manually on some hardcoded data.
Taking into account this functionality is trivial (and not mission critical)
and we need to test output format only, I feel this is more than enough.
Please, let me know if you have any concerns.
> Make nodetool compactionstats and sstable_tasks consistent
> --
>
> Key: CASSANDRA-16976
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16976
> Project: Cassandra
> Issue Type: Task
> Components: Feature/Virtual Tables, Tool/nodetool
>Reporter: Aleksei Zotov
>Assignee: Aleksei Zotov
>Priority: Normal
> Fix For: 4.x
>
>
> Currently there is a difference in the output if {{nodetool compactionstats}}
> command and {{sstable_tasks}} virtual table (originally introduced by
> CASSANDRA-14457). They need to be aligned. The differences are:
>
> ||nodetool||VT||Comment||
> |percentComplete|completion_ratio|column naming is different only|
> |completed|progress|column naming is different only|
> |compaction type|kind|column naming is different only|
> |sstables|NA| |
> Additionally, please, update necessary documentation.
--
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-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428025#comment-17428025
]
Aleksei Zotov commented on CASSANDRA-16902:
---
[~blerer] [~jmckenzie]
Would you mind reviewing this change? I'd like to get it merged to prevent
conflicts with CASSANDRA-16914.
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-16902) A user should be able to view permissions of role they created
[
https://issues.apache.org/jira/browse/CASSANDRA-16902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-16902:
--
Status: Needs Committer (was: Patch Available)
> A user should be able to view permissions of role they created
> --
>
> Key: CASSANDRA-16902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16902
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Authorization
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently users are denied to view permissions to see a role they created:
> {code}
> CREATE ROLE parent WITH PASSWORD = 'x' AND LOGIN = true;
> GRANT CREATE ON ALL ROLES TO parent;
> LOGIN parent;
> CREATE ROLE child WITH PASSWORD = 'x' AND LOGIN = true;
> LIST ALL PERMISSIONS OF 'child'; -- You are not authorized to view child's
> permissions
> {code}
> When a user creates a role they should get the {{DESCRIBE}} permission on
> that role by default.
--
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-14795) Expose information about stored hints via a nodetool command and a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Fix Version/s: (was: 4.x)
4.1
Source Control Link:
https://github.com/apache/cassandra/commit/fc27042f61a6d78ec998a0186a5e97def90fd50a
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed! Thank you [~Ge]!
> Expose information about stored hints via a nodetool command and a virtual
> table
>
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.1
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-14795) Expose information about stored hints via a nodetool command and a virtual table
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Summary: Expose information about stored hints via a nodetool command and a
virtual table (was: Expose information about stored hints via JMX)
> Expose information about stored hints via a nodetool command and a virtual
> table
>
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14795:
--
Status: Ready to Commit (was: Review In Progress)
I'll get it merged soon (tmrw afternoon my time).
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427895#comment-17427895
]
Aleksei Zotov commented on CASSANDRA-14557:
---
LGTM, +1.
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.1
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14557:
--
Status: Needs Committer (was: Patch Available)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Add default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-14557:
--
Summary: Add default and required keyspace replication options (was:
Consider adding default and required keyspace replication options)
> Add default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14557) Consider adding default and required keyspace replication options
[
https://issues.apache.org/jira/browse/CASSANDRA-14557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426843#comment-17426843
]
Aleksei Zotov commented on CASSANDRA-14557:
---
[~sumanth.pasupuleti]
Thanks for the incorporating my feedback! There are two more very minor nits
that can be fixed on commit though (as well as _CHANGES.txt_). So the code LGTM.
I started CI:
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1204/,]
let wait for the results.
[~stefan.miklosovic] [~brandon.williams] would you be able to review the PR?
> Consider adding default and required keyspace replication options
> -
>
> Key: CASSANDRA-14557
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14557
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Sumanth Pasupuleti
>Assignee: Sumanth Pasupuleti
>Priority: Low
> Labels: 4.0-feature-freeze-review-requested
> Fix For: 4.x
>
> Attachments: 14557-4.0.txt, 14557-trunk.patch
>
>
> Ending up with a keyspace of RF=1 is unfortunately pretty easy in C* right
> now - the system_auth table for example is created with RF=1 (to take into
> account single node setups afaict from CASSANDRA-5112), and a user can
> further create a keyspace with RF=1 posing availability and streaming risks
> (e.g. rebuild).
> I propose we add two configuration options in cassandra.yaml:
> # {{default_keyspace_rf}} (default: 1) - If replication factors are not
> specified, use this number.
> # {{required_minimum_keyspace_rf}} (default: unset) - Prevent users from
> creating a keyspace with an RF less than what is configured
> These settings could further be re-used to:
> * Provide defaults for new keyspaces created with SimpleStrategy or
> NetworkTopologyStrategy (CASSANDRA-14303)
> * Make the automatic token [allocation
> algorithm|https://issues.apache.org/jira/browse/CASSANDRA-13701?focusedCommentId=16095662=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16095662]
> interface more intuitive allowing easy use of the new token allocation
> algorithm.
> At the end of the day, if someone really wants to allow RF=1, they simply
> don’t set the setting. For backwards compatibility the default remains 1 and
> C* would create with RF=1, and would default to current behavior of allowing
> any RF on keyspaces.
--
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-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426702#comment-17426702
]
Aleksei Zotov commented on CASSANDRA-14795:
---
I checked the CI and mentioned no failures related to this PR. I'm wondering
whether we need to update corresponding documentation (_virtualtables.rst_) -
I'm not really sure what the policy on that is. The documentation states that
it mentions only a part of the tables:
{code:java}
Some of the salient virtual tables in ``system_views`` virtual keyspace are
described in Table 1.
We shall discuss some of the virtual tables in more detail next.
{code}
So I do not feel we are enforced to describe every table. On the other hand, it
would not make worse. I hope [~e.dimitrova] can judge on that.
Code-wise the changes LGTM, +1.
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 7h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17426018#comment-17426018
]
Aleksei Zotov commented on CASSANDRA-14795:
---
[~Ge]
I see that Stefan has already started
[https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1191/].
In the meantime, I put a couple of comments to the PR.
Also I mentioned that Python dtest already exists. I missed that Jira comment
and that's why kept asking about that on PR, sorry for that!
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-17016) Allow reverse iteration of resources during permissions checking
[
https://issues.apache.org/jira/browse/CASSANDRA-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425771#comment-17425771
]
Aleksei Zotov commented on CASSANDRA-17016:
---
LGTM, +1.
> Allow reverse iteration of resources during permissions checking
>
>
> Key: CASSANDRA-17016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17016
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When we perform authz checks for AuthenticatedUser on a given resource, we
> traverse the resource hierarchy until we either find the required permission
> or we exhaust the traversal. This goes from most specific resource (i.e.
> iResource we're interested in) to the broadest (the root for that iResource
> type).
> Since permissions are a whitelist it isn't possible for a permission granted
> on a more specific resource to be negated or overridden by a grant on a
> resource lower in the hierarchy towards the root. For example, for
> DataResource, the hierarchy goes:
> {code:java}
> root -> keyspace -> table{code}
> So for instance if we:
>
> {code:java}
> GRANT ALL ON KEYSPACE ks TO admin_user;
> {code}
> It is impossible to grant admin_user any set of permissions more restrictive
> than ALL on ks.
> When a request comes in for a user with permissions on a ks for example, you
> can have a path of:
> # Validate SELECT on t1
> # Then check for SELECT on ks
> # Then check for permissions on 'root'
> These unnecessary lookups can negate some of the benefits of caching (and
> pre-warming, which another ticket is in flight for), and lead to issues on
> bounces with timeouts.
> Additionally, the permissions cache ends up storing far more entries than
> necessary, as a subsequent request for ks.t2 by user_x will go through the
> same process and create a second cache entry etc.
> So all this said - this is something we should allow operators to opt-in to;
> impact and performance is going to be highly dependent on the pattern of
> authentication granting and usage on a cluster.
>
--
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-17016) Allow reverse iteration of resources during permissions checking
[
https://issues.apache.org/jira/browse/CASSANDRA-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17016:
--
Authors: Aleksei Zotov, Josh McKenzie (was: Josh McKenzie)
> Allow reverse iteration of resources during permissions checking
>
>
> Key: CASSANDRA-17016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17016
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When we perform authz checks for AuthenticatedUser on a given resource, we
> traverse the resource hierarchy until we either find the required permission
> or we exhaust the traversal. This goes from most specific resource (i.e.
> iResource we're interested in) to the broadest (the root for that iResource
> type).
> Since permissions are a whitelist it isn't possible for a permission granted
> on a more specific resource to be negated or overridden by a grant on a
> resource lower in the hierarchy towards the root. For example, for
> DataResource, the hierarchy goes:
> {code:java}
> root -> keyspace -> table{code}
> So for instance if we:
>
> {code:java}
> GRANT ALL ON KEYSPACE ks TO admin_user;
> {code}
> It is impossible to grant admin_user any set of permissions more restrictive
> than ALL on ks.
> When a request comes in for a user with permissions on a ks for example, you
> can have a path of:
> # Validate SELECT on t1
> # Then check for SELECT on ks
> # Then check for permissions on 'root'
> These unnecessary lookups can negate some of the benefits of caching (and
> pre-warming, which another ticket is in flight for), and lead to issues on
> bounces with timeouts.
> Additionally, the permissions cache ends up storing far more entries than
> necessary, as a subsequent request for ks.t2 by user_x will go through the
> same process and create a second cache entry etc.
> So all this said - this is something we should allow operators to opt-in to;
> impact and performance is going to be highly dependent on the pattern of
> authentication granting and usage on a cluster.
>
--
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-17016) Allow reverse iteration of resources during permissions checking
[
https://issues.apache.org/jira/browse/CASSANDRA-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17425530#comment-17425530
]
Aleksei Zotov commented on CASSANDRA-17016:
---
I feel some small improvements can be made, so I posted a few comments to the
PR.
> Allow reverse iteration of resources during permissions checking
>
>
> Key: CASSANDRA-17016
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17016
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> When we perform authz checks for AuthenticatedUser on a given resource, we
> traverse the resource hierarchy until we either find the required permission
> or we exhaust the traversal. This goes from most specific resource (i.e.
> iResource we're interested in) to the broadest (the root for that iResource
> type).
> Since permissions are a whitelist it isn't possible for a permission granted
> on a more specific resource to be negated or overridden by a grant on a
> resource lower in the hierarchy towards the root. For example, for
> DataResource, the hierarchy goes:
> {code:java}
> root -> keyspace -> table{code}
> So for instance if we:
>
> {code:java}
> GRANT ALL ON KEYSPACE ks TO admin_user;
> {code}
> It is impossible to grant admin_user any set of permissions more restrictive
> than ALL on ks.
> When a request comes in for a user with permissions on a ks for example, you
> can have a path of:
> # Validate SELECT on t1
> # Then check for SELECT on ks
> # Then check for permissions on 'root'
> These unnecessary lookups can negate some of the benefits of caching (and
> pre-warming, which another ticket is in flight for), and lead to issues on
> bounces with timeouts.
> Additionally, the permissions cache ends up storing far more entries than
> necessary, as a subsequent request for ks.t2 by user_x will go through the
> same process and create a second cache entry etc.
> So all this said - this is something we should allow operators to opt-in to;
> impact and performance is going to be highly dependent on the pattern of
> authentication granting and usage on a cluster.
>
--
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-14795) Expose information about stored hints via JMX
[
https://issues.apache.org/jira/browse/CASSANDRA-14795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424547#comment-17424547
]
Aleksei Zotov commented on CASSANDRA-14795:
---
[~Ge]
Thanks for fixing all review comments!
As for me two points are remaining:
# I'd like to hear [~e.dimitrova] / [~brandon.williams] opinion on whether we
need to sort columns in the output of {{nodetool}} output and the VT
# We agreed on having dtests, so I feel it makes sense to merge everything in
one batch
Apart from these two points, everything looks good to me. In the meantime, I've
[triggered Jenkins
CI|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1174/],
so we can ensure the changes do not break anything at the moment.
> Expose information about stored hints via JMX
> -
>
> Key: CASSANDRA-14795
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14795
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/Observability
>Reporter: Aleksandr Sorokoumov
>Assignee: Aleksandr Sorokoumov
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> Currently there is no way to determine what kind of hints a node has, apart
> from looking at the filenames (thus host-ids) on disk. Having a way to access
> this information would help with debugging hint creation/replay scenarios.
> In addition to the JMX method, there is a new nodetool command:
> {noformat}$ bin/nodetool -h 127.0.0.1 -p 7100 listendpointspendinghints
> Host ID Address Rack DC Status Total files Newest Oldest
> 5762b140-3fdf-4057-9ca7-05c070ccc9c3 127.0.0.2 rack1 datacenter1 DOWN 2
> 2018-09-18 14:05:18,835 2018-09-18 14:05:08,811
> {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-16927) Mockable Streaming
[ https://issues.apache.org/jira/browse/CASSANDRA-16927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-16927: -- Reviewers: Aleksei Zotov, Sam Tunnicliffe (was: Sam Tunnicliffe) > Mockable Streaming > -- > > Key: CASSANDRA-16927 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16927 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Streaming and Messaging >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > To support CEP-10 it is necessary to support alternative streaming > implementations, so that execution may be controlled. The ticket encompasses > two sub-tickets: firstly we make InetAddressAndPort extend InetAddress so > that we may 2) introduce a cross-classloader API for establishing a streaming > connection and sending data over it. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-16928) InetAddressAndPort to extend InetAddress
[ https://issues.apache.org/jira/browse/CASSANDRA-16928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksei Zotov updated CASSANDRA-16928: -- Reviewers: Aleksei Zotov, Sam Tunnicliffe (was: Sam Tunnicliffe) > InetAddressAndPort to extend InetAddress > > > Key: CASSANDRA-16928 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16928 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Logically InetAddressAndPort encapsulates the same information as a simple > InetAddress. Importantly, InetAddressAndPort cannot easily be unpicked from > its dependencies that prohibit it being shared between classloaders. So our > in-jvm dtest API instead uses SocketAddress. To support a clean and efficient > Streaming API we need to be able to treat InetAddressAndPort as such a > cross-classloader type. -- 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-17013) CEP-10: dtest-api improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17423708#comment-17423708 ] Aleksei Zotov commented on CASSANDRA-17013: --- [~samt] Could you please share the corresponding PR link? > CEP-10: dtest-api improvements > -- > > Key: CASSANDRA-17013 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17013 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Benedict Elliott Smith >Assignee: Benedict Elliott Smith >Priority: Normal > > Introduce new dtest-api features to support CEP-10, including byte weaving > support, support for Path objects specifying location, and other minor > ergonomic improvements -- 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
