[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Fix Version/s: 5.1-alpha1 (was: 5.x) Source Control Link: https://github.com/apache/cassandra/commit/df78296dcbc67c1d6dd1e0412fcd71f0a8f8fa7c Resolution: Fixed Status: Resolved (was: Ready to Commit) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847948#comment-17847948 ] Stefan Miklosovic commented on CASSANDRA-19556: --- Links were consolidated in Links section of this ticket. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847930#comment-17847930 ] Stefan Miklosovic commented on CASSANDRA-19556: --- Let's ask then and get these binding -1s explicitly. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Status: Ready to Commit (was: Review In Progress) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19648: -- Reviewers: Brandon Williams, Stefan Miklosovic Status: Review In Progress (was: Needs Committer) > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19648) Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS
[ https://issues.apache.org/jira/browse/CASSANDRA-19648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847913#comment-17847913 ] Stefan Miklosovic commented on CASSANDRA-19648: --- +1 > Flaky test: StartupChecksTest#testKernelBug1057843Check() on Non-Linux OS > - > > Key: CASSANDRA-19648 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19648 > Project: Cassandra > Issue Type: Improvement > Components: Test/unit >Reporter: Ling Mao >Assignee: Ling Mao >Priority: Low > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Flaky test: StartupChecksTest#testKernelBug1057843Check() cannot pass in my > MacOs(maybe Windows OS). Just skip this test when tested on Non-Linux OS -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Fix Version/s: 5.1-alpha1 (was: 5.x) Since Version: NA Source Control Link: https://github.com/apache/cassandra/commit/dc89df7da1d9577ed0130873c491f7f4ccf99bae Resolution: Fixed Status: Resolved (was: Ready to Commit) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847710#comment-17847710 ] Stefan Miklosovic commented on CASSANDRA-19645: --- +1 > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Status: Ready to Commit (was: Review In Progress) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847677#comment-17847677 ] Stefan Miklosovic commented on CASSANDRA-19645: --- maybe logging "sequence.kind()" is better? > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic edited comment on CASSANDRA-19645 at 5/19/24 12:54 PM: - Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the default one will be used which is pretty much non-telling. was (Author: smiklosovic): Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic edited comment on CASSANDRA-19645 at 5/19/24 12:54 PM: - Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. was (Author: smiklosovic): Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log the message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847676#comment-17847676 ] Stefan Miklosovic commented on CASSANDRA-19645: --- Looks good but just saying that when "sequence" is MultiStepOperation, which is abstract class, then log the message in GossiperHelper where "toString" is implicitly called on sequence will rely on overridden toString method in extended classes of MultiStepOperation. In other words, if somebody creates new MultiStepOperation and forgets to override toString in it, the the default one will be used which is pretty much non-telling. > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19645) Mismatch of number of args of String.format() in three classes
[ https://issues.apache.org/jira/browse/CASSANDRA-19645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19645: -- Status: Review In Progress (was: Needs Committer) > Mismatch of number of args of String.format() in three classes > -- > > Key: CASSANDRA-19645 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19645 > Project: Cassandra > Issue Type: Bug > Components: Local/Other >Reporter: Dmitrii Kriukov >Assignee: Dmitrii Kriukov >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > Affected classes: > GossipHelper lines 196-197 > SchemaGenerators line 488 > StorageService line 1087 > I'm goind to provide a PR -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Status: Changes Suggested (was: Review In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847146#comment-17847146
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
Oh well, so there are failures when upgrading to this version. It is all in the
respective logs.
I think it is not just about bumping the versions ... Naively bumping it
compiles but tests are failing.
The failure is something like this:
{noformat}
failed on teardown with "Unexpected error found in node logs (see stdout for
full details). Errors: [[node1] "WARN [RMI TCP Connection(2)-127.0.0.1]
2024-05-16 13:47:46,320 Slf4jExceptionHandler.java:50 - You've configured your
queue to use a deprecated RollCycle
(net.openhft.chronicle.queue.RollCycles.TEST_SECONDLY) please consider
switching to
net.openhft.chronicle.queue.rollcycles.TestRollCycles.TEST_SECONDLY, as the
RollCycle constant you've nominated will be removed in a future release!"]"
{noformat}
[CASSANDRA-18712|https://github.com/instaclustr/cassandra/tree/CASSANDRA-18712]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 30s
✓ j17_cqlsh_dtests_py311 6m 57s
✓ j17_cqlsh_dtests_py311_vnode 7m 18s
✓ j17_cqlsh_dtests_py387m 17s
✓ j17_cqlsh_dtests_py38_vnode 7m 20s
✓ j17_cqlshlib_cython_tests8m 15s
✓ j17_cqlshlib_tests 6m 42s
✓ j17_jvm_dtests_latest_vnode 21m 0s
✓ j17_unit_tests 14m 12s
✓ j17_utests_oa13m 5s
✕ j17_dtests 36m 30s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_latest 36m 43s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
configuration_test.TestConfiguration test_change_durable_writes
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_dtests_vnode38m 20s
auditlog_test.TestAuditlog test_archive_on_shutdown
auditlog_test.TestAuditlog test_archive_on_startup
auditlog_test.TestAuditlog test_archiving
auditlog_test.TestAuditlog test_archiving_fql
auditlog_test.TestAuditlog test_fql_nodetool_options
fqltool_test.TestFQLTool test_compare
fqltool_test.TestFQLTool test_compare_mismatch
fqltool_test.TestFQLTool test_jvmdtest
fqltool_test.TestFQLTool test_replay
fqltool_test.TestFQLTool test_unclean_enable
✕ j17_jvm_dtests 22m 57s
✕ j17_utests_latest 14m 25s
org.apache.cassandra.net.ConnectionTest testTimeout
java17_separate_tests
java11_pre-commit_tests
✓ j11_build7m 33s
✓ j11_cqlsh_dtests_py311 8m 26s
✓ j11_cqlsh_dtests_py311_vnode 8m 8s
✓ j11_cqlsh_dtests_py388m 29s
✓ j11_cqlsh_dtests_py38_vnode 10m 33s
✓ j11_cqlshlib_cython_tests11m 8s
✓ j11_cqlshlib_tests 11m 39s
✓ j11_jvm_dtests 27m 21s
✓ j11_jvm_dtests_latest_vnode 21m 8s
✓ j11_unit_tests 17m 33s
✓ j11_utests_oa 18m 53s
✓ j11_utests_system_keyspace_directory18m 43s
✓ j17_cqlsh_dtests_py311 6m 51s
✓ j17_cqlsh_dtests_py311_vnode 7m 20s
✓ j17_cqlsh_dtests_py38 7m 6s
✓ j17_cqlsh_dtests_py38_vnode 7m 33s
✓ j17_cqlshlib_cython_tests7m 28s
✓ j17_cqlshlib_tests 8m 41s
✓ j17_unit_tests 14m 23s
✓ j17_utests_latest
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847145#comment-17847145 ] Stefan Miklosovic commented on CASSANDRA-19556: --- I understand your concern about chasing the last rc blocker but purely in practical terms, as long as e.g. 19534 is not merged first we have time to merge this too. I am not sure what the next steps are. Do you want me to re-iterate the necessity of merging this on the ML in the respective mailing list thread? > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17847034#comment-17847034
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
{quote}I really think that the silver bullet does exist and that is just
removing alter_table_enabled while it is not late and introducing ddl_enabled
in 5.0 GA.
{quote}
I still think this is completely reasonable to do even now. There will be still
at least one rc1 anyway. What are the _objective_ reasons this can't be
incorporated now? There are way bigger patches like CASSANDRA-19534 which seem
to be completely OK to be introduced even now, this patch is magnitude less
complicated.
> Add guardrail to block DDL/DCL queries and replace alter_table_enabled
> guardrail
>
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846941#comment-17846941 ] Stefan Miklosovic commented on CASSANDRA-18712: --- What I would personally do is that I would wait with this ticket until 5.1 is imminent. The reason for doing so is that while we release 5.1, we will most likely want to update these dependencies again because they are being actively developed. I do not see any critical reason why should be this merged _right now_ - only if we want to enable people to test trunk on s390x as mentioned in the description that this is a blocker for them, but we do not officially support that architecture anyway ... > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:41 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
I checked that the versions match the versions in the bom.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic edited comment on CASSANDRA-18712 at 5/16/24 11:40 AM:
-
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same (checking with mvn
dependency:tree)
I am not sure what is their policy when it comes to release versioning.
[https://central.sonatype.com/artifact/net.openhft/chronicle-core/versions]
E.g. there is not any "not early access" of 2.24, they stopped with 2.24ea28
and next one was 2.25ea0.
[https://repo1.maven.org/maven2/net/openhft/chronicle-core/]
was (Author: smiklosovic):
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[
https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846919#comment-17846919
]
Stefan Miklosovic commented on CASSANDRA-18712:
---
I verified that a tarball with this change contains
{code:java}
chronicle-bytes-2.25ea9.jar
chronicle-core-2.25ea13.jar
chronicle-queue-5.25ea13.jar
chronicle-threads-2.25ea6.jar
chronicle-wire-2.25ea12.jar{code}
while the old tarball contains
{code:java}
chronicle-bytes-2.23.33.jar
chronicle-core-2.23.36.jar
chronicle-queue-5.23.37.jar
chronicle-threads-2.23.25.jar
chronicle-wire-2.23.39.jar{code}
There are no changes in libs dir except these.
When it comes to pom.xml (after ant mvn-install), it is same.
> Update Chronicle bytes
> --
>
> Key: CASSANDRA-18712
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18712
> Project: Cassandra
> Issue Type: Task
> Components: Dependencies
>Reporter: Nayana Thorat
>Assignee: Nayana Thorat
>Priority: Normal
> Fix For: 5.x
>
>
> [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of
> cassandra on s390x.
> This patch is merged and available in chronicle-bytes-2.24ea7 and later
> releases.
> possible to update Chronicle bytes and related pkg versions in Cassandra
> (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)?
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846897#comment-17846897 ] Stefan Miklosovic commented on CASSANDRA-18712: --- thanks [~Nayana] , I ll take a look. > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Reviewers: Stefan Miklosovic Status: Review In Progress (was: Patch Available) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-18712: -- Test and Documentation Plan: ci Status: Patch Available (was: In Progress) > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18712) Update Chronicle bytes
[ https://issues.apache.org/jira/browse/CASSANDRA-18712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic reassigned CASSANDRA-18712: - Assignee: Nayana Thorat > Update Chronicle bytes > -- > > Key: CASSANDRA-18712 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18712 > Project: Cassandra > Issue Type: Task > Components: Dependencies >Reporter: Nayana Thorat >Assignee: Nayana Thorat >Priority: Normal > Fix For: 5.x > > > [https://github.com/OpenHFT/Chronicle-Bytes/pull/485] fixes test failures of > cassandra on s390x. > This patch is merged and available in chronicle-bytes-2.24ea7 and later > releases. > possible to update Chronicle bytes and related pkg versions in Cassandra > (https://github.com/apache/cassandra/blob/trunk/.build/parent-pom-template.xml)? > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846725#comment-17846725
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
I think that because this is targetted primarily to 4.0 / 4.1 and all eyes are
on 5.0 for now, I do not see this has high priority at the moment, especially
as we are just releasing 4.1.5 / 4.0.13.
I would however say that you can expect this to be eventually merged, I just do
not know about when.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846337#comment-17846337 ] Stefan Miklosovic commented on CASSANDRA-19335: --- the logic of the test is wrapped in "ifs", checking what version a node is of and then acting accordingly - doing it with or without new feature. > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846324#comment-17846324 ] Stefan Miklosovic commented on CASSANDRA-19335: --- maybe I am missing something but ... how does this work for e.g. 4.0 branch? By looking at (1), we are introducing -r flag for table stats for tests which have nodetool without this feature, no? (1) https://github.com/apache/cassandra-dtest/pull/261/files > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19335) Default nodetool tablestats to Human-Readable Output
[ https://issues.apache.org/jira/browse/CASSANDRA-19335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19335: -- Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) Status: Review In Progress (was: Needs Committer) > Default nodetool tablestats to Human-Readable Output > > > Key: CASSANDRA-19335 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19335 > Project: Cassandra > Issue Type: Improvement > Components: Tool/nodetool >Reporter: Leo Toff >Assignee: Leo Toff >Priority: Low > Fix For: 5.x > > Attachments: c-19335-dtest-bootstraptest-fail.txt, > c-19335-dtest-ccm-fail.txt, c-19335-dtest-compactiontest-fail.txt > > Time Spent: 1h > Remaining Estimate: 0h > > *Current Behavior* > The current implementation of nodetool tablestats in Apache Cassandra outputs > statistics in a format that is not immediately human-readable. This output > primarily includes raw byte counts, which require additional calculation or > conversion to be easily understood by users. This can be inefficient and > time-consuming, especially for users who frequently monitor these statistics > for performance tuning or maintenance purposes. > *Proposed Change* > We propose that nodetool tablestats should, by default, provide its output in > a human-readable format. This change would involve converting byte counts > into more understandable units (KiB, MiB, GiB). The tool could still retain > the option to display raw data for those who need it, perhaps through a flag > such as --no-human-readable or --raw. > *Considerations* > The change should maintain backward compatibility, ensuring that scripts or > tools relying on the current output format can continue to function correctly. > We should provide adequate documentation and examples of both the new default > output and how to access the raw data format, if needed. > *Alignment* > Discussion in the dev mailing list: > [https://lists.apache.org/thread/mlp715kxho5b6f1ql9omlzmmnh4qfby9] > *Related work* > Previous work in the series: > # https://issues.apache.org/jira/browse/CASSANDRA-19015 > # https://issues.apache.org/jira/browse/CASSANDRA-19104 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 4.1.6
5.0-beta2
5.1-alpha1
(was: 5.x)
(was: 4.1.x)
(was: 5.0.x)
Since Version: 4.1.0
Source Control Link:
https://github.com/apache/cassandra/commit/d1f2936ccbc54158831b01499554adf63ae2d6ec
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.6, 5.0-beta2, 5.1-alpha1
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Ready to Commit (was: Review In Progress)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Reviewers: Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Patch Available (was: Ready to Commit)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Status: Ready to Commit (was: Review In Progress)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846094#comment-17846094
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
Nothing seems to be related. I am sending it by tomorrow.
[CASSANDRA-19498-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 14s
✓ j17_cqlsh_dtests_py311 7m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 17s
✓ j17_cqlsh_dtests_py38 7m 1s
✓ j17_cqlsh_dtests_py38_vnode 7m 38s
✓ j17_cqlshlib_cython_tests7m 30s
✓ j17_cqlshlib_tests 9m 13s
✓ j17_dtests_vnode36m 15s
✓ j17_unit_tests 13m 36s
✓ j17_utests_latest 14m 55s
✓ j17_utests_oa 13m 51s
✕ j17_dtests 37m 33s
pushed_notifications_test.TestPushedNotifications
test_move_single_node_localhost
✕ j17_dtests_latest 36m 11s
configuration_test.TestConfiguration test_change_durable_writes
topology_test.TestTopology test_resumable_decommission
✕ j17_jvm_dtests 23m 43s
org.apache.cassandra.distributed.test.NativeTransportEncryptionOptionsTest
testEndpointVerificationEnabledIpNotInSAN
org.apache.cassandra.distributed.test.log.CoordinatorPathTest
readConsistencyTest
✕ j17_jvm_dtests_latest_vnode 19m 35s
org.apache.cassandra.fuzz.harry.integration.model.ConcurrentQuiescentCheckerIntegrationTest
testConcurrentReadWriteWorkload
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4306/workflows/af302198-2b4a-4283-a6f0-bd90710f05a8]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail:
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17846045#comment-17846045
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py311 6m 43s
✓ j17_cqlsh_dtests_py311_vnode 6m 11s
✓ j17_cqlsh_dtests_py38 6m 2s
✓ j17_cqlsh_dtests_py38_vnode 6m 31s
✓ j17_cqlshlib_cython_tests7m 21s
✓ j17_cqlshlib_tests 6m 43s
✓ j17_dtests 35m 20s
✓ j17_dtests_latest 33m 16s
✓ j17_dtests_vnode33m 50s
✓ j17_jvm_dtests 22m 25s
✓ j17_jvm_dtests_latest_vnode 17m 1s
✓ j17_unit_tests 15m 43s
✓ j17_utests_latest 14m 16s
✓ j17_utests_oa 14m 16s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4305/workflows/f1f3c878-e0be-4b3c-9b53-315b3148e556]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845960#comment-17845960
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[CASSANDRA-19498-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19498-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build 2m 0s
✓ j11_cqlsh_dtests_py3 5m 50s
✓ j11_cqlsh_dtests_py311 5m 42s
✓ j11_cqlsh_dtests_py311_vnode 5m 58s
✓ j11_cqlsh_dtests_py385m 36s
✓ j11_cqlsh_dtests_py38_vnode 6m 1s
✓ j11_cqlsh_dtests_py3_vnode 6m 10s
✓ j11_cqlshlib_cython_tests 8m 4s
✓ j11_cqlshlib_tests 6m 28s
✓ j11_dtests 35m 12s
✓ j11_dtests_vnode37m 47s
✓ j11_jvm_dtests 19m 30s
✓ j11_jvm_dtests_vnode11m 50s
✕ j11_unit_tests 7m 30s
org.apache.cassandra.tools.TopPartitionsTest
testServiceTopPartitionsSingleTable
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4300/workflows/47cb43ab-a92d-41e0-8ed7-6a45da454d23]
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:57 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. Having two rules at the same time leads to kind of inconsistency / unexpected behavior. If we have ddl_enabled, it will, functionally, shadow alter_table_enabled. If the former is disabled but the latter is enabled, we can not alter tables which I find rather confusing for a user. I think there is no such case yet which would behave similarly. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/13/24 1:55 PM: So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Plus we are not going to deprecate it in 5.0.x either. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. was (Author: smiklosovic): So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845934#comment-17845934 ] Stefan Miklosovic commented on CASSANDRA-19556: --- So deprecation of alter_table_enabled is probably out of window because it was never released in a GA so deprecating something on the very first introduction does not make sense to me either. It would be just better if we removed alter_table_enabled altogether in that case so we can just put ddl_enabled to 5.1. Individual guardrail per group, as explained on the mailing list, is IMHO overkill. All the explanation is there. I really think that the silver bullet _does_ exist and that is just removing alter_table_enabled while it is not late and introducing ddl_enabled in 5.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0.x
(was: 5.0-rc)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Fix Version/s: 5.0-rc
(was: 5.0.x)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] section in credentials file removed unintentionally
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] section in credentials file
removed unintentionally (was: support legacy [plain_text_auth] in credentials
file)
> support legacy [plain_text_auth] section in credentials file removed
> unintentionally
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845890#comment-17845890
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
I am starting the builds. I also tweaked the wording around docs a little bit
etc ...
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT by Stefan Miklosovic:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT by Stefan Miklosovic:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Reviewers: Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Brad Schoening, Stefan Miklosovic, Stefan Miklosovic (was: Brad
Schoening, Stefan Miklosovic)
Status: Review In Progress (was: Patch Available)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Description:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
[https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
EDIT:
specifying username and password in credentials file works, it is just that
[plain_text_auth] section does not work in credentials file anymore. This was
working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
tickets were firstly introduced in 4.1.0 (for the public). I do not think that
it was ever an intention to stop to support that when CASSANDRA-16456 was
merged and it was most probably just overlooked.
was:
The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
however, it is immediately ignored.
https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
{code:java}
if not options.username:
credentials = configparser.ConfigParser()
if options.credentials is not None:
credentials.read(options.credentials) # use the username
from credentials file but fallback to cqlshrc if username is absent from the
command line parameters
options.username = username_from_cqlshrc if not options.password:
rawcredentials = configparser.RawConfigParser()
if options.credentials is not None:
rawcredentials.read(options.credentials) # handling password
in the same way as username, priority cli > credentials > cqlshrc
options.password = option_with_default(rawcredentials.get,
'plain_text_auth', 'password', password_from_cqlshrc)
options.password = password_from_cqlshrc{code}
These corrections have been made in accordance with
https://issues.apache.org/jira/browse/CASSANDRA-16983 and
https://issues.apache.org/jira/browse/CASSANDRA-16456.
The documentation does not indicate that AuthProviders can be used in the
cqlshrc and credentials files.
I propose to return the ability to use the legacy option of specifying the user
and password in the credentials file in the [plain_text_auth] section.
It is also required to describe the rules for using the credentials file in the
documentation.
I can make a corresponding pull request.
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
>
[jira] [Assigned] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic reassigned CASSANDRA-19498:
-
Assignee: Stefan Miklosovic
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> [https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070]
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
> EDIT:
> specifying username and password in credentials file works, it is just that
> [plain_text_auth] section does not work in credentials file anymore. This was
> working with CASSANDRA-16983 but it stopped to work by CASSANDRA-16456. Both
> tickets were firstly introduced in 4.1.0 (for the public). I do not think
> that it was ever an intention to stop to support that when CASSANDRA-16456
> was merged and it was most probably just overlooked.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19498) support legacy [plain_text_auth] in credentials file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19498:
--
Summary: support legacy [plain_text_auth] in credentials file (was: Error
reading data from credential file)
> support legacy [plain_text_auth] in credentials file
>
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845839#comment-17845839
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
Thanks for the approval on the PR, [~blerer] . I think we will get to this
post-5.0 again.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845735#comment-17845735 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:16 PM: if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after alter_table_enabled is in 5.0.0 GA. was (Author: smiklosovic): if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after this one is in 5.0.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:12 PM: The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how we are actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] was (Author: smiklosovic): The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic edited comment on CASSANDRA-19556 at 5/12/24 5:10 PM: The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] was (Author: smiklosovic): The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail run in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845735#comment-17845735 ] Stefan Miklosovic commented on CASSANDRA-19556: --- if you all think otherwise then please go to ML and explain your position PLUS please provide the clear guidance how to introduce ddl_enabled rule after this one is in 5.0.0 GA. > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845734#comment-17845734 ] Stefan Miklosovic commented on CASSANDRA-19556: --- The decision about putting this in 5.0-rc/beta2 was made based on this answer on the ML (1) where Josh said that he would make an exception: _if you could get this patch in before we GA'd, I'd personally support making an exception for it._ Hence I went ahead. I still think that this makes sense to include in 5.0.0 GA. If we do not, then the situation we find ourselves in post GA is that we will have "alter_table_enabled" guardrail run in cassandra.yaml and then ... what exactly is the path forward? If we do not do this right now, replacing alter_table_enabled with ddl_enabled, then 5.0.0 will be the only release which will include alter_table_enabled because if ddl_enabled is introduced then alter_table_enabled does not make sense to exist anymore. (Please go over the ML thread and my initial email where I go over all possibilities we have). I would rather not release anything with alter_table_enabled than to make it more problematic / questionable how are we actually going to get rid of it post GA because of backward compatibility etc. It just does not make sense to me to introduce something we know will have little value once it is out and we know we want to replace it. Are we OK to drop a guardrail rule just like that? What is the policy? (1) [https://lists.apache.org/thread/tz2mlzt2pnym2l1kvxgxxkmy65hznywl] > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845733#comment-17845733 ] Stefan Miklosovic commented on CASSANDRA-19632: --- Well ... I created this ticket to be of type "improvement" and fix versions are 5.0.x and 5.x. I think that says it all. I also wrote: _We should fix this at least in trunk and 5.0 (not critical though)_ Yeah, 5.0 is just nice to have, not critical ... We also do not know how to quantify the improvement. Can we tell for sure what other (significant) performance improvements are out there? I think we were rather "lucky" to hit something like CASSANDRA-19429 but that does not mean that such improvements would be indeed found at other places too. > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Summary: Add guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail (was: Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail) > Add guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Summary: Add Guardrail to block DDL/DCL queries and replace alter_table_enabled guardrail (was: Guardrail to block DDL/DCL queries) > Add Guardrail to block DDL/DCL queries and replace alter_table_enabled > guardrail > > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
[ https://issues.apache.org/jira/browse/CASSANDRA-19632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19632: -- Fix Version/s: 5.0.x 5.x > wrap tracing logs in isTraceEnabled across the codebase > --- > > Key: CASSANDRA-19632 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 > Project: Cassandra > Issue Type: Improvement >Reporter: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > > Our usage of logger.isTraceEnabled across the codebase is inconsistent. This > would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] > suggested. > We should fix this at least in trunk and 5.0 (not critical though) and > probably come up with a checkstyle rule to prevent not calling isTraceEnabled > while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19632) wrap tracing logs in isTraceEnabled across the codebase
Stefan Miklosovic created CASSANDRA-19632: - Summary: wrap tracing logs in isTraceEnabled across the codebase Key: CASSANDRA-19632 URL: https://issues.apache.org/jira/browse/CASSANDRA-19632 Project: Cassandra Issue Type: Improvement Reporter: Stefan Miklosovic Our usage of logger.isTraceEnabled across the codebase is inconsistent. This would also fix issues similar in e.g. CASSANDRA-19429 as [~rustyrazorblade] suggested. We should fix this at least in trunk and 5.0 (not critical though) and probably come up with a checkstyle rule to prevent not calling isTraceEnabled while logging with TRACE level. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19631) Consider autocompletion of in-built functions in CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-19631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19631: -- Description: Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to choose from without consulting the documentation. (was: Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to chose from without consulting the documentation.) > Consider autocompletion of in-built functions in CQLSH > -- > > Key: CASSANDRA-19631 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Priority: Normal > > Why do we not autocomplete native functions in CQLSH shell? I am pretty lost > in what functions are there to choose from without consulting the > documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19631) Consider autocompletion of in-built functions in CQLSH
Stefan Miklosovic created CASSANDRA-19631: - Summary: Consider autocompletion of in-built functions in CQLSH Key: CASSANDRA-19631 URL: https://issues.apache.org/jira/browse/CASSANDRA-19631 Project: Cassandra Issue Type: Improvement Components: CQL/Interpreter Reporter: Stefan Miklosovic Why do we not autocomplete native functions in CQLSH shell? I am pretty lost in what functions are there to chose from without consulting the documentation. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Fix Version/s: 5.0.x
(was: 3.0.x)
(was: 3.11.x)
(was: 4.0.x)
(was: 4.1.x)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.0.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 9:32 AM:
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical. I moved it to improvement ticket type and lowered
the priority.
was (Author: smiklosovic):
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 9:31 AM:
well, thinking about it more, this is actually an improvement rather than a
bug, even less so critical.
was (Author: smiklosovic):
well, thinking about it more, this is actual an improvement rather than a bug,
even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Workflow: Copy of Cassandra Default Workflow (was: Copy of Cassandra Bug
Workflow)
Issue Type: Improvement (was: Bug)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-18322:
--
Priority: Normal (was: Urgent)
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845260#comment-17845260
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
well, thinking about it more, this is actual an improvement rather than a bug,
even less so critical.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 7:58 AM:
[~blerer] any chance this might appear in 5.0 and trunk only? I just forgot
about this one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
was (Author: smiklosovic):
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic edited comment on CASSANDRA-18322 at 5/10/24 7:57 AM:
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
https://github.com/apache/cassandra/pull/2668/files
was (Author: smiklosovic):
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18322) Warn about unqualified prepared statement only if it is a select, update, delete, insert
[
https://issues.apache.org/jira/browse/CASSANDRA-18322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845235#comment-17845235
]
Stefan Miklosovic commented on CASSANDRA-18322:
---
[~blerer] any chance this might appear in 5.0+ only? I just forgot about this
one and we just somehow dropped the ball.
> Warn about unqualified prepared statement only if it is a select, update,
> delete, insert
>
>
> Key: CASSANDRA-18322
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18322
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Mohammad Aburadeh
>Assignee: Stefan Miklosovic
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Hi,
> We get the following warnings when we use prepared statements with "create
> keyspace ... " or "drop keyspace" statements.
> "
> {{USE }} with prepared statements is considered to be an
> anti-pattern due to ambiguity in non-qualified table names. Please consider
> removing instances of {{{}Session#setKeyspace(){}}},
> {{Session#execute("USE ")}} and {{cluster.newSession()}}
> from your code, and always use fully qualified table names (e.g.
> .). Keyspace used: null, statement keyspace: null, statement
> id: 8153d922390fdf9a9963bfeda85b2f3b at
> "
> Such statements are already full-qualified. So, why are we getting this
> warning?
> Regards
> Mohammad
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18108) Data loss after a system restart of 3.11.17/4.1.4
[
https://issues.apache.org/jira/browse/CASSANDRA-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845231#comment-17845231
]
Stefan Miklosovic commented on CASSANDRA-18108:
---
Something very similar is happening in CASSANDRA-18956
> Data loss after a system restart of 3.11.17/4.1.4
> -
>
> Key: CASSANDRA-18108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18108
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Ke Han
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
>
> When we upgrade Cassandra from 3.11.17 to 4.0.12, we found a data loss during
> the upgrade process. This bug can also be triggered if simply performing a
> system restart for 3.11.17, 4.0.12 or 4.1.4.
> h1. Steps to reproduce
> Start a 3.11.15 or 4.1.4 Cassandra node using default configurations. Execute
> the following cqlsh commands.
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE IF NOT EXISTS ks.tb (c1 INT,c3 INT,c2 TEXT, PRIMARY KEY (c1 ))
> WITH speculative_retry = 'ALWAYS';
> INSERT INTO ks.tb (c1, c2) VALUES (2,'val');
> ALTER TABLE ks.tb DROP c2 ;
> ALTER TABLE ks.tb RENAME c1 TO c2; {code}
> Then execute a SELECT command, we get the correct data
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +--
> 2 | null
> (1 rows){code}
> Flush and stop the Cassandra daemon.
> {code:java}
> bin/nodetool flush
> bin/nodetool stopdaemon{code}
> Then restart the node.
> {code:java}
> bin/cassandra{code}
> Start cqlsh, and execute the same SELECT command. The data in ks.tb is lost.
> {code:java}
> cqlsh> SELECT * FROM ks.tb;
> c2 | c3
> +
> (0 rows){code}
> During the node restart, we found an error log about initializing the table,
> but it didn't prevent the system from starting up.
> {code:java}
> INFO [main] 2022-12-09 21:37:54,234 ColumnFamilyStore.java:432 -
> Initializing ks.tb
> ERROR [SSTableBatchOpen:1] 2022-12-09 21:37:54,237 CassandraDaemon.java:244 -
> Exception in thread Thread[SSTableBatchOpen:1,5,main]
> java.lang.AssertionError: null
> at
> org.apache.cassandra.db.PartitionColumns$Builder.add(PartitionColumns.java:161)
> at
> org.apache.cassandra.db.SerializationHeader$Component.toHeader(SerializationHeader.java:340)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:522)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:385)
> at
> org.apache.cassandra.io.sstable.format.SSTableReader$3.run(SSTableReader.java:570)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:84)
> at java.lang.Thread.run(Thread.java:750) {code}
> This bug can also be triggered if we perform an upgrade (with drain) from
> 3.11.17 to 4.0.12 or 4.1.4 and execute the SELECT command in the new version.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19604) Add support for BETWEEN operator
[
https://issues.apache.org/jira/browse/CASSANDRA-19604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845226#comment-17845226
]
Stefan Miklosovic commented on CASSANDRA-19604:
---
what's the fix version?
> Add support for BETWEEN operator
>
>
> Key: CASSANDRA-19604
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19604
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
>
> CQL support the {{>=}} and {{<=}} but does not support yet the {{BETWEEN}}
> operator. After CASSANDRA-19341 adding new operators should be much simpler
> and safer than it use to be.
> For the scope of this ticket {{BETWEEN}} support should be added for
> {{WHERE}} clauses of {{SELECT}} and {{DELETE}} queries (for single column and
> multi-column restrictions). NOT BETWEEN should be added and should be
> supported everywhere BETWEEN is.
> +Additional information for newcomers:+
> Parts that will need to be modified:
> * {{Lexer.g}} and {{Parser.g}} to add support for the new keyword and syntax
> * The {{Operator.class}} to add the new {{BETWEEN}} operator
> * Unit tests in {{SelectSingleColumnRelationTest}} and
> {{SelectMultiColumnRelationTest}} classes for the different types of columns
> (partition key, clustering, static and regular).
> * CQLSH auto completion in {{cql3handling.py}} and test for it in
> {{test_cqlsh_completion.py}}
> * Update the documentation
> Of course this is just an overview and some other parts might have to be
> changed as well.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19498) Error reading data from credential file
[
https://issues.apache.org/jira/browse/CASSANDRA-19498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17845224#comment-17845224
]
Stefan Miklosovic commented on CASSANDRA-19498:
---
[~bschoeni] any progress?
> Error reading data from credential file
> ---
>
> Key: CASSANDRA-19498
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19498
> Project: Cassandra
> Issue Type: Bug
> Components: Documentation, Tool/cqlsh
>Reporter: Slava
>Priority: Normal
> Fix For: 4.1.x, 5.0.x, 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The pylib/cqlshlib/cqlshmain.py code reads data from the credentials file,
> however, it is immediately ignored.
> https://github.com/apache/cassandra/blob/c9625e0102dab66f41d3ef2338c54d499e73a8c5/pylib/cqlshlib/cqlshmain.py#L2070
> {code:java}
> if not options.username:
> credentials = configparser.ConfigParser()
> if options.credentials is not None:
> credentials.read(options.credentials) # use the username
> from credentials file but fallback to cqlshrc if username is absent from the
> command line parameters
> options.username = username_from_cqlshrc if not options.password:
> rawcredentials = configparser.RawConfigParser()
> if options.credentials is not None:
> rawcredentials.read(options.credentials) # handling
> password in the same way as username, priority cli > credentials > cqlshrc
> options.password = option_with_default(rawcredentials.get,
> 'plain_text_auth', 'password', password_from_cqlshrc)
> options.password = password_from_cqlshrc{code}
> These corrections have been made in accordance with
> https://issues.apache.org/jira/browse/CASSANDRA-16983 and
> https://issues.apache.org/jira/browse/CASSANDRA-16456.
> The documentation does not indicate that AuthProviders can be used in the
> cqlshrc and credentials files.
> I propose to return the ability to use the legacy option of specifying the
> user and password in the credentials file in the [plain_text_auth] section.
> It is also required to describe the rules for using the credentials file in
> the documentation.
> I can make a corresponding pull request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844930#comment-17844930 ] Stefan Miklosovic commented on CASSANDRA-19556: --- [~jmckenzie] it's yours! > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844929#comment-17844929
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
[CASSANDRA-19556-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19556-5.0]
{noformat}
java11_pre-commit_tests
✓ j11_build7m 58s
✓ j11_cqlsh_dtests_py311 9m 57s
✓ j11_cqlsh_dtests_py311_vnode 9m 36s
✓ j11_cqlsh_dtests_py388m 52s
✓ j11_cqlsh_dtests_py38_vnode 9m 52s
✓ j11_cqlshlib_cython_tests 11m 25s
✓ j11_cqlshlib_tests 9m 39s
✓ j11_dtests 33m 33s
✓ j11_dtests_latest 36m 25s
✓ j11_dtests_vnode35m 29s
✓ j11_jvm_dtests 22m 39s
✓ j11_jvm_dtests_latest_vnode 18m 37s
✓ j11_simulator_dtests10m 28s
✓ j11_unit_tests 15m 33s
✓ j11_unit_tests_repeat 17m 36s
✓ j11_utests_latest 17m 40s
✓ j11_utests_latest_repeat18m 10s
✓ j11_utests_oa 15m 54s
✓ j11_utests_oa_repeat17m 12s
✓ j11_utests_system_keyspace_directory_repeat 15m 18s
✓ j17_cqlsh_dtests_py311 6m 20s
✓ j17_cqlsh_dtests_py311_vnode 6m 24s
✓ j17_cqlsh_dtests_py386m 15s
✓ j17_cqlsh_dtests_py38_vnode 6m 20s
✓ j17_cqlshlib_cython_tests7m 31s
✓ j17_cqlshlib_tests 6m 39s
✓ j17_dtests 32m 52s
✓ j17_dtests_latest33m 8s
✓ j17_dtests_vnode33m 13s
✓ j17_jvm_dtests 21m 57s
✓ j17_jvm_dtests_latest_vnode 17m 5s
✓ j17_unit_tests 14m 28s
✓ j17_unit_tests_repeat 13m 36s
✓ j17_utests_latest17m 3s
✓ j17_utests_latest_repeat13m 55s
✓ j17_utests_oa 19m 44s
✓ j17_utests_oa_repeat13m 18s
✕ j11_utests_system_keyspace_directory15m 11s
org.apache.cassandra.cql3.validation.operations.SelectTest
testCreatingUDFWithSameNameAsBuiltin_PrefersCompatibleArgs
java11_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4298/workflows/efcf5f01-6b32-4ca8-af12-a47f21564e26]
testCreatingUDFWithSameNameAsBuiltin_PrefersCompatibleArgs is just a flake
> Guardrail to block DDL/DCL queries
> --
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[
https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844886#comment-17844886
]
Stefan Miklosovic commented on CASSANDRA-19556:
---
Clean java 17 pre-commit on 5.0!
[CASSANDRA-19556-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19556-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build3m 55s
✓ j17_cqlsh_dtests_py311 5m 55s
✓ j17_cqlsh_dtests_py311_vnode 6m 31s
✓ j17_cqlsh_dtests_py38 6m 8s
✓ j17_cqlsh_dtests_py38_vnode 6m 33s
✓ j17_cqlshlib_cython_tests9m 51s
✓ j17_cqlshlib_tests 8m 55s
✓ j17_dtests 34m 9s
✓ j17_dtests_latest 33m 21s
✓ j17_dtests_vnode33m 44s
✓ j17_jvm_dtests 22m 21s
✓ j17_jvm_dtests_latest_vnode 16m 56s
✓ j17_unit_tests 15m 5s
✓ j17_unit_tests_repeat14m 6s
✓ j17_utests_latest 13m 52s
✓ j17_utests_latest_repeat15m 14s
✓ j17_utests_oa 13m 52s
✓ j17_utests_oa_repeat13m 30s
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4298/workflows/edba89d8-4d28-4fa9-9e79-1fe9a03275f4]
> Guardrail to block DDL/DCL queries
> --
>
> Key: CASSANDRA-19556
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19556
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Yuqi Yan
>Assignee: Yuqi Yan
>Priority: Normal
> Fix For: 5.0-rc, 5.x
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Sometimes we want to block DDL/DCL queries to stop new schemas being created
> or roles created. (e.g. when doing live-upgrade)
> For DDL guardrail current implementation won't block the query if it's no-op
> (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The
> guardrail check is added in apply() right after all the existence check)
> I don't have preference on either block every DDL query or check whether if
> it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS..
> at startup, which is no-op but will be blocked by this guardrail and failed
> to start.
>
> 4.1 PR: [https://github.com/apache/cassandra/pull/3248]
> trunk PR: [https://github.com/apache/cassandra/pull/3275]
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Fix Version/s: 5.0-rc > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.0-rc, 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19556: -- Status: Needs Committer (was: Review In Progress) > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844790#comment-17844790 ] Stefan Miklosovic commented on CASSANDRA-19556: --- [~yukei] I have created a PR against your branch which removes CASSANDRA-17495 and I refactored the tests little bit. To speed up things a little bit, I have created 5.0 PR here. Based on the ML link above, I think we need to remove CASSANDRA-17495 and incorporate these two guardrails into that. I think that we will work on 5.0 patch for now, I will take it from here if you do not mind. Does this sound OK for you? (1) https://github.com/Yukei7/cassandra/pull/1/files (2) https://github.com/apache/cassandra/pull/3298 > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1.5h > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19429:
--
Status: Needs Committer (was: Patch Available)
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1781#comment-1781 ] Stefan Miklosovic commented on CASSANDRA-19593: --- No rush necessary, indeed. On the other hand, I am happy to see that we can start to integrate features into TCM framework relatively early after its introduction with practical results and ease which show how well designed it was. My plan is to consolidate what I have and if it makes sense then I could finalize related CEP and get the voting done. Far from it for now. When it comes to more configuration committed into TCM, sure, but I see guardrails to be a little bit special and I would dedicate it its own set of transformations. Then all other config properties could be thrown into another category. > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844256#comment-17844256
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
To summarize the changes I did, I basically made sure that getCapacity() is not
used and we read size of caches from DatabaseDescriptor instead. Doing that
required a little bit more changes in DD, it is currently quite hairy to
resolve sizes and use getters / setters, there is another set of variables in
DatabaseDescriptor we do not need and everything goes through Config instead.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844205#comment-17844205
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
4.0 looks reasonable OK too, failing test_pkey_requirement is the fault of
recently merged CASSANDRA-19341
[CASSANDRA-19429-4.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19429-4.0]
{noformat}
java11_pre-commit_tests
java11_separate_tests
java8_pre-commit_tests
✓ j8_build 1m 33s
✓ j8_cqlsh-dtests-py2-no-vnodes5m 17s
✓ j8_cqlsh-dtests-py2-with-vnodes 6m 34s
✓ j8_cqlsh_dtests_py3 6m 55s
✓ j8_cqlsh_dtests_py3118m 10s
✓ j8_cqlsh_dtests_py311_vnode 6m 49s
✓ j8_cqlsh_dtests_py38 6m 12s
✓ j8_cqlsh_dtests_py38_vnode 5m 31s
✓ j8_cqlsh_dtests_py3_vnode5m 11s
✓ j8_cqlshlib_tests 9m 6s
✓ j8_jvm_dtests14m 9s
✓ j11_cqlsh_dtests_py3_vnode 5m 25s
✓ j11_cqlsh_dtests_py38_vnode 5m 33s
✓ j11_cqlsh_dtests_py385m 34s
✓ j11_cqlsh_dtests_py311_vnode 5m 33s
✓ j11_cqlsh_dtests_py311 5m 45s
✓ j11_cqlsh-dtests-py2-with-vnodes 5m 37s
✓ j11_cqlsh-dtests-py2-no-vnodes 5m 38s
✕ j8_dtests 31m 17s
json_test.TestJsonFullRowInsertSelect test_pkey_requirement
✕ j8_dtests_vnode 36m 54s
json_test.TestJsonFullRowInsertSelect test_pkey_requirement
✕ j8_unit_tests 10m 45s
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
✕ j8_utests_system_keyspace_directory 9m 40s
org.apache.cassandra.cql3.BatchTest testNonCounterInLoggedBatch
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
✕ j11_unit_tests7m 8s
org.apache.cassandra.cql3.MemtableSizeTest testTruncationReleasesLogSpace
✕ j11_dtests_vnode43m 44s
bootstrap_test.TestBootstrap test_bootstrap_binary_disabled
json_test.TestJsonFullRowInsertSelect test_pkey_requirement
✕ j11_dtests 31m 20s
json_test.TestJsonFullRowInsertSelect test_pkey_requirement
✕ j11_cqlsh_dtests_py3 5m 21s
compression_test.TestCompression test_compression_cql_options
java8_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4287/workflows/62e98e6f-2687-4ba0-943e-17b990ad5737]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4287/workflows/946942f4-66a9-4aa2-aed7-581dda35f814]
[java8_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4287/workflows/151e79a6-1494-40c6-9c22-3ac71cf6161b]
[java8_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4287/workflows/3db92b5a-3faf-440d-9b31-c40e56fb0778]
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance
[jira] [Comment Edited] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844190#comment-17844190
]
Stefan Miklosovic edited comment on CASSANDRA-19341 at 5/7/24 8:11 AM:
---
[~blerer] [~e.dimitrova] dtest alignement is failing
json_test.py::TestJsonFullRowInsertSelect::test_pkey_requirement on 4.0 (at
least).
was (Author: smiklosovic):
[~blerer] [~e.dimitrova] dtest alignement is failing json_test.py on 4.0 (at
least).
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19341) Relation and Restriction hierarchies are too complex and error prone
[
https://issues.apache.org/jira/browse/CASSANDRA-19341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17844190#comment-17844190
]
Stefan Miklosovic commented on CASSANDRA-19341:
---
[~blerer] [~e.dimitrova] dtest alignement is failing json_test.py on 4.0 (at
least).
> Relation and Restriction hierarchies are too complex and error prone
>
>
> Key: CASSANDRA-19341
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19341
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Benjamin Lerer
>Assignee: Benjamin Lerer
>Priority: Normal
> Fix For: 5.1
>
> Time Spent: 32h 40m
> Remaining Estimate: 0h
>
> The {{Relation}} and {{Restriction}} hierarchy have been designed when C* was
> only supporting a limited amount of operators and columns expressions (single
> column, multi-column and token expressions). Over time they have grown in
> complexity making the code harder to understand and modify and error prone.
> Their design is also resulting in unnecessary limitations that could be
> easily lifted, like the ability to accept different predicates on the same
> column.
> Today adding a new operator requires the addition of a lot of glue code and
> surgical changes accross the CQL layer. Making patch for features such as
> CASSANDRA-18584 much complex than it should be.
> The goal of this ticket is to simplify the {{Relation}} and {{Restriction}}
> hierarchies and modify operator class so that adding new operators requires
> only changes to the {{Operator}} class and ANTLR file.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843813#comment-17843813
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
I think that size and capacity are trully two different concepts as already
explained by Brandon and myself and I believe that having capacity set to 0
practically disables a respective cache.
CI for 4.1 looks good with the below patch. I identified couple more places
where we could use reading the capacity from DatabaseDescriptor rather than
calling getCapacity() on the cache to see if it is bigger than zero to proceed.
One just needs to be cautious to not forget to update DatabaseDescriptor when
capacity is set to zero, e.g. from JMX etc if we are going to use DD as the
source of truth whether a cache is enabled or not.
For other branches, this ticket, as I write this, specifies only 4.0 and 4.1 ax
fix versions but that should be extended up to trunk.
This is all being said if there is an appetite to do this across all versions
instead of just fixing the trace messages as suggested by Jon. The bellow build
tells me that we are on something here and it would be just a matter of
applying this elsewhere.
[CASSANDRA-19429-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19429-4.1]
{noformat}
java11_pre-commit_tests
java11_separate_tests
java8_pre-commit_tests
✓ j8_build 6m 53s
✓ j8_cqlsh_dtests_py3 6m 53s
✓ j8_cqlsh_dtests_py3118m 26s
✓ j8_cqlsh_dtests_py311_vnode 6m 53s
✓ j8_cqlsh_dtests_py38 8m 3s
✓ j8_cqlsh_dtests_py38_vnode 7m 40s
✓ j8_cqlsh_dtests_py3_vnode8m 16s
✓ j8_cqlshlib_cython_tests13m 32s
✓ j8_cqlshlib_tests 11m 44s
✓ j8_dtests 33m 23s
✓ j8_dtests_vnode 38m 26s
✓ j8_jvm_dtests 19m 30s
✓ j8_jvm_dtests_vnode 12m 23s
✓ j8_simulator_dtests 5m 51s
✓ j11_jvm_dtests_vnode11m 50s
✓ j11_jvm_dtests 19m 47s
✓ j11_dtests_vnode 35m 6s
✓ j11_dtests 34m 46s
✓ j11_cqlshlib_tests 6m 35s
✓ j11_cqlshlib_cython_tests9m 27s
✓ j11_cqlsh_dtests_py3_vnode 5m 47s
✓ j11_cqlsh_dtests_py38_vnode 6m 7s
✓ j11_cqlsh_dtests_py385m 41s
✓ j11_cqlsh_dtests_py311_vnode 5m 50s
✓ j11_cqlsh_dtests_py311 5m 56s
✓ j11_cqlsh_dtests_py3 5m 38s
✕ j8_unit_tests9m 53s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
org.apache.cassandra.net.ConnectionTest testMessageDeliveryOnReconnect
✕ j8_utests_system_keyspace_directory 11m 5s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
✕ j11_unit_tests 8m 12s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
java8_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4285/workflows/7470a92f-1cb3-487d-9d0a-dd1f781a79e8]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4285/workflows/2116e61d-1e6a-4589-85e7-1980acfbdb05]
[java8_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4285/workflows/30501a49-c2b0-4aaf-a504-f087f27e88f7]
[java8_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4285/workflows/232134f1-5956-4346-afa3-bd556b6c5f60]
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843726#comment-17843726 ] Stefan Miklosovic commented on CASSANDRA-19556: --- https://lists.apache.org/thread/zsw12lnsoy5h3334s8hrwsh8lfz5pfh4 > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843588#comment-17843588
]
Stefan Miklosovic edited comment on CASSANDRA-19429 at 5/5/24 8:51 PM:
---
[~rustyrazorblade] there is 63 instances in the production codebase where we do
not check tracing level and just log. We should take more holistic approach
here and just fix this everywhere which would be probably better suited for a
new ticket.
Anyway, I think we should still deliver this with the changes OP suggested (and
myself improved on top of that). This seems like a fairly innocent change and I
do not see where it might go wrong. We should double check that our
understanding of getSize vs getCapacity is correct though.
was (Author: smiklosovic):
[~rustyrazorblade] there is 63 instances in the production codebase where we do
not check tracing level and just log. We should take more holistic approach
here and just fix this everywhere which would be probably better suited for a
new ticket.
Anyway, I think we should still deliver this with the changes OP suggested (and
myself improved on top of that). This seems like a fairy innocent change and I
do not see where it might go wrong. We should double check that our
understanding of getSize vs getCapacity is correct though.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843588#comment-17843588
]
Stefan Miklosovic edited comment on CASSANDRA-19429 at 5/5/24 8:50 PM:
---
[~rustyrazorblade] there is 63 instances in the production codebase where we do
not check tracing level and just log. We should take more holistic approach
here and just fix this everywhere which would be probably better suited for a
new ticket.
Anyway, I think we should still deliver this with the changes OP suggested (and
myself improved on top of that). This seems like a fairy innocent change and I
do not see where it might go wrong. We should double check that our
understanding of getSize vs getCapacity is correct though.
was (Author: smiklosovic):
[~rustyrazorblade] there is 63 instances in the production codebase where we do
not check tracing level and just log. We should take more holistic approach
here and just fix this everywhere which would be probably better suited of a
new ticket.
Anyway, I think we should still deliver this with the changes OP suggested (and
myself improved on top of that). This seems like a fairy innocent change and I
do not see where it might go wrong. We should double check that our
understanding of getSize vs getCapacity is correct though.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19429) Remove lock contention generated by getCapacity function in SSTableReader
[
https://issues.apache.org/jira/browse/CASSANDRA-19429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843588#comment-17843588
]
Stefan Miklosovic commented on CASSANDRA-19429:
---
[~rustyrazorblade] there is 63 instances in the production codebase where we do
not check tracing level and just log. We should take more holistic approach
here and just fix this everywhere which would be probably better suited of a
new ticket.
Anyway, I think we should still deliver this with the changes OP suggested (and
myself improved on top of that). This seems like a fairy innocent change and I
do not see where it might go wrong. We should double check that our
understanding of getSize vs getCapacity is correct though.
> Remove lock contention generated by getCapacity function in SSTableReader
> -
>
> Key: CASSANDRA-19429
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19429
> Project: Cassandra
> Issue Type: Bug
> Components: Local/SSTable
>Reporter: Dipietro Salvatore
>Assignee: Dipietro Salvatore
>Priority: Normal
> Fix For: 4.0.x, 4.1.x
>
> Attachments: Screenshot 2024-02-26 at 10.27.10.png, Screenshot
> 2024-02-27 at 11.29.41.png, Screenshot 2024-03-19 at 15.22.50.png,
> asprof_cass4.1.3__lock_20240216052912lock.html,
> image-2024-03-08-15-51-30-439.png, image-2024-03-08-15-52-07-902.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Profiling Cassandra 4.1.3 on large AWS instances, a high number of lock
> acquires is measured in the `getCapacity` function from
> `org/apache/cassandra/cache/InstrumentingCache` (1.9M lock acquires per 60
> seconds). Based on our tests on r8g.24xlarge instances (using Ubuntu 22.04),
> this limits the CPU utilization of the system to under 50% when testing at
> full load and therefore limits the achieved throughput.
> Removing the lock contention from the SSTableReader.java file by replacing
> the call to `getCapacity` with `size` achieves up to 2.95x increase in
> throughput on r8g.24xlarge and 2x on r7i.24xlarge:
> |Instance type|Cass 4.1.3|Cass 4.1.3 patched|
> |r8g.24xlarge|168k ops|496k ops (2.95x)|
> |r7i.24xlarge|153k ops|304k ops (1.98x)|
>
> Instructions to reproduce:
> {code:java}
> ## Requirements for Ubuntu 22.04
> sudo apt install -y ant git openjdk-11-jdk
> ## Build and run
> CASSANDRA_USE_JDK11=true ant realclean && CASSANDRA_USE_JDK11=true ant jar &&
> CASSANDRA_USE_JDK11=true ant stress-build && rm -rf data && bin/cassandra -f
> -R
> # Run
> bin/cqlsh -e 'drop table if exists keyspace1.standard1;' && \
> bin/cqlsh -e 'drop keyspace if exists keyspace1;' && \
> bin/nodetool clearsnapshot --all && tools/bin/cassandra-stress write
> n=1000 cl=ONE -rate threads=384 -node 127.0.0.1 -log file=cload.log
> -graph file=cload.html && \
> bin/nodetool compact keyspace1 && sleep 30s && \
> tools/bin/cassandra-stress mixed ratio\(write=10,read=90\) duration=10m
> cl=ONE -rate threads=406 -node localhost -log file=result.log -graph
> file=graph.html
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843343#comment-17843343 ] Stefan Miklosovic commented on CASSANDRA-19556: --- I think that having it more granular is just overkill. We have that table-centric guardrail already in place so we have to live with it. We might have this new ddl which might be considered as a superset of 17495. So when this ddl guardrail is disabled, we cant do anything with tables. If it is enabled, we can still forbid tables modifications. > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19593) Transactional Guardrails
[ https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19593: -- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Transactional Guardrails > > > Key: CASSANDRA-19593 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19593 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails, Transactional Cluster Metadata >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > I think it is time to start to think about this more seriously. TCM is > getting into pretty nice shape and we might start to investigate how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19593) Transactional Guardrails
[
https://issues.apache.org/jira/browse/CASSANDRA-19593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843327#comment-17843327
]
Stefan Miklosovic commented on CASSANDRA-19593:
---
I took CEP-24, applied CASSANDRA-19553 and I integrated with with TCM. So it
behaves like this:
{code}
cqlsh> select * from system_guardrails.flags where name = 'simplestrategy';
name | value
+---
simplestrategy | True
{code}
so lets disable that ...
{code}
cqlsh> update system_guardrails.flags set value = false where name =
'simplestrategy';
cqlsh> select * from system_guardrails.flags where name = 'simplestrategy';
name | value
+---
simplestrategy | False
{code}
in the logs:
{code}
INFO [GlobalLogFollower] 2024-05-03 21:18:27,578 LocalLog.java:493 - Enacted
EXECUTED {Flag{name='simplestrategy', flag=false}}. New tail is Epoch{epoch=9}
INFO [GlobalLogFollower] 2024-05-03 21:18:27,579 GuardrailsOptions.java:1089 -
Updated simplestrategy_enabled from true to false
{code}
What happens is that this is integrated with TCM so this setting survives
restart, after it is restarted, that setting is still false.
Obviously, this will be false on every node in the cluster so there is just one
CQL command to drive all guardrails, globally, for whole cluster.
This is very soon to open this ticket for a review. I think there is still
unknowns and to-dos but TCM poc seems to be viable.
Few things:
I do not want to commit guardrail transformation when such configuration would
be forbidden. For example, when I set fail threshold lower than warn threshold,
I should not commit this at all and I should detect this before committing.
This is not easy to do because we would need to validate the guardrail before
actually executing that. Because if the guardrail is executed as part of the
validation / in respective flag vtable, then I would run through that logic for
the second time in the post-commit listener.
> Transactional Guardrails
>
>
> Key: CASSANDRA-19593
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19593
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails, Transactional Cluster Metadata
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 5.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I think it is time to start to think about this more seriously. TCM is
> getting into pretty nice shape and we might start to investigate how to do
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19556) Guardrail to block DDL/DCL queries
[ https://issues.apache.org/jira/browse/CASSANDRA-19556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17843095#comment-17843095 ] Stefan Miklosovic commented on CASSANDRA-19556: --- [~jmckenzie] would you mind if CASSANDRA-17495 was extended to something like this? That ticket guardrails just schema modifications on tables. What about more holistic approach to forbid all schema modifications completely? Why have we stopped at tables? https://github.com/apache/cassandra/pull/3277/files > Guardrail to block DDL/DCL queries > -- > > Key: CASSANDRA-19556 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19556 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Yuqi Yan >Assignee: Yuqi Yan >Priority: Normal > Fix For: 5.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Sometimes we want to block DDL/DCL queries to stop new schemas being created > or roles created. (e.g. when doing live-upgrade) > For DDL guardrail current implementation won't block the query if it's no-op > (e.g. CREATE TABLE...IF NOT EXISTS, but table already exists, etc. The > guardrail check is added in apply() right after all the existence check) > I don't have preference on either block every DDL query or check whether if > it's no-op here. Just we have some users always run CREATE..IF NOT EXISTS.. > at startup, which is no-op but will be blocked by this guardrail and failed > to start. > > 4.1 PR: [https://github.com/apache/cassandra/pull/3248] > trunk PR: [https://github.com/apache/cassandra/pull/3275] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19600) Resolve the oldest hints just from descriptors and current writer if available
[ https://issues.apache.org/jira/browse/CASSANDRA-19600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19600: -- Fix Version/s: 5.0-beta2 5.1-alpha1 (was: 5.x) (was: 5.0.x) Since Version: 4.0.0 Source Control Link: https://github.com/apache/cassandra/commit/326bf4b3f5a9ba2de3bd3962babd343164e59bf8 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Resolve the oldest hints just from descriptors and current writer if available > -- > > Key: CASSANDRA-19600 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19600 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0-beta2, 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > We should not resolve hints from buffers as these are just very short-lived / > transient data structures and resolving "the oldest hints" from buffers too > just does not make sense when we should just look into descriptors and > current writer's descriptor at most. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19600) Resolve the oldest hints just from descriptors and current writer if available
[ https://issues.apache.org/jira/browse/CASSANDRA-19600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842982#comment-17842982 ] Stefan Miklosovic commented on CASSANDRA-19600: --- trunk repeats on added test look good https://app.circleci.com/pipelines/github/instaclustr/cassandra/4275/workflows/cd8a579f-e009-42c7-99ff-27ebaae3bb9a > Resolve the oldest hints just from descriptors and current writer if available > -- > > Key: CASSANDRA-19600 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19600 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 10m > Remaining Estimate: 0h > > We should not resolve hints from buffers as these are just very short-lived / > transient data structures and resolving "the oldest hints" from buffers too > just does not make sense when we should just look into descriptors and > current writer's descriptor at most. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842970#comment-17842970
]
Stefan Miklosovic commented on CASSANDRA-19606:
---
+1
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19606) Fix building debian packages
[
https://issues.apache.org/jira/browse/CASSANDRA-19606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17842959#comment-17842959
]
Stefan Miklosovic commented on CASSANDRA-19606:
---
I verified that using Brandon's patch and executing
".build/docker/build-debian.sh" on cassandra-5.0 branch produces the deb
package and the docker build does not loop.
> Fix building debian packages
>
>
> Key: CASSANDRA-19606
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19606
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Urgent
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 5.0.x, 5.x
>
>
> Trying to run cassandra-deb-packaging.sh will result in the docker image
> looping:
> {noformat}
> Errors were encountered while processing:
> ed
> quilt
> cassandra-build-deps
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> (Reading database ... 36721 files and directories currently installed.)
> Removing cassandra-build-deps (5.0~beta2-20240501gitae9be29918) ...
> mk-build-deps: Unable to install all build-dep packages
> mk-build-deps failed… trying again after 10s…
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
