[jira] [Updated] (CASSANDRA-17334) Pre hashed passwords in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17334:
Description:
As seen on CASSANDRA-16801 and friends we are working across the system with
plain text passwords. These can be unintentionally revealed by intermediate
systems. Allowing the use of hashed passwords should mitigate that. The idea is
to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
Examples:
{noformat}
CREATE ROLE foo WITH login = true AND hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
ALTER ROLE foo WITH hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
{noformat}
To generate the password hash, there will be a new tool {{hash_password}} in
resources/cassandra/bin
was:As seen on CASSANDRA-16801 and friends we are working across the system
with plain text passwords. These can be unintentionally revealed by
intermediate systems. Allowing the use of hashed passwords should mitigate that.
> Pre hashed passwords in CQL
> ---
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
--
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-17383) Fix user_functions_test.py::TestUserFunctions::test_udf_overload
[ https://issues.apache.org/jira/browse/CASSANDRA-17383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492465#comment-17492465 ] Benjamin Lerer commented on CASSANDRA-17383: Sorry, I missed that part when I reviewed the patch. > Fix user_functions_test.py::TestUserFunctions::test_udf_overload > > > Key: CASSANDRA-17383 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17383 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Manish Ghildiyal >Priority: Normal > Fix For: 4.1, 3.0.x, 3.11.x, 4.0.x > > > user_functions_test.py::TestUserFunctions::test_udf_overload > is failing after CASSANDRA-17190 on all branches except trunk. > -- 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-17334) Pre hashed passwords in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-17334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17334:
Description:
As seen on CASSANDRA-16801 and friends we are working across the system with
plain text passwords. These can be unintentionally revealed by intermediate
systems. Allowing the use of hashed passwords should mitigate that. The idea is
to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
Examples:
{noformat}
CREATE ROLE foo WITH login = true AND hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
ALTER ROLE foo WITH hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
{noformat}
To generate the password hash, there will be a new tool {{hash_password}} in
resources/cassandra/bin
Based on original works from [~snazy]
was:
As seen on CASSANDRA-16801 and friends we are working across the system with
plain text passwords. These can be unintentionally revealed by intermediate
systems. Allowing the use of hashed passwords should mitigate that. The idea is
to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
Examples:
{noformat}
CREATE ROLE foo WITH login = true AND hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
ALTER ROLE foo WITH hashed password =
'$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
{noformat}
To generate the password hash, there will be a new tool {{hash_password}} in
resources/cassandra/bin
> Pre hashed passwords in CQL
> ---
>
> Key: CASSANDRA-17334
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17334
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Authorization
>Reporter: Berenguer Blasi
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.1
>
>
> As seen on CASSANDRA-16801 and friends we are working across the system with
> plain text passwords. These can be unintentionally revealed by intermediate
> systems. Allowing the use of hashed passwords should mitigate that. The idea
> is to add a new option {{HASHED PASSWORD}} for {{CREATE/ALTER ROLE/USER}}.
> Examples:
> {noformat}
> CREATE ROLE foo WITH login = true AND hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> ALTER ROLE foo WITH hashed password =
> '$2a$10$JSJEMFm6GeaW9XxT5JIheuEtPvat6i7uKbnTcxX3c1wshIIsGyUtG';
> {noformat}
> To generate the password hash, there will be a new tool {{hash_password}} in
> resources/cassandra/bin
> Based on original works from [~snazy]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17384) WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra Release"
[ https://issues.apache.org/jira/browse/CASSANDRA-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17384: - Assignee: Josh McKenzie > WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra > Release" > --- > > Key: CASSANDRA-17384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17384 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Josh McKenzie >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Behind the scenes of an Apache Cassandra Release" > If this blog cannot be published by the *February 17, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- 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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492515#comment-17492515
]
Benjamin Lerer commented on CASSANDRA-17198:
[~subkanthi] Looking at the patch there are several point that would need to be
changed.
* Without indexes LIKE restrictions can only be performed through filtering.
That means that the queries should fail if {{ALLOW FILTERING}} is not
specified. As shown by some of the unit tests it is not the case. This should
be changed for clustering columns by modifying
{{StatementRestrictions.processClusteringColumnRestrictions}} and for the
partition keys by modifying {{PartitionKeySingleRestrictionSet.needFiltering}}.
For that last one you will need to add a new {{hasLike}} method to
{{Restrictions}} and use it.
* If the user attempt to use a LIKE restriction on a column which is not a
string type the error can be confusing. The logic within
{{SingleColumnRelation.newLikeRestriction}} can be changed to validate that the
type of the receiver (for a LIKE you are guaranty to have only one) is a
instanceof StringType.
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> +Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
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-17198) Allow to filter using LIKE predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-17198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492515#comment-17492515
]
Benjamin Lerer edited comment on CASSANDRA-17198 at 2/15/22, 10:34 AM:
---
[~subkanthi] Looking at the patch there are several point that would need to be
changed.
* Without indexes LIKE restrictions can only be performed through filtering.
That means that the queries should fail if {{ALLOW FILTERING}} is not
specified. As shown by some of the unit tests it is not the case. This should
be changed for clustering columns by modifying
{{StatementRestrictions.processClusteringColumnRestrictions}} and for the
partition keys by modifying {{PartitionKeySingleRestrictionSet.needFiltering}}.
For that last one you will need to add a new {{hasLike}} method to
{{Restrictions}} and use it.
* If the user attempt to use a LIKE restriction on a column which is not a
string type the error can be confusing. The logic within
{{SingleColumnRelation.newLikeRestriction}} can be changed to validate that the
type of the receiver (for a LIKE you are guaranty to have only one) is a
instanceof StringType.
* It should be good to test that LIKE statement cannot be used on UPDATE or
DELETE statements.
was (Author: blerer):
[~subkanthi] Looking at the patch there are several point that would need to be
changed.
* Without indexes LIKE restrictions can only be performed through filtering.
That means that the queries should fail if {{ALLOW FILTERING}} is not
specified. As shown by some of the unit tests it is not the case. This should
be changed for clustering columns by modifying
{{StatementRestrictions.processClusteringColumnRestrictions}} and for the
partition keys by modifying {{PartitionKeySingleRestrictionSet.needFiltering}}.
For that last one you will need to add a new {{hasLike}} method to
{{Restrictions}} and use it.
* If the user attempt to use a LIKE restriction on a column which is not a
string type the error can be confusing. The logic within
{{SingleColumnRelation.newLikeRestriction}} can be changed to validate that the
type of the receiver (for a LIKE you are guaranty to have only one) is a
instanceof StringType.
> Allow to filter using LIKE predicates
> -
>
> Key: CASSANDRA-17198
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17198
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Kanthi Subramanian
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> {{LIKE}} predicates can only be used with the SASI indices. In several
> usecases (e.g. querying the {{settings}} virtual table) it makes sense to
> support them for filtering.
> +Additional information for newcomers:+
> There are some checks in the {{StatementRestrictions}} constructor and on
> {{LikeRestriction}} that need to be removed for allowing filtering using LIKE
> on clustering and regular columns.
> For filtering on partition columns the {{needFiltering}} methods in
> {{PartitionKeySingleRestrictionSet}} will need to be modified to return true
> when LIKE predicate are used.
> The unit tests should go in {{SelectTest}}.
--
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-16378) Expose application_name and application_version in virtual table system_views.clients
[
https://issues.apache.org/jira/browse/CASSANDRA-16378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492519#comment-17492519
]
Berenguer Blasi commented on CASSANDRA-16378:
-
CI failures look unrelated to me. We need another committer to review now.
> Expose application_name and application_version in virtual table
> system_views.clients
> -
>
> Key: CASSANDRA-16378
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16378
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables
>Reporter: Tibor Repasi
>Assignee: Tibor Repasi
>Priority: Normal
> Labels: AdventCalendar2021, gsoc2021, lhf, mentor
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Recent java-driver's
> [com.datastax.oss.driver.api.core.session.SessionBuilder|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html]
> respects properties
> [ApplicationName|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationName-java.lang.String-]
> and
> [ApplicationVersion|https://docs.datastax.com/en/drivers/java/4.9/com/datastax/oss/driver/api/core/session/SessionBuilder.html#withApplicationVersion-java.lang.String-].
> It would be helpful to expose this information via virtual table
> {{system_views.clients}} and with {{{}nodetool clientstats{}}}.
> +Additional information for newcomers:+
> The drivers can send as part of the {{STARTUP MESSAGE}} the
> {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options. Two new volatile
> fields {{applicationName}} and {{applicationVersion}} need to be added to
> {{ClientState}} in a similar way to {{driverName}} and {{{}driverVersion{}}}.
> The {{APPLICATION_NAME}} and {{APPLICATION_VERSION}} options need to be
> retrieved in {{StartupMessage#execute}} and passed to the
> {{{}ClientState{}}}.
> The new {{application_name}} and {{application_version}} columns need to be
> added to the {{system_views.clients}} represented by the {{ClientsTable}}
> class. The data then need to be retrieved from the {{ClientState}} through
> {{{}ConnectedClient{}}}.
> Some unit tests similat to {{SettingsTableTest}} should be added.
--
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-17384) WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra Release"
[ https://issues.apache.org/jira/browse/CASSANDRA-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17384: -- Status: Changes Suggested (was: Review In Progress) I've suggested some changes and posted them directly in the PR. Cheers! 🍻 > WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra > Release" > --- > > Key: CASSANDRA-17384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17384 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Josh McKenzie >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Behind the scenes of an Apache Cassandra Release" > If this blog cannot be published by the *February 17, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- 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-17384) WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra Release"
[ https://issues.apache.org/jira/browse/CASSANDRA-17384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17384: -- Reviewers: Erick Ramirez Status: Review In Progress (was: Patch Available) > WEBSITE - February 2022 blog "Behind the scenes of an Apache Cassandra > Release" > --- > > Key: CASSANDRA-17384 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17384 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Josh McKenzie >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Behind the scenes of an Apache Cassandra Release" > If this blog cannot be published by the *February 17, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17283) Failing test: UNIT org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1
[ https://issues.apache.org/jira/browse/CASSANDRA-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi reassigned CASSANDRA-17283: --- Assignee: Berenguer Blasi > Failing test: UNIT > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1 > - > > Key: CASSANDRA-17283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17283 > Project: Cassandra > Issue Type: Bug >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.x > > > Intermittent failure: > [https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/BulkLoaderTest/testBulkLoader_WithArgs1] > h3. Error Message > Wrong thread status, active threads unaccounted for: > [cluster2-connection-reaper-0] > h3. Stacktrace > junit.framework.AssertionFailedError: Wrong thread status, active threads > unaccounted for: [cluster2-connection-reaper-0] at > org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:106) > at > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:85) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > DEBUG [main] 2022-01-21 19:11:46,606 InternalLoggerFactory.java:63 - Using > SLF4J as the default logging framework DEBUG [main] 2022-01-21 19:11:46,634 > PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false DEBUG [main] > 2022-01-21 19:11:46,634 PlatformDependent0.java:897 - Java version: 8 DEBUG > [main] 2022-01-21 19:11:46,636 PlatformDependent0.java:130 - > sun.misc.Unsafe.theUnsafe: available DEBUG [main] 2022-01-21 19:11:46,636 > PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available -- 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-17283) Failing test: UNIT org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1
[ https://issues.apache.org/jira/browse/CASSANDRA-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492537#comment-17492537 ] Berenguer Blasi commented on CASSANDRA-17283: - I also found: bq. Wrong thread status, active threads unaccounted for: [Shutdown-checker] bq. Wrong thread status, active threads unaccounted for: [cluster3-connection-reaper-0] Where the first one googling a bit seems to be some jdk thread. The cluster connection reapears no idea so far. But they are probably coming from somewhere in C*. They both seems benign and probably the fix is to add them to the list of exclusion of threads to check. Need to look a bit more though. > Failing test: UNIT > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1 > - > > Key: CASSANDRA-17283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17283 > Project: Cassandra > Issue Type: Bug >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.x > > > Intermittent failure: > [https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/BulkLoaderTest/testBulkLoader_WithArgs1] > h3. Error Message > Wrong thread status, active threads unaccounted for: > [cluster2-connection-reaper-0] > h3. Stacktrace > junit.framework.AssertionFailedError: Wrong thread status, active threads > unaccounted for: [cluster2-connection-reaper-0] at > org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:106) > at > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:85) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > DEBUG [main] 2022-01-21 19:11:46,606 InternalLoggerFactory.java:63 - Using > SLF4J as the default logging framework DEBUG [main] 2022-01-21 19:11:46,634 > PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false DEBUG [main] > 2022-01-21 19:11:46,634 PlatformDependent0.java:897 - Java version: 8 DEBUG > [main] 2022-01-21 19:11:46,636 PlatformDependent0.java:130 - > sun.misc.Unsafe.theUnsafe: available DEBUG [main] 2022-01-21 19:11:46,636 > PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available -- 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-17283) Failing test: UNIT org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1
[ https://issues.apache.org/jira/browse/CASSANDRA-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17283: Bug Category: Parent values: Correctness(12982) Complexity: Normal Component/s: Test/unit Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Failing test: UNIT > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1 > - > > Key: CASSANDRA-17283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17283 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.x > > > Intermittent failure: > [https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/BulkLoaderTest/testBulkLoader_WithArgs1] > h3. Error Message > Wrong thread status, active threads unaccounted for: > [cluster2-connection-reaper-0] > h3. Stacktrace > junit.framework.AssertionFailedError: Wrong thread status, active threads > unaccounted for: [cluster2-connection-reaper-0] at > org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:106) > at > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:85) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > DEBUG [main] 2022-01-21 19:11:46,606 InternalLoggerFactory.java:63 - Using > SLF4J as the default logging framework DEBUG [main] 2022-01-21 19:11:46,634 > PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false DEBUG [main] > 2022-01-21 19:11:46,634 PlatformDependent0.java:897 - Java version: 8 DEBUG > [main] 2022-01-21 19:11:46,636 PlatformDependent0.java:130 - > sun.misc.Unsafe.theUnsafe: available DEBUG [main] 2022-01-21 19:11:46,636 > PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available -- 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-17283) Failing test: UNIT org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1
[ https://issues.apache.org/jira/browse/CASSANDRA-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492537#comment-17492537 ] Berenguer Blasi edited comment on CASSANDRA-17283 at 2/15/22, 11:19 AM: I also found: bq. Wrong thread status, active threads unaccounted for: [Shutdown-checker] bq. Wrong thread status, active threads unaccounted for: [cluster3-connection-reaper-0] Where the first one googling a bit seems to be some jdk thread. The cluster connection reapears from the C* driver*. They both seems benign and probably the fix is to add them to the list of exclusion of threads to check. Need to look a bit more though. was (Author: bereng): I also found: bq. Wrong thread status, active threads unaccounted for: [Shutdown-checker] bq. Wrong thread status, active threads unaccounted for: [cluster3-connection-reaper-0] Where the first one googling a bit seems to be some jdk thread. The cluster connection reapears no idea so far. But they are probably coming from somewhere in C*. They both seems benign and probably the fix is to add them to the list of exclusion of threads to check. Need to look a bit more though. > Failing test: UNIT > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1 > - > > Key: CASSANDRA-17283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17283 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.x > > > Intermittent failure: > [https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/BulkLoaderTest/testBulkLoader_WithArgs1] > h3. Error Message > Wrong thread status, active threads unaccounted for: > [cluster2-connection-reaper-0] > h3. Stacktrace > junit.framework.AssertionFailedError: Wrong thread status, active threads > unaccounted for: [cluster2-connection-reaper-0] at > org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:106) > at > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:85) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > DEBUG [main] 2022-01-21 19:11:46,606 InternalLoggerFactory.java:63 - Using > SLF4J as the default logging framework DEBUG [main] 2022-01-21 19:11:46,634 > PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false DEBUG [main] > 2022-01-21 19:11:46,634 PlatformDependent0.java:897 - Java version: 8 DEBUG > [main] 2022-01-21 19:11:46,636 PlatformDependent0.java:130 - > sun.misc.Unsafe.theUnsafe: available DEBUG [main] 2022-01-21 19:11:46,636 > PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available -- 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-17283) Failing test: UNIT org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1
[ https://issues.apache.org/jira/browse/CASSANDRA-17283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492537#comment-17492537 ] Berenguer Blasi edited comment on CASSANDRA-17283 at 2/15/22, 11:25 AM: I also found: bq. Wrong thread status, active threads unaccounted for: [Shutdown-checker] bq. Wrong thread status, active threads unaccounted for: [cluster3-connection-reaper-0] Where the first one googling a bit seems to be some jdk thread. The cluster connection reapears from the C* driver. They both seems benign and probably the fix is to add them to the list of exclusion of threads to check. These come up as we're invoking the _class_ directly, not the _tool_. Need to look a bit more though. was (Author: bereng): I also found: bq. Wrong thread status, active threads unaccounted for: [Shutdown-checker] bq. Wrong thread status, active threads unaccounted for: [cluster3-connection-reaper-0] Where the first one googling a bit seems to be some jdk thread. The cluster connection reapears from the C* driver*. They both seems benign and probably the fix is to add them to the list of exclusion of threads to check. Need to look a bit more though. > Failing test: UNIT > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1 > - > > Key: CASSANDRA-17283 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17283 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Josh McKenzie >Assignee: Berenguer Blasi >Priority: Normal > Fix For: 4.x > > > Intermittent failure: > [https://butler.cassandra.apache.org/#/ci/upstream/workflow/Cassandra-trunk/failure/org.apache.cassandra.tools/BulkLoaderTest/testBulkLoader_WithArgs1] > h3. Error Message > Wrong thread status, active threads unaccounted for: > [cluster2-connection-reaper-0] > h3. Stacktrace > junit.framework.AssertionFailedError: Wrong thread status, active threads > unaccounted for: [cluster2-connection-reaper-0] at > org.apache.cassandra.tools.OfflineToolUtils.assertNoUnexpectedThreadsStarted(OfflineToolUtils.java:106) > at > org.apache.cassandra.tools.BulkLoaderTest.testBulkLoader_WithArgs1(BulkLoaderTest.java:85) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > h3. Standard Output > DEBUG [main] 2022-01-21 19:11:46,606 InternalLoggerFactory.java:63 - Using > SLF4J as the default logging framework DEBUG [main] 2022-01-21 19:11:46,634 > PlatformDependent0.java:417 - -Dio.netty.noUnsafe: false DEBUG [main] > 2022-01-21 19:11:46,634 PlatformDependent0.java:897 - Java version: 8 DEBUG > [main] 2022-01-21 19:11:46,636 PlatformDependent0.java:130 - > sun.misc.Unsafe.theUnsafe: available DEBUG [main] 2022-01-21 19:11:46,636 > PlatformDependent0.java:154 - sun.misc.Unsafe.copyMemory: available -- 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-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492595#comment-17492595 ] Brad Schoening commented on CASSANDRA-17293: What version of openssl do you have when testing? % openssl version > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17382) Flaky Test - LongLeveledCompactionStrategyCQLTest
[
https://issues.apache.org/jira/browse/CASSANDRA-17382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksei Zotov updated CASSANDRA-17382:
--
Component/s: Test/unit
> Flaky Test - LongLeveledCompactionStrategyCQLTest
> --
>
> Key: CASSANDRA-17382
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17382
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS, Test/unit
>Reporter: Aleksei Zotov
>Priority: Normal
> Fix For: 3.11.x
>
>
> The test fails on 3.11 with such an issue:
> {code}
> ERROR [CompactionExecutor:2] 2022-02-07 13:29:52,856 CQLTester.java:184 -
> Fatal exception in thread Thread[CompactionExecutor:2,1,main]
> java.lang.AssertionError: Got unexpected overlap in level 2 at
> org.apache.cassandra.db.compaction.LeveledGenerations.addAll(LeveledGenerations.java:159)
> at
> org.apache.cassandra.db.compaction.LeveledManifest.addSSTables(LeveledManifest.java:132)
> at
> org.apache.cassandra.db.compaction.LeveledCompactionStrategy.addSSTable(LeveledCompactionStrategy.java:351)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.startup(CompactionStrategyManager.java:216)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.reload(CompactionStrategyManager.java:393)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.maybeReloadDiskBoundaries(CompactionStrategyManager.java:356)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManager.handleNotification(CompactionStrategyManager.java:579)
> at
> org.apache.cassandra.db.lifecycle.Tracker.notifySSTablesChanged(Tracker.java:429)
> at
> org.apache.cassandra.db.lifecycle.LifecycleTransaction.doCommit(LifecycleTransaction.java:234)
> at
> org.apache.cassandra.utils.concurrent.Transactional$AbstractTransactional.commit(Transactional.java:113)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.doCommit(SSTableRewriter.java:207)
> {code}
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/316/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
> [https://ci-cassandra.apache.org/job/Cassandra-3.11/318/testReport/org.apache.cassandra.db.compaction/LongLeveledCompactionStrategyCQLTest/stressTestCompactionStrategyManager/]
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492615#comment-17492615 ] Berenguer Blasi commented on CASSANDRA-17293: - I get: OpenSSL 1.1.1f 31 Mar 2020 > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- 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-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492624#comment-17492624
]
Andres de la Peña commented on CASSANDRA-17186:
---
CI looks good to me, +1. Now we need a second reviewer, maybe [~Bereng] or
[~blerer] can take a look?
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
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-17220) Make startup checks configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17220: -- Status: Needs Committer (was: Patch Available) > Make startup checks configurable > > > Key: CASSANDRA-17220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17220 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > > This ticket was created from needs discovered in CASSANDRA-17180. We want to > be able to configure a startup check so we figured out that it is necessary > to treat all startup checks same - to be able to configure them. This ticket > is about making startup checks configurable. > Once this ticket is done, we can continue with the implementation of > CASSANDRA-17180 where the implementation of gc grace check will be done. > We have identified that there is one check currently in place which needs to > be changed to reflect this configuration implementation and that is > FileSystemOwnershipCheck. > Because startup checks were not configurable before via means of a > configuration file, they were configurable via system properties. This ticket > does not aim to get rid system properties configuration mechanism, system > properties will have precedence over settings in configuration file. Then, in > the next release, I am aiming to get rid of system properties configuration > mechanism. -- 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-17220) Make startup checks configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17220: -- Test and Documentation Plan: unit tests Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/1448 > Make startup checks configurable > > > Key: CASSANDRA-17220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17220 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > > This ticket was created from needs discovered in CASSANDRA-17180. We want to > be able to configure a startup check so we figured out that it is necessary > to treat all startup checks same - to be able to configure them. This ticket > is about making startup checks configurable. > Once this ticket is done, we can continue with the implementation of > CASSANDRA-17180 where the implementation of gc grace check will be done. > We have identified that there is one check currently in place which needs to > be changed to reflect this configuration implementation and that is > FileSystemOwnershipCheck. > Because startup checks were not configurable before via means of a > configuration file, they were configurable via system properties. This ticket > does not aim to get rid system properties configuration mechanism, system > properties will have precedence over settings in configuration file. Then, in > the next release, I am aiming to get rid of system properties configuration > mechanism. -- 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
[cassandra-website] branch trunk updated: CASSANDRA-17373: February 2022 blog "Tightening Security for Apache Cassandra Part: 3"
This is an automated email from the ASF dual-hosted git repository. blerer pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-website.git The following commit(s) were added to refs/heads/trunk by this push: new a0fb0de CASSANDRA-17373: February 2022 blog "Tightening Security for Apache Cassandra Part: 3" a0fb0de is described below commit a0fb0de12c70b2a4b2b27ca1196ae9598aa45db0 Author: Diogenese Topper AuthorDate: Thu Feb 10 19:00:05 2022 -0800 CASSANDRA-17373: February 2022 blog "Tightening Security for Apache Cassandra Part: 3" patch by Maulin Vasavada, Diogenese Topper; review by Erick Ramirez Add blog post titled "Tightening Security for Apache Cassandra Part: 3" update blog index add 2 images for blog: "Cassandra-SslContextFactory.png" and "tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg" --- .../images/blog/Cassandra-SslContextFactory.png| Bin 0 -> 33750 bytes ...che-cassandra-p3-unsplash-jennefer-zacarias.jpg | Bin 0 -> 1658871 bytes site-content/source/modules/ROOT/pages/blog.adoc | 24 + ...ening-Security-for-Apache-Cassandra-Part-3.adoc | 97 + 4 files changed, 121 insertions(+) diff --git a/site-content/source/modules/ROOT/images/blog/Cassandra-SslContextFactory.png b/site-content/source/modules/ROOT/images/blog/Cassandra-SslContextFactory.png new file mode 100644 index 000..872f0a4 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/Cassandra-SslContextFactory.png differ diff --git a/site-content/source/modules/ROOT/images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg b/site-content/source/modules/ROOT/images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg new file mode 100644 index 000..b708d58 Binary files /dev/null and b/site-content/source/modules/ROOT/images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg differ diff --git a/site-content/source/modules/ROOT/pages/blog.adoc b/site-content/source/modules/ROOT/pages/blog.adoc index d039eff..2523451 100644 --- a/site-content/source/modules/ROOT/pages/blog.adoc +++ b/site-content/source/modules/ROOT/pages/blog.adoc @@ -14,6 +14,30 @@ NOTES FOR CONTENT CREATORS [openblock,card-header] -- [discrete] +=== Tightening Security for Apache Cassandra: Part 3 +[discrete] + February 14, 2022 +-- +[openblock,card-content] +-- +In Part 3 of Maulin Vasavada’s mini-series on improving security, we detail how Cassandra 4.0 delivers ways to customize mTLS/TLS configuration while retaining the hot-reload functionality. + +[openblock,card-btn card-btn--blog] + +[.btn.btn--alt] +xref:blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc[Read More] + + +-- + +//end card + +//start card +[openblock,card shadow relative test] + +[openblock,card-header] +-- +[discrete] === Apache Cassandra Changelog #12 [discrete] February 10, 2022 diff --git a/site-content/source/modules/ROOT/pages/blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc b/site-content/source/modules/ROOT/pages/blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc new file mode 100644 index 000..c8ac3fb --- /dev/null +++ b/site-content/source/modules/ROOT/pages/blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc @@ -0,0 +1,97 @@ += Tightening security for Apache Cassandra: Part 3 +:page-layout: single-post +:page-role: blog-post +:page-post-date: February, 14 2022 +:page-post-author: Maulin Vasavada +:description: The Apache Cassandra Community +:keywords: + +:!figure-caption: + +.Image credit: https://unsplash.com/@zenchic[Jennefer Zacarias^] +image::blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg[3-4] + +In xref:blog/Tightening-Security-for-Apache-Cassandra-Part-2.adoc[Part-2] of this series, we explored avenues for securing data in transit and described how to configure TLS/mTLS with Apache Cassandra 4.0. In Part 3, we’ll look at how you can customize TLS/mTLS for Apache Cassandra 4.0+ to overcome the challenges with a TLS configuration. + +=== How We Made TLS Configuration Better With 4.0 + +With Apache Cassandra 4.0, https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable[we enhanced^] the TLS/mTLS configuration to allow for specifying custom ways to build SSLContext and we provided a default implementation for backward compatibility. We introduced a new configuration, `ssl_context_factory`, where you can specify your custom class to build SSLContext objects required by Java/Netty SSL libraries. You can also add custom properties to [...] + +To demonstrate this customization, let’s use the example of Kubernetes, the popular cloud-native solution. Kubernetes allows configuring https://kubernetes.io/docs/concepts/configuration/secret/[Secrets^] to
[jira] [Updated] (CASSANDRA-17220) Make startup checks configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17220: -- Priority: Normal (was: Low) > Make startup checks configurable > > > Key: CASSANDRA-17220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17220 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > This ticket was created from needs discovered in CASSANDRA-17180. We want to > be able to configure a startup check so we figured out that it is necessary > to treat all startup checks same - to be able to configure them. This ticket > is about making startup checks configurable. > Once this ticket is done, we can continue with the implementation of > CASSANDRA-17180 where the implementation of gc grace check will be done. > We have identified that there is one check currently in place which needs to > be changed to reflect this configuration implementation and that is > FileSystemOwnershipCheck. > Because startup checks were not configurable before via means of a > configuration file, they were configurable via system properties. This ticket > does not aim to get rid system properties configuration mechanism, system > properties will have precedence over settings in configuration file. Then, in > the next release, I am aiming to get rid of system properties configuration > mechanism. -- 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-17220) Make startup checks configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492626#comment-17492626 ] Stefan Miklosovic commented on CASSANDRA-17220: --- hey [~dcapwell] [~paulo] , would you mind to review this? It touches the enum configs we spoke about recently. > Make startup checks configurable > > > Key: CASSANDRA-17220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17220 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Low > > This ticket was created from needs discovered in CASSANDRA-17180. We want to > be able to configure a startup check so we figured out that it is necessary > to treat all startup checks same - to be able to configure them. This ticket > is about making startup checks configurable. > Once this ticket is done, we can continue with the implementation of > CASSANDRA-17180 where the implementation of gc grace check will be done. > We have identified that there is one check currently in place which needs to > be changed to reflect this configuration implementation and that is > FileSystemOwnershipCheck. > Because startup checks were not configurable before via means of a > configuration file, they were configurable via system properties. This ticket > does not aim to get rid system properties configuration mechanism, system > properties will have precedence over settings in configuration file. Then, in > the next release, I am aiming to get rid of system properties configuration > mechanism. -- 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
[cassandra-website] branch asf-staging updated (6568f4b -> 7525e6c)
This is an automated email from the ASF dual-hosted git repository.
git-site-role pushed a change to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard 6568f4b generate docs for bb420481
add a0fb0de CASSANDRA-17373: February 2022 blog "Tightening Security for
Apache Cassandra Part: 3"
new 7525e6c generate docs for a0fb0de1
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (6568f4b)
\
N -- N -- N refs/heads/asf-staging (7525e6c)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
The 1 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../_/_images/blog/Cassandra-SslContextFactory.png | Bin 0 -> 33750 bytes
...che-cassandra-p3-unsplash-jennefer-zacarias.jpg | Bin 0 -> 1658871 bytes
content/_/blog.html| 24 +
...ning-Security-for-Apache-Cassandra-Part-3.html} | 118 +++--
content/search-index.js| 2 +-
.../images/blog/Cassandra-SslContextFactory.png| Bin 0 -> 33750 bytes
...che-cassandra-p3-unsplash-jennefer-zacarias.jpg | Bin 0 -> 1658871 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +
...ening-Security-for-Apache-Cassandra-Part-3.adoc | 97 +
site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084
bytes
10 files changed, 230 insertions(+), 35 deletions(-)
create mode 100644 content/_/_images/blog/Cassandra-SslContextFactory.png
create mode 100644
content/_/_images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg
copy content/_/blog/{Tightening-Security-for-Apache-Cassandra-Part-1.html =>
Tightening-Security-for-Apache-Cassandra-Part-3.html} (64%)
create mode 100644
site-content/source/modules/ROOT/images/blog/Cassandra-SslContextFactory.png
create mode 100644
site-content/source/modules/ROOT/images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (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:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Status: Needs Committer (was: Patch Available) > 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: 10m > 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] [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=17492650#comment-17492650 ] Stefan Miklosovic commented on CASSANDRA-17180: --- I have implemented the check here https://github.com/apache/cassandra/pull/1351 The work to make checks configurable is in CASSANDRA-17220. 17220 needs to go first before this one is eligible to go in. > 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: 10m > 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-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:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Status: Patch Available (was: In Progress) https://github.com/apache/cassandra/pull/1351 > 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: 10m > 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-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:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17180: -- Reviewers: Paulo Motta Status: Review In Progress (was: Needs Committer) > 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: 10m > 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-17220) Make startup checks configurable
[ https://issues.apache.org/jira/browse/CASSANDRA-17220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17220: -- Reviewers: Paulo Motta Status: Review In Progress (was: Needs Committer) > Make startup checks configurable > > > Key: CASSANDRA-17220 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17220 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > > This ticket was created from needs discovered in CASSANDRA-17180. We want to > be able to configure a startup check so we figured out that it is necessary > to treat all startup checks same - to be able to configure them. This ticket > is about making startup checks configurable. > Once this ticket is done, we can continue with the implementation of > CASSANDRA-17180 where the implementation of gc grace check will be done. > We have identified that there is one check currently in place which needs to > be changed to reflect this configuration implementation and that is > FileSystemOwnershipCheck. > Because startup checks were not configurable before via means of a > configuration file, they were configurable via system properties. This ticket > does not aim to get rid system properties configuration mechanism, system > properties will have precedence over settings in configuration file. Then, in > the next release, I am aiming to get rid of system properties configuration > mechanism. -- 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-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:all-tabpanel ] Paulo Motta updated CASSANDRA-17180: Status: Patch Available (was: Review In Progress) > 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: 10m > 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] [Commented] (CASSANDRA-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492675#comment-17492675 ] Brandon Williams commented on CASSANDRA-17293: -- I put this through [circle|https://app.circleci.com/pipelines/github/driftx/cassandra/361/workflows/e6dd2c5a-7c3b-4ca3-b2d1-9ed86c739166/jobs/4096] to doublecheck and it fails there as well. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17385) Guardrails for items per UDT
Andres de la Peña created CASSANDRA-17385:
-
Summary: Guardrails for items per UDT
Key: CASSANDRA-17385
URL: https://issues.apache.org/jira/browse/CASSANDRA-17385
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Andres de la Peña
Assignee: Andres de la Peña
Add a guardrail for the number of items in a UDT. For example:
{code}
# Guardrail to warn or fail when creating a user-defined-type with more fields
in than threshold.
# Default -1 to disable.
fields_per_udt_warn_threshold: -1
fields_per_udt_fail_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] [Updated] (CASSANDRA-17153) Guardrails for collection items and size
[
https://issues.apache.org/jira/browse/CASSANDRA-17153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17153:
--
Description:
Add guardrails for the number of items and size of collections. For example:
{code}
# Guardrail to warn or fail when encountering larger size of collection data
than threshold.
# The two thresholds default to 0KiB to disable.
collection_size_warn_threshold: 0KiB
collection_size_fail_threshold: 0KiB
# Guardrail to warn or fail when encountering more elements in collection than
threshold.
# The two thresholds default to -1 to disable.
items_per_collection_warn_threshold: -1
items_per_collection_fail_threshold: -1
{code}
was:
Add guardrails for the number of items in a collection/UDT and possibly also
the size of a collection. For example:
{code}
# Failure threshold to prevent creating more fields in user-defined-type than
threshold.
# Defaults -1 to disable.
# fields_per_udt_failure_threshold: -1
# Warning threshold to warn when encountering larger size of collection data
than threshold.
# Defaults -1 to disable.
# collection_size_warn_threshold_in_kb: -1
# Warning threshold to warn when encountering more elements in collection than
threshold.
# Defaults -1 to disable.
# items_per_collection_warn_threshold: -1
{code}
Summary: Guardrails for collection items and size (was: Guardrails for
collection/UDT items and size)
> Guardrails for collection items and size
>
>
> Key: CASSANDRA-17153
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17153
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for the number of items and size of collections. For example:
> {code}
> # Guardrail to warn or fail when encountering larger size of collection data
> than threshold.
> # The two thresholds default to 0KiB to disable.
> collection_size_warn_threshold: 0KiB
> collection_size_fail_threshold: 0KiB
> # Guardrail to warn or fail when encountering more elements in collection
> than threshold.
> # The two thresholds default to -1 to disable.
> items_per_collection_warn_threshold: -1
> items_per_collection_fail_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] [Commented] (CASSANDRA-17385) Guardrails for items per UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492683#comment-17492683
]
Andres de la Peña commented on CASSANDRA-17385:
---
||PR||CI||
|[trunk|https://github.com/apache/cassandra/pull/1449]|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1298/workflows/ef0892b8-d9f0-4e29-8fc9-d4baa63ba556]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1298/workflows/b1aef77a-fc2e-41b2-bbc3-dae576f445f4]|
> Guardrails for items per UDT
>
>
> Key: CASSANDRA-17385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17385
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add a guardrail for the number of items in a UDT. For example:
> {code}
> # Guardrail to warn or fail when creating a user-defined-type with more
> fields in than threshold.
> # Default -1 to disable.
> fields_per_udt_warn_threshold: -1
> fields_per_udt_fail_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] [Updated] (CASSANDRA-17385) Guardrails for items per UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17385:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Fix Version/s: 4.x
Status: Open (was: Triage Needed)
> Guardrails for items per UDT
>
>
> Key: CASSANDRA-17385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17385
> 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
>
>
> Add a guardrail for the number of items in a UDT. For example:
> {code}
> # Guardrail to warn or fail when creating a user-defined-type with more
> fields in than threshold.
> # Default -1 to disable.
> fields_per_udt_warn_threshold: -1
> fields_per_udt_fail_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] [Updated] (CASSANDRA-17385) Guardrails for items per UDT
[
https://issues.apache.org/jira/browse/CASSANDRA-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17385:
--
Test and Documentation Plan: New tests are included
Status: Patch Available (was: In Progress)
> Guardrails for items per UDT
>
>
> Key: CASSANDRA-17385
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17385
> 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
>
>
> Add a guardrail for the number of items in a UDT. For example:
> {code}
> # Guardrail to warn or fail when creating a user-defined-type with more
> fields in than threshold.
> # Default -1 to disable.
> fields_per_udt_warn_threshold: -1
> fields_per_udt_fail_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
[cassandra-website] branch asf-site updated (fec7fb2 -> 7525e6c)
This is an automated email from the ASF dual-hosted git repository.
blerer pushed a change to branch asf-site
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git.
discard fec7fb2 ninja
discard 56da4b9 generate docs for ee56da10
add bb42048 Releases 3.0.26, 3.11.12, 4.0.2
add a0fb0de CASSANDRA-17373: February 2022 blog "Tightening Security for
Apache Cassandra Part: 3"
add 7525e6c generate docs for a0fb0de1
This update added new revisions after undoing existing revisions.
That is to say, some revisions that were in the old version of the
branch are not in the new version. This situation occurs
when a user --force pushes a change and generates a repository
containing something like this:
* -- * -- B -- O -- O -- O (fec7fb2)
\
N -- N -- N refs/heads/asf-site (7525e6c)
You should already have received notification emails for all of the O
revisions, and so the following emails describe only the N revisions
from the common base, B.
Any revisions marked "omit" are not gone; other references still
refer to them. Any revisions marked "discard" are gone forever.
No new revisions were added by this update.
Summary of changes:
.../_/_images/blog/Cassandra-SslContextFactory.png | Bin 0 -> 33750 bytes
...che-cassandra-p3-unsplash-jennefer-zacarias.jpg | Bin 0 -> 1658871 bytes
content/_/blog.html| 24 +++
...ning-Security-for-Apache-Cassandra-Part-3.html} | 118
content/_/download.html| 52 ++---
.../cassandra/configuration/cass_yaml_file.html| 211 -
.../cassandra/configuration/cass_yaml_file.html| 211 -
.../cassandra/configuration/cass_yaml_file.html| 211 -
content/search-index.js| 2 +-
.../images/blog/Cassandra-SslContextFactory.png| Bin 0 -> 33750 bytes
...che-cassandra-p3-unsplash-jennefer-zacarias.jpg | Bin 0 -> 1658871 bytes
site-content/source/modules/ROOT/pages/blog.adoc | 24 +++
...ening-Security-for-Apache-Cassandra-Part-3.adoc | 97 ++
.../source/modules/ROOT/pages/download.adoc| 18 +-
site-ui/build/ui-bundle.zip| Bin 4740084 -> 4740084
bytes
15 files changed, 880 insertions(+), 88 deletions(-)
create mode 100644 content/_/_images/blog/Cassandra-SslContextFactory.png
create mode 100644
content/_/_images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg
copy content/_/blog/{Tightening-Security-for-Apache-Cassandra-Part-1.html =>
Tightening-Security-for-Apache-Cassandra-Part-3.html} (64%)
create mode 100644
site-content/source/modules/ROOT/images/blog/Cassandra-SslContextFactory.png
create mode 100644
site-content/source/modules/ROOT/images/blog/tightening-security-for-apache-cassandra-p3-unsplash-jennefer-zacarias.jpg
create mode 100644
site-content/source/modules/ROOT/pages/blog/Tightening-Security-for-Apache-Cassandra-Part-3.adoc
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-5108) expose overall progress of cleanup tasks in jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492691#comment-17492691 ] Krishna Vadali commented on CASSANDRA-5108: --- Before going deep into this issue, [~mkjellman] Is the goal of this task to log the progress of cleanup operation. For instance something like the following. Running compaction on SSTables A, completed 10 SSTables, remaining 90 SSTables. > expose overall progress of cleanup tasks in jmx > --- > > Key: CASSANDRA-5108 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5108 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability, Local/Compaction >Affects Versions: 1.2.0 >Reporter: Michael Kjellman >Assignee: Krishna Vadali >Priority: Low > Labels: lhf > Fix For: 4.x > > > it would be nice if, upon starting a cleanup operation, cassandra could > maintain a Set (i assume this already exists as we have to know which file to > act on next) and a new set of "completed" sstables. When each is compacted > remove it from the pending list. That way C* could give an overall completion > of the long running and pending cleanup tasks. -- 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-5108) expose overall progress of cleanup tasks in jmx
[
https://issues.apache.org/jira/browse/CASSANDRA-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492708#comment-17492708
]
Paulo Motta commented on CASSANDRA-5108:
[~tejavadali] I think it's displaying the operation completion percentage on
{{nodetool compactionstats}}, which keeps a percentage count per operation but
apparently it's not working for {{CLEANUP}}.
Perhaps you can try reproducing this by running a cleanup manually on {{ccm}}
after bootstrap to check how the progress is displayed on {{nodetool
compactionstats}}?
> expose overall progress of cleanup tasks in jmx
> ---
>
> Key: CASSANDRA-5108
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5108
> Project: Cassandra
> Issue Type: New Feature
> Components: Legacy/Observability, Local/Compaction
>Affects Versions: 1.2.0
>Reporter: Michael Kjellman
>Assignee: Krishna Vadali
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> it would be nice if, upon starting a cleanup operation, cassandra could
> maintain a Set (i assume this already exists as we have to know which file to
> act on next) and a new set of "completed" sstables. When each is compacted
> remove it from the pending list. That way C* could give an overall completion
> of the long running and pending cleanup tasks.
--
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-17351) Pip doesn't install ccm every time
[ https://issues.apache.org/jira/browse/CASSANDRA-17351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492712#comment-17492712 ] Ekaterina Dimitrova commented on CASSANDRA-17351: - It seems the Jenkins run finished fine, no new failures > Pip doesn't install ccm every time > -- > > Key: CASSANDRA-17351 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17351 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Urgent > Fix For: 4.x > > > In CASSANDRA-16688 we fixed requirements.txt in DTest repo, pip install to > run without -e for ccm in order to address the moveable tag. That worked for > some time until last night. I successfully retagged and now ccm is not > re-installed in Circle CI. > Jenkins picked stuff though. But it was acting unreliably and weird so > rerunning now things there. Results pending. > Now I added -e for ccm in requirements.txt and it worked in CircleCI. Still > pending results. I don't think this will be permanent solution and I am not > sure whether it will affect also the previous branches in a way. We need to > further investigate it and test. > For now I will ask people to test with -e until we figure it out. > CC [~mck] , [~bereng] , [~dcapwell] and [~stefan.miklosovic] -- 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-5108) expose overall progress of cleanup tasks in jmx
[ https://issues.apache.org/jira/browse/CASSANDRA-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492731#comment-17492731 ] Krishna Vadali commented on CASSANDRA-5108: --- Thanks [~paulo] I will give it a try. > expose overall progress of cleanup tasks in jmx > --- > > Key: CASSANDRA-5108 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5108 > Project: Cassandra > Issue Type: New Feature > Components: Legacy/Observability, Local/Compaction >Affects Versions: 1.2.0 >Reporter: Michael Kjellman >Assignee: Krishna Vadali >Priority: Low > Labels: lhf > Fix For: 4.x > > > it would be nice if, upon starting a cleanup operation, cassandra could > maintain a Set (i assume this already exists as we have to know which file to > act on next) and a new set of "completed" sstables. When each is compacted > remove it from the pending list. That way C* could give an overall completion > of the long running and pending cleanup tasks. -- 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-17272) LeveledCompactionStrategy disk space check improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492763#comment-17492763
]
Caleb Rackliffe commented on CASSANDRA-17272:
-
+1 w/ minor nits on all 3 PRs (and assuming 4.0 will merge cleanly to trunk)
Just to make sure I have things straight, the only difference between 3.0 and
3.11+ is the latter avoids the unnecessary call to {{getWriteDirectory()}} in
the various {{realAppend()}} overrides?
> LeveledCompactionStrategy disk space check improvements
> ---
>
> Key: CASSANDRA-17272
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17272
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Compaction/LCS
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> We currently allow reducing scope (removing sstables from the compaction)
> when starting STCS-in-L0 with LCS if the compaction is too large for the
> available disk space. We can do the same for L0 -> L1 compactions - but we
> can only remove L0 sstables to avoid causing overlap in L1.
> Also, in 3.0, when starting an LCS compaction we try to [get a writeable
> location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128]
> where the full result of the compaction will fit - here we should only get a
> directory where the first sstable fits, otherwise the compaction might fail
> even though there is enough space in total among the data directories
--
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-17378) Add backward compatibility for a few changes done in 15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492853#comment-17492853 ] Ekaterina Dimitrova commented on CASSANDRA-17378: - I ended up only reverting the name change to those three parameters. I want to give a bit of a break to ccm in the moment while we stabilize CI, etc. I will change them later. Patch [here|https://github.com/apache/cassandra/commit/5bea69f0f6563fc51230b96adbd6066dd1d80315]. CI run [J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/ca0427b3-da1b-45aa-9eb5-26831ed3cfdc], [J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/bd556ef1-525c-4635-bf9b-7694ed2888c3] There are already tickets for all CI issues > Add backward compatibility for a few changes done in 15234 > -- > > Key: CASSANDRA-17378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17378 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the latest ML conversations, the following changes in Config should > be reconsidered: > [https://github.com/apache/cassandra/commit/c51a7c66fc21ca2da08b89ae5f9b4817ee4d8c23] > * max_streaming_retries - deprecated long time ago but it should be there > until at least 5.0. We need to revert this change > * user_defined_function_warn_timeout_in_ms and > user_defined_function_fail_timeout_in_ms - add @Replaces annotation and I > think it is nice to transfer them to the new types too. *NOTE: Don't forget > to add the backward compatibility for those two in CCM by adding entries > [here|https://github.com/riptano/ccm/blob/master/ccmlib/common.py#L62-L148]; > valid for any parameter that will use the new framework and we want to be > backward compatible and tested properly by DTests* -- 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-17378) Add backward compatibility for a few changes done in 15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492853#comment-17492853 ] Ekaterina Dimitrova edited comment on CASSANDRA-17378 at 2/15/22, 8:17 PM: --- I ended up only reverting the name change to those three parameters. I want to give a bit of a break to ccm in the moment while we stabilize CI, etc. I will change them later. Patch [here|https://github.com/apache/cassandra/commit/5bea69f0f6563fc51230b96adbd6066dd1d80315]. CI run [J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/ca0427b3-da1b-45aa-9eb5-26831ed3cfdc], [J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/bd556ef1-525c-4635-bf9b-7694ed2888c3] There are already tickets for all CI issues [~dcapwell] do you mind to review? was (Author: e.dimitrova): I ended up only reverting the name change to those three parameters. I want to give a bit of a break to ccm in the moment while we stabilize CI, etc. I will change them later. Patch [here|https://github.com/apache/cassandra/commit/5bea69f0f6563fc51230b96adbd6066dd1d80315]. CI run [J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/ca0427b3-da1b-45aa-9eb5-26831ed3cfdc], [J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/bd556ef1-525c-4635-bf9b-7694ed2888c3] There are already tickets for all CI issues > Add backward compatibility for a few changes done in 15234 > -- > > Key: CASSANDRA-17378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17378 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the latest ML conversations, the following changes in Config should > be reconsidered: > [https://github.com/apache/cassandra/commit/c51a7c66fc21ca2da08b89ae5f9b4817ee4d8c23] > * max_streaming_retries - deprecated long time ago but it should be there > until at least 5.0. We need to revert this change > * user_defined_function_warn_timeout_in_ms and > user_defined_function_fail_timeout_in_ms - add @Replaces annotation and I > think it is nice to transfer them to the new types too. *NOTE: Don't forget > to add the backward compatibility for those two in CCM by adding entries > [here|https://github.com/riptano/ccm/blob/master/ccmlib/common.py#L62-L148]; > valid for any parameter that will use the new framework and we want to be > backward compatible and tested properly by DTests* -- 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-17378) Add backward compatibility for a few changes done in 15234
[ https://issues.apache.org/jira/browse/CASSANDRA-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17378: Test and Documentation Plan: Patch [here|https://github.com/apache/cassandra/commit/5bea69f0f6563fc51230b96adbd6066dd1d80315]. CI run [J8|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/ca0427b3-da1b-45aa-9eb5-26831ed3cfdc], [J11|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1395/workflows/bd556ef1-525c-4635-bf9b-7694ed2888c3] Status: Patch Available (was: In Progress) > Add backward compatibility for a few changes done in 15234 > -- > > Key: CASSANDRA-17378 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17378 > Project: Cassandra > Issue Type: Bug > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Based on the latest ML conversations, the following changes in Config should > be reconsidered: > [https://github.com/apache/cassandra/commit/c51a7c66fc21ca2da08b89ae5f9b4817ee4d8c23] > * max_streaming_retries - deprecated long time ago but it should be there > until at least 5.0. We need to revert this change > * user_defined_function_warn_timeout_in_ms and > user_defined_function_fail_timeout_in_ms - add @Replaces annotation and I > think it is nice to transfer them to the new types too. *NOTE: Don't forget > to add the backward compatibility for those two in CCM by adding entries > [here|https://github.com/riptano/ccm/blob/master/ccmlib/common.py#L62-L148]; > valid for any parameter that will use the new framework and we want to be > backward compatible and tested properly by DTests* -- 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-15239) [flaky in-mem dtest] nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15239:
-
Resolution: (was: Auto Closed)
Status: Open (was: Resolved)
> [flaky in-mem dtest] nodeDownDuringMove -
> org.apache.cassandra.distributed.test.GossipTest
> --
>
> Key: CASSANDRA-15239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jay Zhuang
>Priority: Normal
> Fix For: 3.0.x
>
>
> The in-mem dtest fail from time to time:
> {noformat}
> nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> {noformat}
> [https://circleci.com/gh/Instagram/cassandra/98]
> More details:
> {noformat}
> Testcase:
> nodeDownDuringMove(org.apache.cassandra.distributed.test.GossipTest): Caused
> an ERROR
> java.lang.IllegalStateException: Unable to contact any seeds!
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:166)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$4(IsolatedExecutor.java:69)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:322)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:148)
> at
> org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove(GossipTest.java:96)
> Caused by: java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1261)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:921)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$6(Instance.java:301)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> Test org.apache.cassandra.distributed.test.GossipTest FAILED
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
Ekaterina Dimitrova created CASSANDRA-17386: --- Summary: Test failure: TestCqlshOutput failing tests Key: CASSANDRA-17386 URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova The following TestCqlshOutput tests are failing consistently on 3.11 and as far as Butler goes, since the very beginning it started collecting data so I am not able to say at this point what exactly broke them: Test_static_cf_output, test_boolean_output, test_count_output, test_string_output_ascii, test_null_output, test_columness_key_output, test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17386: Fix Version/s: 3.11.x > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17386: Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/unit Discovered By: Unit Test Severity: Normal Status: Open (was: Triage Needed) > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17348) Fix flaky test - org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove
[ https://issues.apache.org/jira/browse/CASSANDRA-17348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17348: - Resolution: Duplicate Status: Resolved (was: Open) I reopened CASSANDRA-15239 and marked this as a duplicate, since that one was auto-closed and never properly fixed. > Fix flaky test - > org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove > > > Key: CASSANDRA-17348 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17348 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 5 times in the last 12 runs. Flakiness: 36%, Stability: 58% > Error Message > java.lang.AssertionError > Stacktrace > java.lang.RuntimeException: java.lang.AssertionError > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218) > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$19(IsolatedExecutor.java:124) > at > org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove(GossipTest.java:124) > Caused by: java.lang.AssertionError > at > org.apache.cassandra.locator.TokenMetadata.getTokens(TokenMetadata.java:568) > at > org.apache.cassandra.distributed.test.GossipTest.lambda$nodeDownDuringMove$805d71c$1(GossipTest.java:122) > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$null$17(IsolatedExecutor.java:123) > 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:83) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17386) Test failure: TestCqlshOutput failing tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492858#comment-17492858 ] Ekaterina Dimitrova commented on CASSANDRA-17386: - CC [~azotcsit] as I remember you were interested into those > Test failure: TestCqlshOutput failing tests > > > Key: CASSANDRA-17386 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17386 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x > > > The following TestCqlshOutput tests are failing consistently on 3.11 and as > far as Butler goes, since the very beginning it started collecting data so I > am not able to say at this point what exactly broke them: > Test_static_cf_output, test_boolean_output, test_count_output, > test_string_output_ascii, test_null_output, test_columness_key_output, > test_numeric_output -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-15239) [flaky in-mem dtest] nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-15239:
-
Fix Version/s: 3.11.x
> [flaky in-mem dtest] nodeDownDuringMove -
> org.apache.cassandra.distributed.test.GossipTest
> --
>
> Key: CASSANDRA-15239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jay Zhuang
>Priority: Normal
> Fix For: 3.0.x, 3.11.x
>
>
> The in-mem dtest fail from time to time:
> {noformat}
> nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> {noformat}
> [https://circleci.com/gh/Instagram/cassandra/98]
> More details:
> {noformat}
> Testcase:
> nodeDownDuringMove(org.apache.cassandra.distributed.test.GossipTest): Caused
> an ERROR
> java.lang.IllegalStateException: Unable to contact any seeds!
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:166)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$4(IsolatedExecutor.java:69)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:322)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:148)
> at
> org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove(GossipTest.java:96)
> Caused by: java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1261)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:921)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$6(Instance.java:301)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> Test org.apache.cassandra.distributed.test.GossipTest FAILED
> {noformat}
--
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-15239) [flaky in-mem dtest] nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
[
https://issues.apache.org/jira/browse/CASSANDRA-15239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492860#comment-17492860
]
Brandon Williams commented on CASSANDRA-15239:
--
Reopening per CASSANDRA-17348.
> [flaky in-mem dtest] nodeDownDuringMove -
> org.apache.cassandra.distributed.test.GossipTest
> --
>
> Key: CASSANDRA-15239
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15239
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Jay Zhuang
>Priority: Normal
> Fix For: 3.0.x
>
>
> The in-mem dtest fail from time to time:
> {noformat}
> nodeDownDuringMove - org.apache.cassandra.distributed.test.GossipTest
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> {noformat}
> [https://circleci.com/gh/Instagram/cassandra/98]
> More details:
> {noformat}
> Testcase:
> nodeDownDuringMove(org.apache.cassandra.distributed.test.GossipTest): Caused
> an ERROR
> java.lang.IllegalStateException: Unable to contact any seeds!
> java.lang.RuntimeException: java.lang.IllegalStateException: Unable to
> contact any seeds!
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:166)
> at
> org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$4(IsolatedExecutor.java:69)
> at
> org.apache.cassandra.distributed.impl.Instance.startup(Instance.java:322)
> at
> org.apache.cassandra.distributed.impl.AbstractCluster$Wrapper.startup(AbstractCluster.java:148)
> at
> org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove(GossipTest.java:96)
> Caused by: java.lang.IllegalStateException: Unable to contact any seeds!
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1261)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:921)
> at
> org.apache.cassandra.distributed.impl.Instance.lambda$startup$6(Instance.java:301)
> 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:83)
> at java.lang.Thread.run(Thread.java:748)
> Test org.apache.cassandra.distributed.test.GossipTest FAILED
> {noformat}
--
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-17348) Fix flaky test - org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove
[ https://issues.apache.org/jira/browse/CASSANDRA-17348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17348: - Fix Version/s: 3.11.x > Fix flaky test - > org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove > > > Key: CASSANDRA-17348 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17348 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x > > > Failed 5 times in the last 12 runs. Flakiness: 36%, Stability: 58% > Error Message > java.lang.AssertionError > Stacktrace > java.lang.RuntimeException: java.lang.AssertionError > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.waitOn(IsolatedExecutor.java:218) > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$sync$19(IsolatedExecutor.java:124) > at > org.apache.cassandra.distributed.test.GossipTest.nodeDownDuringMove(GossipTest.java:124) > Caused by: java.lang.AssertionError > at > org.apache.cassandra.locator.TokenMetadata.getTokens(TokenMetadata.java:568) > at > org.apache.cassandra.distributed.test.GossipTest.lambda$nodeDownDuringMove$805d71c$1(GossipTest.java:122) > at > org.apache.cassandra.distributed.impl.IsolatedExecutor.lambda$null$17(IsolatedExecutor.java:123) > 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:83) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
Ekaterina Dimitrova created CASSANDRA-17387: --- Summary: Test failure: dtest-offheap.counter_test.TestCounters.test_13691 Key: CASSANDRA-17387 URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 Project: Cassandra Issue Type: Bug Reporter: Ekaterina Dimitrova This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler: h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Fix Version/s: 3.11.x > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler: > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Bug Category: Parent values: Correctness(12982)Level 1 values: Test Failure(12990) Complexity: Normal Component/s: Test/dtest/python Discovered By: User Report Severity: Normal Status: Open (was: Triage Needed) > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler: > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Description: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler. Marking it critical as it shows breaking config change. h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at was: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler. h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Severity: Critical (was: Normal) > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Description: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler. h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at was: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler: h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams reassigned CASSANDRA-17387: Assignee: Brandon Williams > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17387: Description: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have Butler. Marking it critical as it shows breaking config change. h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at was: This test fails only off heap on 3.11, hard to say when it started as it was always failing since we have butler. Marking it critical as it shows breaking config change. h3. Stacktrace Unexpected error found in node logs (see stdout for full details). Errors: [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) Fatal configuration error org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please remove properties [memtable_allocation_type] from your cassandra.yaml at org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) at org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) at > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492867#comment-17492867 ] Brandon Williams commented on CASSANDRA-17387: -- I tested and 3.11 will startup fine with offheap_objects set, so something else is going on here, but it's not as bad as it appears on the surface. > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17365:
---
Description:
According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
auto-negotiation of the highest protocol version that both the client and
server support.
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
The above are deprecated since version 3.6: OpenSSL has deprecated all version
specific protocols.
This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py. And
also config files test/config/{sslhandling.config, sslhandling_invalid.config}
was:
According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
auto-negotiation of the highest protocol version that both the client and
server support.
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
* {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
The above are deprecated since version 3.6: OpenSSL has deprecated all version
specific protocols.
This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/{sslhandling.config,
> sslhandling_invalid.config}
>
--
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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492870#comment-17492870 ] Ekaterina Dimitrova commented on CASSANDRA-17387: - Great, thank you for the quick reaction, I suspect it might be a test issue but better to verify it. > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17354) Bump java-driver dependency in Cassandra to latest 3.x series
[ https://issues.apache.org/jira/browse/CASSANDRA-17354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17354: Complexity: Normal (was: Low Hanging Fruit) > Bump java-driver dependency in Cassandra to latest 3.x series > -- > > Key: CASSANDRA-17354 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17354 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Alex Petrov >Priority: High > Fix For: 4.x > > > We depend on java-driver for testing, and developing/validating native > protocol changes. Unfortunately, the version of drvier that is included with > Cassandra is quite ancient: 3.0.1. We need to bump this dependency to latest > in 3.x series, without upgrading to 4.0 at least for now. Unfortunately, this > is not a trivial change in build.xml (otherwise I would’ve done it rather > than opening this ticket), and bumping version breaks a few tests in all > versions, so those need to be fixed, too. > This should be a prerequiste for the next minor version release, too. -- 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-17373) WEBSITE - February 2022 blog "Tightening Security for Apache Cassandra Part: 3"
[ https://issues.apache.org/jira/browse/CASSANDRA-17373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492892#comment-17492892 ] Erick Ramirez commented on CASSANDRA-17373: --- Committed by [~blerer] as [a0fb0de|https://github.com/apache/cassandra-website/commit/a0fb0de12c70b2a4b2b27ca1196ae9598aa45db0]. > WEBSITE - February 2022 blog "Tightening Security for Apache Cassandra Part: > 3" > --- > > Key: CASSANDRA-17373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17373 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.x > > Attachments: c17373-01-blog-index.png, c17373-02-blog-post.png > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Tightening Security for Apache Cassandra Part: 3" > If this blog cannot be published by the *February 14, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- 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-17373) WEBSITE - February 2022 blog "Tightening Security for Apache Cassandra Part: 3"
[ https://issues.apache.org/jira/browse/CASSANDRA-17373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17373: -- Fix Version/s: 4.0.2 (was: 4.0.x) Source Control Link: https://github.com/apache/cassandra-website/commit/a0fb0de12c70b2a4b2b27ca1196ae9598aa45db0 Resolution: Fixed Status: Resolved (was: Ready to Commit) > WEBSITE - February 2022 blog "Tightening Security for Apache Cassandra Part: > 3" > --- > > Key: CASSANDRA-17373 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17373 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: 4.0.2 > > Attachments: c17373-01-blog-index.png, c17373-02-blog-post.png > > > This ticket is to capture the work associated with publishing the January > 2022 blog "Tightening Security for Apache Cassandra Part: 3" > If this blog cannot be published by the *February 14, 2022 publish date*, > please contact me/suggest changes when possible in the pull request for the > appropriate time that the blog will go live (on blog.adoc and in the blog > post .adoc). -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492898#comment-17492898 ] Brandon Williams commented on CASSANDRA-17387: -- This test [only runs|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L20] with offheap objects on 3.11, since they are disabled in 3.0. The tested scenario involves old counter shards, so it first [installs 2.0.17|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L33]. In the case of offheap memtables, this is too late for the [dtest setup|https://github.com/apache/cassandra-dtest/blob/trunk/dtest_setup.py#L428] which is applied without discretion, so it's actually 2.0 complaining here about a parameter from the (not so near) future. I don't see how this ever could have worked since the addition of offheap to the dtests, and I don't think using them is particularly valuable for this test, so the simplest thing to do is skip this test when offheap is requested - [done here.|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17387] > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17387: - Test and Documentation Plan: disabling a test Status: Patch Available (was: Open) > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17387) Test failure: dtest-offheap.counter_test.TestCounters.test_13691
[ https://issues.apache.org/jira/browse/CASSANDRA-17387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492898#comment-17492898 ] Brandon Williams edited comment on CASSANDRA-17387 at 2/15/22, 11:12 PM: - This test [only runs|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L20] with offheap objects on 3.11, since they are disabled in 3.0. The tested scenario involves old counter shards, so it first [installs 2.0.17|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L33]. In the case of offheap memtables, this is too late for the [dtest setup|https://github.com/apache/cassandra-dtest/blob/trunk/dtest_setup.py#L428] which is applied without discretion, so it's actually 2.0 complaining here about a parameter from the (not so near) future. I don't see how this ever could have worked since the addition of offheap memtables to the dtests, and I don't think using them is particularly valuable for this test, so the simplest thing to do is skip this test when offheap is requested - [done here.|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17387] was (Author: brandon.williams): This test [only runs|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L20] with offheap objects on 3.11, since they are disabled in 3.0. The tested scenario involves old counter shards, so it first [installs 2.0.17|https://github.com/apache/cassandra-dtest/blob/trunk/counter_test.py#L33]. In the case of offheap memtables, this is too late for the [dtest setup|https://github.com/apache/cassandra-dtest/blob/trunk/dtest_setup.py#L428] which is applied without discretion, so it's actually 2.0 complaining here about a parameter from the (not so near) future. I don't see how this ever could have worked since the addition of offheap to the dtests, and I don't think using them is particularly valuable for this test, so the simplest thing to do is skip this test when offheap is requested - [done here.|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17387] > Test failure: dtest-offheap.counter_test.TestCounters.test_13691 > > > Key: CASSANDRA-17387 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17387 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Ekaterina Dimitrova >Assignee: Brandon Williams >Priority: Urgent > Fix For: 3.11.x > > > This test fails only off heap on 3.11, hard to say when it started as it was > always failing since we have Butler. Marking it critical as it shows breaking > config change. > h3. Stacktrace > Unexpected error found in node logs (see stdout for full details). Errors: > [ERROR [main] 2022-02-10 05:06:27,462 DatabaseDescriptor.java (line 117) > Fatal configuration error > org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please > remove properties [memtable_allocation_type] from your cassandra.yaml at > org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:137) > at > org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:100) > at -- 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-17292) Move cassandra.yaml toward a nested structure around major database concepts
[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492922#comment-17492922
]
Caleb Rackliffe commented on CASSANDRA-17292:
-
[~benedict] [~dcapwell] [~adelapena] [~e.dimitrova] Alright, took me a while,
but I've pushed up a proposal
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a],
with some inline comments to explain some bits I'm not 100% happy about.
> Move cassandra.yaml toward a nested structure around major database concepts
>
>
> Key: CASSANDRA-17292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17292
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new
> features") has made it clear we will gravitate toward appropriately nested
> structures for new parameters in {{cassandra.yaml}}, but from the scattered
> conversation across a few Guardrails tickets (see CASSANDRA-17212 and
> CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to
> eventually extend this to the rest of {{cassandra.yaml}}. The benefits of
> this change include those we gain by doing it for new features (single point
> of interest for feature documentation, typed configuration objects, logical
> grouping for additional parameters added over time, discoverability, etc.),
> but one a larger scale.
> This may overlap with ongoing work, including the Guardrails epic. Ideally,
> even a rough cut of a design here would allow that to move forward in a
> timely and coherent manner (with less long-term refactoring pain).
> While these would have to be adjusted to CASSANDRA-15234 (probably after it
> merges), there have been two proposals floated already for what this might
> look like:
> From [~maedhroz] -
> https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8
> From [~benedict] -
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
--
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-17292) Move cassandra.yaml toward a nested structure around major database concepts
[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492922#comment-17492922
]
Caleb Rackliffe edited comment on CASSANDRA-17292 at 2/16/22, 12:00 AM:
[~benedict] [~dcapwell] [~adelapena] [~e.dimitrova] Alright, took me a while,
but I've pushed up a proposal
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a],
with some inline comments to explain some bits I'm not 100% happy about. In
some areas, I've actually borrowed pretty heavily from Benedict's work.
was (Author: maedhroz):
[~benedict] [~dcapwell] [~adelapena] [~e.dimitrova] Alright, took me a while,
but I've pushed up a proposal
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a],
with some inline comments to explain some bits I'm not 100% happy about.
> Move cassandra.yaml toward a nested structure around major database concepts
>
>
> Key: CASSANDRA-17292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17292
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new
> features") has made it clear we will gravitate toward appropriately nested
> structures for new parameters in {{cassandra.yaml}}, but from the scattered
> conversation across a few Guardrails tickets (see CASSANDRA-17212 and
> CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to
> eventually extend this to the rest of {{cassandra.yaml}}. The benefits of
> this change include those we gain by doing it for new features (single point
> of interest for feature documentation, typed configuration objects, logical
> grouping for additional parameters added over time, discoverability, etc.),
> but one a larger scale.
> This may overlap with ongoing work, including the Guardrails epic. Ideally,
> even a rough cut of a design here would allow that to move forward in a
> timely and coherent manner (with less long-term refactoring pain).
> While these would have to be adjusted to CASSANDRA-15234 (probably after it
> merges), there have been two proposals floated already for what this might
> look like:
> From [~maedhroz] -
> https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8
> From [~benedict] -
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
--
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-17292) Move cassandra.yaml toward a nested structure around major database concepts
[
https://issues.apache.org/jira/browse/CASSANDRA-17292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492922#comment-17492922
]
Caleb Rackliffe edited comment on CASSANDRA-17292 at 2/16/22, 12:01 AM:
[~benedict] [~dcapwell] [~adelapena] [~e.dimitrova] Alright, took me a while,
but I've pushed up a proposal
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a],
with some inline comments to explain some bits I'm not 100% happy about. In
some areas, I've actually borrowed pretty heavily from Benedict's work. In the
context of the ongoing guardrails work, I'd make particular note of the
migration of those elements to {{schema}} and {{requests}}.
was (Author: maedhroz):
[~benedict] [~dcapwell] [~adelapena] [~e.dimitrova] Alright, took me a while,
but I've pushed up a proposal
[here|https://github.com/maedhroz/cassandra/commit/450b920e0ac072cec635e0ebcb63538ee7f1fc5a],
with some inline comments to explain some bits I'm not 100% happy about. In
some areas, I've actually borrowed pretty heavily from Benedict's work.
> Move cassandra.yaml toward a nested structure around major database concepts
>
>
> Key: CASSANDRA-17292
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17292
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.x
>
>
> Recent mailing list conversation (see "[DISCUSS] Nested YAML configs for new
> features") has made it clear we will gravitate toward appropriately nested
> structures for new parameters in {{cassandra.yaml}}, but from the scattered
> conversation across a few Guardrails tickets (see CASSANDRA-17212 and
> CASSANDRA-17148) and CASSANDRA-15234, there is also a general desire to
> eventually extend this to the rest of {{cassandra.yaml}}. The benefits of
> this change include those we gain by doing it for new features (single point
> of interest for feature documentation, typed configuration objects, logical
> grouping for additional parameters added over time, discoverability, etc.),
> but one a larger scale.
> This may overlap with ongoing work, including the Guardrails epic. Ideally,
> even a rough cut of a design here would allow that to move forward in a
> timely and coherent manner (with less long-term refactoring pain).
> While these would have to be adjusted to CASSANDRA-15234 (probably after it
> merges), there have been two proposals floated already for what this might
> look like:
> From [~maedhroz] -
> https://github.com/maedhroz/cassandra/commit/49e83c70eba3357978d1081ecf500bbbdee960d8
> From [~benedict] -
> https://github.com/belliottsmith/cassandra/commits/CASSANDRA-15234-grouping-ideas
--
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-17381) Produce and verify BoundedReadCompactionStrategy as a unified general purpose compaction algorithm
[ https://issues.apache.org/jira/browse/CASSANDRA-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492941#comment-17492941 ] Joey Lynch commented on CASSANDRA-17381: The PoC patch is against 3.0, but yeah if we wanted to land this in trunk it would need to be rebased there (I don't think that the Compaction interface has changed too much). > Produce and verify BoundedReadCompactionStrategy as a unified general purpose > compaction algorithm > -- > > Key: CASSANDRA-17381 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17381 > Project: Cassandra > Issue Type: Improvement > Components: Local/Compaction >Reporter: Joey Lynch >Assignee: Joey Lynch >Priority: Normal > Labels: gsoc, gsoc2022 > > The existing compaction strategies have a number of drawbacks that make all > three unsuitable as a general use compaction strategy, for example STCS > creates giant files that are hard to back up, mess with read performance and > the page cache, and led to many of the early re-open bugs. LCS improved > dramatically on this but also has various issues e.g. lack of performant full > compaction or due to the strict leveling with e.g. bulk loading when writes > exceed the rate we can do the L0 - L1 promotion. > In this > [talk|https://github.com/ngcc/ngcc2019/blob/master/NextGenerationCassandraCompactionGoingBeyondLCS.pdf] > I proposed a novel compaction strategy that aims to expose a single tunable > that the user can control for the read amplification. Raise the > min_threshold_levels and you tradeoff read/space performance for write > performance. Since then a proof of concept [patch > |https://github.com/jolynch/cassandra/tree/jolynch_bounded_read_final]has > been published along with some rudimentary [documentation > |https://gist.github.com/jolynch/9118465f32ad5298b4e39d03ccd4370e] but this > is still not tracked in Jira. > The remaining work here is > 1. Validate the algorithm is correct via test suites and performance testing > stress testing and benchmarking with OSS tools (e.g. cassandra-stress, > [tlp-stress|https://github.com/thelastpickle/tlp-stress], or > [ndbench|https://github.com/Netflix/ndbench]). When issues are found (there > likely will be issues as the patch is a PoC), devise how to adjust the > algorithm and implementation appropriately. Key metric of success is we can > run Cassandra stably for more than 24 hours while applying sustained load, > with minimal compaction load (and also compaction can keep up). > 2. Do more in depth experiments measuring performance across a wide range of > workloads (e.g. write heavy, read heavy, balanced, time series, register > update, etc ...) and in comparison with LCS (leveled), STCS (size tiered), > and TWCS (time window). Key metrics of success are establishing that as we > tune max_read_per_read we should get more predictable read latency under low > system load (ρ < 30%) while not degrading at high system load (ρ > 70%), and > we should match LCS performance under low load while doing better at high > load. > Once this is validated a Cassandra blog post reporting on the findings > (positive or negative) may be advisable. > -- 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-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492955#comment-17492955 ] Brad Schoening commented on CASSANDRA-17293: The issue reproducing this was the base directory chosen to run the tests, cassandra/pylib vs cassandra/pylib/cqlshlib. They yield different outputs for test_sslhandling.py depending upon if test/config files for ssl were found or not. A new fix has been checked in, and (fingers crossed) should resolve the test_sslhandling.py failures. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- 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-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492962#comment-17492962 ] Brandon Williams commented on CASSANDRA-17293: -- [Circle|https://app.circleci.com/pipelines/github/driftx/cassandra/362/workflows/216c1567-9aaa-4a53-b39d-c2ff99a10e37] > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- 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-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17492955#comment-17492955 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/16/22, 2:31 AM: -- The issue reproducing the errors was the base directory chosen to run the tests, cassandra/pylib vs cassandra/pylib/cqlshlib. They yield different outputs for test_sslhandling.py depending upon if test/config files for ssl were found or not. A new fix has been checked in, and (fingers crossed) should resolve the test_sslhandling.py failures. was (Author: bschoeni): The issue reproducing this was the base directory chosen to run the tests, cassandra/pylib vs cassandra/pylib/cqlshlib. They yield different outputs for test_sslhandling.py depending upon if test/config files for ssl were found or not. A new fix has been checked in, and (fingers crossed) should resolve the test_sslhandling.py failures. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- 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-17293) Update python test framework from nose to pytest
[ https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491233#comment-17491233 ] Brad Schoening edited comment on CASSANDRA-17293 at 2/16/22, 2:40 AM: -- I first looked at nose2, but nose2 does not fully support nose. Pytest actually does support most of nose, required fewer changes and is a more popular framework, so I've updated it to run with pytest. was (Author: bschoeni): I first looked at nose2, but nose2 does not fully support nose. But pytest required fewer changes and is a more popular framework, so I've updated it to run with pytest. > Update python test framework from nose to pytest > > > Key: CASSANDRA-17293 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17293 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > I had trouble trying to install and run the python nose test from pip > (nosetest not found). > According to the homepage of nose at [https://nose.readthedocs.io/en/latest/] > h1. _Note to Users_ > _Nose has been in maintenance mode for the past several years and will likely > cease without a new person/team to take over maintainership. New projects > should consider using [Nose2|https://github.com/nose-devs/nose2], > [py.test|http://pytest.org/], or just plain unittest/unittest2._ > > Upgrading to pytest is likely the least effort. -- 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-17293) Update python test framework from nose to pytest
[
https://issues.apache.org/jira/browse/CASSANDRA-17293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493031#comment-17493031
]
Berenguer Blasi commented on CASSANDRA-17293:
-
Hi,
the failure is legit imo. I can run all tests locally from trunk without a
failure:
{noformat}
nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$']
test_cql_reserved_keywords (cqlshlib.test.test_constants.TestConstants) ... ok
Test behavior of ExportTask internal get_ranges function ... ok
test_colons_in_string_literals (cqlshlib.test.test_cql_parsing.TestCqlParsing)
... ok
test_comments_in_string_literals
(cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_alter_table (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_batch (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_create_index (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_create_keyspace (cqlshlib.test.test_cql_parsing.TestCqlParsing) ...
ok
test_parse_create_table (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_delete (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_drop_index (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_drop_keyspace (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_drop_table (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_insert (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_numbers (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_pgstring_literals (cqlshlib.test.test_cql_parsing.TestCqlParsing)
... ok
test_parse_select (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_select_token (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_string_literals (cqlshlib.test.test_cql_parsing.TestCqlParsing) ...
ok
test_parse_truncate (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_update (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_use (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_parse_uuid (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_partial_parsing (cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_strip_comment_blocks_from_input
(cqlshlib.test.test_cql_parsing.TestCqlParsing) ... ok
test_complete_command_words
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_alter_keyspace
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_batch
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_create_columnfamily
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_create_keyspace
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_create_table
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_delete
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_describe
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_drop (cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion)
... ok
test_complete_in_drop_keyspace
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_grant
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_insert
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_revoke
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_select
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_string_literals
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_update
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_complete_in_uuid (cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion)
... ok
test_complete_on_empty_string
(cqlshlib.test.test_cqlsh_completion.TestCqlshCompletion) ... ok
test_blob_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_boolean_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_cancel_statement (cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_color_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_columnless_key_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput)
... ok
test_count_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_describe_cluster_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput)
... ok
test_describe_columnfamilies_output
(cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_describe_columnfamily_output
(cqlshlib.test.test_cqlsh_output.TestCqlshOutput) ... ok
test_describe_keyspace_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput)
... ok
test_describe_schema_output (cqlshlib.test.test_cqlsh_output.TestCqlshOutput)
... ok
test_empty_cf_out
[jira] [Updated] (CASSANDRA-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi updated CASSANDRA-17186:
Reviewers: Andres de la Peña, Berenguer Blasi (was: Andres de la Peña)
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
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-17186) Guardrail for number of partition keys on IN queries
[
https://issues.apache.org/jira/browse/CASSANDRA-17186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493034#comment-17493034
]
Berenguer Blasi commented on CASSANDRA-17186:
-
[~adelapena] can you create a PR for me please? I tried to but I don't have
permissions. Hunting down lines amongst commits it's a pain :-) Mainly I have
some formatting nits, some naming concern and a small other suggestion.
> Guardrail for number of partition keys on IN queries
>
>
> Key: CASSANDRA-17186
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17186
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Krishna Vadali
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add a guardrail for limiting the number of partitions restricted with an
> {{IN}} clause in a {{SELECT}} query, for example:
> {code:java}
> # Guardrail to warn or abort when querying with an IN restriction selecting
> # more partition keys than threshold.
> # The two thresholds default to -1 to disable.
> partition_keys_in_select:
> warn_threshold: -1
> abort_threshold: -1
> {code}
> +Additional information for newcomers:+
> * Add the configuration for the new guardrail on the number of partitions on
> IN queries in the guardrails section of cassandra.yaml.
> * Add a getPartitionKeysInSelect method in GuardrailsConfig returning a
> Threshold.Config object
> * Implement that method in GuardrailsOptions, which is the default
> yaml-based implementation of GuardrailsConfig
> * Add a Threshold guardrail named partitionKeysInSelect in Guardrails, using
> the previously created config
> * Define JMX-friendly getters and setters for the previously created config
> in GuardrailsMBean
> * Implement the JMX-friendly getters and setters in Guardrails
> * Now that we have the guardrail ready, it’s time to use it. We should
> search for a place to invoke the Guardrails.partitionKeysInSelect#guard
> method with the number of keys specified in select query. The
> SelectStatement#getSliceCommands methods look like good candidates for this.
> * Finally, add some tests for the new guardrail. Given that the new
> guardrail is a Threshold, our new test should probably extend ThresholdTester.
--
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-17272) LeveledCompactionStrategy disk space check improvements
[ https://issues.apache.org/jira/browse/CASSANDRA-17272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17493040#comment-17493040 ] Marcus Eriksson commented on CASSANDRA-17272: - bq. Just to make sure I have things straight, the only difference between 3.0 and 3.11+ is the latter avoids the unnecessary call to getWriteDirectory() in the various realAppend() overrides? yeah write directory in 3.11+ is based on the token instead of the size > LeveledCompactionStrategy disk space check improvements > --- > > Key: CASSANDRA-17272 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17272 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction/LCS >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Time Spent: 2h 10m > Remaining Estimate: 0h > > We currently allow reducing scope (removing sstables from the compaction) > when starting STCS-in-L0 with LCS if the compaction is too large for the > available disk space. We can do the same for L0 -> L1 compactions - but we > can only remove L0 sstables to avoid causing overlap in L1. > Also, in 3.0, when starting an LCS compaction we try to [get a writeable > location|https://github.com/apache/cassandra/blob/b1a8a56c563b85ab9a34d3bbf9c16278dd441157/src/java/org/apache/cassandra/db/compaction/writers/CompactionAwareWriter.java#L128] > where the full result of the compaction will fit - here we should only get a > directory where the first sstable fits, otherwise the compaction might fail > even though there is enough space in total among the data directories -- 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
