[cassandra-website] branch dependabot/npm_and_yarn/site-ui/minimist-1.2.6 created (now adf4e2b3)
This is an automated email from the ASF dual-hosted git repository. github-bot pushed a change to branch dependabot/npm_and_yarn/site-ui/minimist-1.2.6 in repository https://gitbox.apache.org/repos/asf/cassandra-website.git at adf4e2b3 Bump minimist from 1.2.5 to 1.2.6 in /site-ui No new revisions were added by this update. - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522999#comment-17522999 ] Stefan Miklosovic commented on CASSANDRA-16456: --- Yes, that what Bowen said. I am all for the simplification. I get that it might be little bit frustrating to constantly change the goal post but I guess that is the part of the process and some creativity needs to be involved. For patches like these, which are facing a user, what helps me is to put myself in his shoes for a while and try to understand if I would like to use what I just did. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17180) Implement heartbeat service to know last time Cassandra node was up
[ https://issues.apache.org/jira/browse/CASSANDRA-17180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522994#comment-17522994 ] Stefan Miklosovic commented on CASSANDRA-17180: --- Anybody willing to take a look at this? Doing the pinging round all over again [~jmckenzie] [~e.dimitrova] [~paulo] [~adelapena] I want this to see in 4.1 please. It is 10 minutes patch to review, I am trying to merge this for half a year already. > Implement heartbeat service to know last time Cassandra node was up > --- > > Key: CASSANDRA-17180 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17180 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > As already discussed on ML, it would be nice to have a service which would > periodically write timestamp to a file signalling it is up / running. > Then, on the startup, we would read this file and we would determine if there > is some table which gc grace is behind this time and we would fail the start > so we would prevent zombie data to be likely spread around a cluster. > https://lists.apache.org/thread/w4w5t2hlcrvqhgdwww61hgg58qz13glw -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17366:
-
Status: Patch Available (was: Open)
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522978#comment-17522978
]
Brandon Williams edited comment on CASSANDRA-17366 at 4/15/22 11:30 PM:
These tests set up and then stop a cluster, subsequently starting it with some
combination of seeds, and then nodes in parallel. The problem is that the
setup doesn't guarantee it will wait long enough for the cluster to be
completely established, though C* is fast enough to do so anyway, _almost_ all
of the time. To ensure the setup is complete before shutting down, the nodes
should wait for the CQL interface to become available after the initial
startup. [This dtest
branch|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17366] does
that, and here's 400 runs on
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/438/workflows/df01fde1-1ff1-4007-bdc2-a9de8e358a16/jobs/5145]
and
[trunk|https://app.circleci.com/pipelines/github/driftx/cassandra/439/workflows/c00617e8-904c-44d7-9f4f-de565e4878cf/jobs/5143].
was (Author: brandon.williams):
These tests setup and then stop a cluster, subsequently starting it with some
combination of seeds, and then nodes in parallel. The problem is that the
setup doesn't guarantee it will wait long enough for the cluster to be
completely established, though C* is fast enough to do so anyway, _almost_ all
of the time. To ensure the setup is complete before shutting down, the nodes
should wait for the CQL interface to become available after the initial
startup. [This dtest
branch|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17366] does
that, and here's 400 runs on
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/438/workflows/df01fde1-1ff1-4007-bdc2-a9de8e358a16/jobs/5145]
and
[trunk|https://app.circleci.com/pipelines/github/driftx/cassandra/439/workflows/c00617e8-904c-44d7-9f4f-de565e4878cf/jobs/5143].
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.ski
[jira] [Updated] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17379:
Reviewers: Ekaterina Dimitrova
Status: Review In Progress (was: Patch Available)
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-14752:
Status: Ready to Commit (was: Review In Progress)
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522979#comment-17522979
]
Ekaterina Dimitrova commented on CASSANDRA-14752:
-
Starting commit, pending CI:
[3.0|https://github.com/apache/cassandra/compare/cassandra-3.0...ekaterinadimitrova2:14752-3.0]
|
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1539/workflows/45e492b7-bdb7-43d3-ac9c-194675661b86]
[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...ekaterinadimitrova2:14752-3.11?expand=1]
|
[CI|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1540/workflows/92dd6163-c11a-41e7-8156-acfff45010db]
[4.0|https://github.com/apache/cassandra/compare/cassandra-4.0...ekaterinadimitrova2:14752-4.0?expand=1]
| [CI
J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1541/workflows/5a606780-788f-4ce7-a769-47f2c91e9398]
| [CI
J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1541/workflows/cc29f66c-3679-48ca-9c49-388106a02162]
[trunk|https://github.com/apache/cassandra/compare/trunk...ekaterinadimitrova2:14752-trunk?expand=1]
| [CI
J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1542/workflows/823731cb-54f6-4208-a619-6e77af751fa0]
| [CI
J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1542/workflows/11215d18-48d0-4b7a-938b-0b2c0e4dc3f8]
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522978#comment-17522978
]
Brandon Williams commented on CASSANDRA-17366:
--
These tests setup and then stop a cluster, subsequently starting it with some
combination of seeds, and then nodes in parallel. The problem is that the
setup doesn't guarantee it will wait long enough for the cluster to be
completely established, though C* is fast enough to do so anyway, _almost_ all
of the time. To ensure the setup is complete before shutting down, the nodes
should wait for the CQL interface to become available after the initial
startup. [This dtest
branch|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17366] does
that, and here's 400 runs on
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/438/workflows/df01fde1-1ff1-4007-bdc2-a9de8e358a16/jobs/5145]
and
[trunk|https://app.circleci.com/pipelines/github/driftx/cassandra/439/workflows/c00617e8-904c-44d7-9f4f-de565e4878cf/jobs/5143].
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.C
[jira] [Commented] (CASSANDRA-17150) Guardrails for disk usage
[
https://issues.apache.org/jira/browse/CASSANDRA-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522953#comment-17522953
]
Ekaterina Dimitrova commented on CASSANDRA-17150:
-
Solid patch as usual, it just took me some time to wrap up my mind as I see
this work first time.
I left small questions&comments.
I am thinking it is good to verify with [~jasonstack] the new approach you took
in regards to the calculations. Maybe it was considered during the initial
discussions and he has something to add? Or maybe it's just me making noise. :)
1 thing I noticed is we will hit warnings faster. Probably it is more accurate
but I am also wondering about recommendations for users in order not to corner
themselves.
We need also NEWS.txt entry.
> Guardrails for disk usage
> -
>
> Key: CASSANDRA-17150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17150
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add guardrails for disk usage establishing soft/hard limits on the percentage
> of used disk space. For example:
> {code}
> # Warning threshold to warn when local disk usage exceeds threshold. Valid
> values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_warn_threshold: -1
> # Failure threshold to reject write requests if replica disk usage exceeds
> threshold. Valid values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_failure_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522942#comment-17522942 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 8:08 PM: -- Does it make sense to change the title of this ticket/PR to reflect it clearly - "Adding support for TLS client authentication for internode communication"? was (Author: maulin.vasavada): Does it make sense to change the title of this ticket to reflect it clearly - "Adding support for TLS client authentication for internode communication"? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522942#comment-17522942 ] Maulin Vasavada commented on CASSANDRA-17513: - Does it make sense to change the title of this ticket to reflect it clearly - "Adding support for TLS client authentication for internode communication"? > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 50m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522900#comment-17522900 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/15/22 5:07 PM: -- Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. I'll also take a look at the code changes in the PR and provide any comments I may have. Thanks [~Jyothsnakonisa] for working on the changes. was (Author: maulin.vasavada): Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522900#comment-17522900 ] Maulin Vasavada commented on CASSANDRA-17513: - Btw, [this|https://www.ssl2buy.com/wiki/what-is-the-difference-between-client-and-server-certificates#:~:text=Client%20certificates%20are%20utilized%20for,certificates%20are%20being%20thoroughly%20used.] was useful for me to clearly understand the difference between client and server certs. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522898#comment-17522898 ] Jordan West commented on CASSANDRA-17547: - I may have linked the wrong ticket. I thought that was the parent one for all new doc stuff and I assume this got caught up in the doc move (per the cassandra-dev thread it was expected to a degree) > Documentation from Partition Denylist Lost in Document Migration + Minor Fixes > -- > > Key: CASSANDRA-17547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > The documentation added in > https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the > documents were migrated to the new format. We just need to bring the doc > back. Along with this fix there are a couple minor edits to make to the > document itself to correct the examples. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522894#comment-17522894 ] Maulin Vasavada commented on CASSANDRA-17513: - Thanks [~djoshi] that clarifies it for me. Also I agree with your operational overhead comment. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522889#comment-17522889 ] Bowen Song commented on CASSANDRA-16456: Hi [~bhouser] , as Stefan has pointed out, there's no need for backward compatibility for the [plain_text_auth] section name in the credentials file, because the change hasn't been released yet. It makes a lot more sense to avoid having two names for the same thing in the same file. I would purpose get rid of the [plain_text_auth] section from the credentials file. Make the credentials from the CLI options have priority over them from the [PlainTextAuthProvider] section in credentials file, and then fallback to username & password from the [authentciation] section in cqlshrc. As of the class name and module name, they can live in the existing [authentication] section in cqlshrc file, or a new [auth_provider] section in the same file, because they are not credentials and don't need to be protected as secrets. BTW, I don't see the need of of a new section for them, as they are undoubtedly a part of the authentication options. Use your best judgement here. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522888#comment-17522888 ] Josh McKenzie edited comment on CASSANDRA-17547 at 4/15/22 4:47 PM: ping [~polandll] - if this was actually caused by the move in CASSANDRA-16763 (new docs added during review cycle and missed maybe?), we should probably invest a little time in diffing a snapshot of the documentation on the commit before 16763 [and it|https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=05b0eaecad5e40390352a4e182179a29ac784372] to make sure nothing else was inadvertently dropped. And [~jwest] - we linked CASSANDRA-16761 here; was it that or the doc move that we think this got caught up in? was (Author: jmckenzie): ping [~polandll] - if this was actually caused by the move in CASSANDRA-16761 (new docs added during review cycle and missed maybe?), we should probably invest a little time in diffing a snapshot of the documentation on the commit before 16763 [and it|https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=05b0eaecad5e40390352a4e182179a29ac784372] to make sure nothing else was inadvertently dropped. > Documentation from Partition Denylist Lost in Document Migration + Minor Fixes > -- > > Key: CASSANDRA-17547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > The documentation added in > https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the > documents were migrated to the new format. We just need to bring the doc > back. Along with this fix there are a couple minor edits to make to the > document itself to correct the examples. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522888#comment-17522888 ] Josh McKenzie commented on CASSANDRA-17547: --- ping [~polandll] - if this was actually caused by the move in CASSANDRA-16761 (new docs added during review cycle and missed maybe?), we should probably invest a little time in diffing a snapshot of the documentation on the commit before 16763 [and it|https://gitbox.apache.org/repos/asf?p=cassandra.git;a=commit;h=05b0eaecad5e40390352a4e182179a29ac784372] to make sure nothing else was inadvertently dropped. > Documentation from Partition Denylist Lost in Document Migration + Minor Fixes > -- > > Key: CASSANDRA-17547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > The documentation added in > https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the > documents were migrated to the new format. We just need to bring the doc > back. Along with this fix there are a couple minor edits to make to the > document itself to correct the examples. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522869#comment-17522869 ] Stefan Miklosovic commented on CASSANDRA-16456: --- Great! I will take a look next week, thank you. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522859#comment-17522859 ] Brian Houser commented on CASSANDRA-16456: -- Ok I updated this to make PlainTextAuthProvider work transparently with the new auth provider process. AuthProviders now only read a single key [auth_provider] in the cqlshrc file (instead of [auth_provider_config]), and will read the credentials file under the name of the class (example: [PlainTextAuthProvider]). If we are using legacy elements (passing a username or a password, or using older authentication properties, etc), it will handle things in the old way rather than load a non PlainText auth provider. If you specify PlainTextAuthProvider explicitly as your auth_provider section, it can use legacy way and new way of specfiying properties (older way trumps the new one). Basically we use username and password properties... CLI args > credentials [plain_text_auth] > [authentciation section]in cqlshrc > [PlainTextAuthProvider]section in credentials > [auth_provider]section in cqlshrc (if auth provider is PlainTextAuthProvider). I have tested manually using source command, login command, and have connected under a variety of scenarios for PlainTextAuthProvider (new, old, etc), as well as SigV4. I've also added a number of unit tests and done a bit of refactoring to make the code a little smoother. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
