[jira] [Commented] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521465#comment-17521465
]
Berenguer Blasi commented on CASSANDRA-10537:
-
[~Antoine Rocheteau] I fired a different CI run as jenkins seems to be having
trouble now. There seems to be a small failure
[here|https://app.circleci.com/pipelines/github/bereng/cassandra/640/workflows/c0e44dc1-f997-4cc9-9776-ef544be567e4/jobs/5681].
The rest of the
[run|https://app.circleci.com/pipelines/github/bereng/cassandra/640/workflows/c0e44dc1-f997-4cc9-9776-ef544be567e4]
lgtm though, those oversized mutation failures are unrelated to this ticket.
Once that last failure is fixed I can merge :-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada edited comment on CASSANDRA-17513 at 4/13/22 5:36 AM: -- [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. You have to remember that for validating client with client cert, you need 'truststore' and to be able to send server cert to client, you need 'keystore'. Please let me know if this helps. was (Author: maulin.vasavada): [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521459#comment-17521459 ] Maulin Vasavada commented on CASSANDRA-17513: - [~Jyothsnakonisa] The existing cassandra yaml configurations under client_encryption_options must suffice for your needs. For the inbound traffic (from client to the server nodes) when you want to authenticate client with client certs, you would have to put the trusted CAs in the truststore configuration under client_encryption_options. For the outbound traffic (from server node to client) you need to configure keystore with server key/cert under client_encryption_options. Cassandra code looks at the client_encryption_options and uses the configured truststore and keystore appropriately. Please let me know if this helps. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17549) jvm-dtest unhandled exceptions failing the test no longer work
[ https://issues.apache.org/jira/browse/CASSANDRA-17549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17549: -- Bug Category: Parent values: Correctness(12982)Level 1 values: Transient Incorrect Response(12987) Complexity: Normal Discovered By: Code Inspection Fix Version/s: 4.1 Severity: Normal Status: Open (was: Triage Needed) marking 4.1 as this feature detects subtle bugs, so with this broken we could have subtle things failing, so we may actually have failing tests but think passing. > jvm-dtest unhandled exceptions failing the test no longer work > -- > > Key: CASSANDRA-17549 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17549 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/java >Reporter: David Capwell >Priority: Normal > Fix For: 4.1 > > > Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution) > refactored and avoided using AbstractCluster.uncaughtException, this means > that the logic to detect unexpected exceptions to fail tests no longer works. -- 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-17549) jvm-dtest unhandled exceptions failing the test no longer work
David Capwell created CASSANDRA-17549: - Summary: jvm-dtest unhandled exceptions failing the test no longer work Key: CASSANDRA-17549 URL: https://issues.apache.org/jira/browse/CASSANDRA-17549 Project: Cassandra Issue Type: Bug Components: Test/dtest/java Reporter: David Capwell Seems that ([CASSANDRA-16925] CEP-10 Phase 1: Mockable Task Execution) refactored and avoided using AbstractCluster.uncaughtException, this means that the logic to detect unexpected exceptions to fail tests no longer works. -- 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-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521404#comment-17521404
]
Ekaterina Dimitrova edited comment on CASSANDRA-14752 at 4/13/22 1:37 AM:
--
So I reran the upgrade tests with 3.11 in CircleCI without the patch. -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1533/workflows/118fff4b-1d4f-4fd6-8b2d-c33dd8f76bde/jobs/9933/tests
The only two tests that failed with my patch and I don't see in the list of
failures without are:
upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_11_x_To_indev_trunk -
I found it in Butler, trunk
(https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_trunk/test_noncomposite_static_cf/)
test_noncomposite_static_cf - found it again on trunk...
https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/cls/test_noncomposite_static_cf/
So to conclude, I see the same failures, except two which for some reason in
Butler appear under trunk and not 3.11... I am not sure why I see what I see...
I got +1 on the patch on green CI from [~blerer] in Slack.
I consider all failures known and I will open a ticket to align how we run the
upgrade tests in Circle and in Jenkins to ensure we don't miss anything...
I will wait until tomorrow to commit the patch as there is some Jenkins issue
and I see the last runs marked in red. Infra is checking.
was (Author: e.dimitrova):
So I reran the upgrade tests with 3.11 in CircleCI without the patch. -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1533/workflows/118fff4b-1d4f-4fd6-8b2d-c33dd8f76bde/jobs/9933/tests
The only two tests I don't see in the list of failures are:
upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_11_x_To_indev_trunk -
I found it in Butler, trunk
(https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_trunk/test_noncomposite_static_cf/)
test_noncomposite_static_cf - found it again on trunk...
https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/cls/test_noncomposite_static_cf/
So to conclude, I see the same failures, except two which for some reason in
Butler appear under trunk and not 3.11... I am not sure why I see what I see...
I got +1 on the patch on green CI from [~blerer] in Slack.
I consider all failures known and I will open a ticket to align how we run the
upgrade tests in Circle and in Jenkins to ensure we don't miss anything...
I will wait until tomorrow to commit the patch as there is some Jenkins issue
and I see the last runs marked in red. Infra is checking.
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
[jira] [Commented] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521404#comment-17521404
]
Ekaterina Dimitrova commented on CASSANDRA-14752:
-
So I reran the upgrade tests with 3.11 in CircleCI without the patch. -
https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1533/workflows/118fff4b-1d4f-4fd6-8b2d-c33dd8f76bde/jobs/9933/tests
The only two tests I don't see in the list of failures are:
upgrade_tests.cql_tests.TestCQLNodes2RF1_Upgrade_indev_3_11_x_To_indev_trunk -
I found it in Butler, trunk
(https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/TestCQLNodes2RF1_Upgrade_indev_3_0_x_To_indev_trunk/test_noncomposite_static_cf/)
test_noncomposite_static_cf - found it again on trunk...
https://ci-cassandra.apache.org/job/Cassandra-trunk/1076/testReport/dtest-upgrade.upgrade_tests.cql_tests/cls/test_noncomposite_static_cf/
So to conclude, I see the same failures, except two which for some reason in
Butler appear under trunk and not 3.11... I am not sure why I see what I see...
I got +1 on the patch on green CI from [~blerer] in Slack.
I consider all failures known and I will open a ticket to align how we run the
upgrade tests in Circle and in Jenkins to ensure we don't miss anything...
I will wait until tomorrow to commit the patch as there is some Jenkins issue
and I see the last runs marked in red. Infra is checking.
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17532: Status: Review In Progress (was: Needs Committer) > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17532: Status: Needs Committer (was: Review In Progress) > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521377#comment-17521377
]
Ekaterina Dimitrova edited comment on CASSANDRA-17379 at 4/12/22 11:15 PM:
---
Thank you for the patch! I think I can review it tomorrow. Just wanted to
mention we need to update also Docs and NEWS.txt. Also, I think it will be good
to run all upgrade tests pre-commit.
was (Author: e.dimitrova):
Thank you for the patch! I think I can review it tomorrow. Just wanted to
mention we need to update also Docs and NEWS.txt. Also, I think it will be good
to run the Python upgrade tests pre-commit.
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17379) Fail starting when the same parameter exists more than once with different values in cassandra.yaml
[
https://issues.apache.org/jira/browse/CASSANDRA-17379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521377#comment-17521377
]
Ekaterina Dimitrova commented on CASSANDRA-17379:
-
Thank you for the patch! I think I can review it tomorrow. Just wanted to
mention we need to update also Docs and NEWS.txt. Also, I think it will be good
to run the Python upgrade tests pre-commit.
> Fail starting when the same parameter exists more than once with different
> values in cassandra.yaml
>
>
> Key: CASSANDRA-17379
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17379
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Marcus Eriksson
>Priority: Low
> Fix For: 4.x
>
>
> The way that SnakeYAML works, if someone has added the same parameter more
> than once - the last occurrence will be the one that will take precedence.
> Now after CASSANDRA-15234 we can even add the parameter with the old name and
> with the new name and the occurrences will replace each other. Again,
> whatever is last in cassandra.yaml will take precedence. Example:
> If you add the following in cassandra.yaml
> {code:java}
> hinted_handoff_enabled: true
> enabled_hinted_handolff: false
> {code}
> you will get loaded in Config -
> {code:java}
> hinted_handoff_enabled: false{code}
> //there is backward compatibility from the old name to load into the new one
> Currently Cassandra prints in the logs what config was loaded but it is good
> also to detect the case mentioned and emit a warning for the user so they can
> verify that the value they wanted was loaded in config.
> To do that you might want to look at the PropertiesChecker and the way we
> emit other warnings in
> [check()|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/YamlConfigurationLoader.java#L376]
> in YamlConfigurationLoader.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17509) Add Guardrail to disable GROUP BY functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521365#comment-17521365 ] Josh McKenzie commented on CASSANDRA-17509: --- bq. we should probably create tickets for them. Agree; I ran a clean (i.e. vanilla trunk) circle run earlier today as a reference and am planning on getting together a focused effort to get us to stable green there in the run up to the freeze. I'll make sure failures from here make it to that effort. > Add Guardrail to disable GROUP BY functionality > --- > > Key: CASSANDRA-17509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17509 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > GROUP BY can be expensive and troublesome on large tables. We should have a > guardrail to disable this in clusters where we don't want users to have this > functionality. -- 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-17545) Fix Travis CI for Python DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17545:
Fix Version/s: 4.1
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra-dtest/commit/029e1903cfed2e710b366cba5360f443db2139d0
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
> Fix Travis CI for Python DTests
> ---
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.1
>
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-17545) Fix Travis CI for Python DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17545:
Fix Version/s: (was: 4.1)
> Fix Travis CI for Python DTests
> ---
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-17545) Fix Travis CI for Python DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521356#comment-17521356
]
Ekaterina Dimitrova commented on CASSANDRA-17545:
-
Committed, thanks
> Fix Travis CI for Python DTests
> ---
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-17545) Fix Travis CI for Python DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17545:
Since Version: (was: 4.0)
> Fix Travis CI for Python DTests
> ---
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-dtest] branch trunk updated: Fix Travis CI issue - The unauthenticated git protocol on port 9418 is no longer supported. patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSA
This is an automated email from the ASF dual-hosted git repository. edimitrova pushed a commit to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra-dtest.git The following commit(s) were added to refs/heads/trunk by this push: new 029e1903 Fix Travis CI issue - The unauthenticated git protocol on port 9418 is no longer supported. patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-17545 029e1903 is described below commit 029e1903cfed2e710b366cba5360f443db2139d0 Author: Ekaterina Dimitrova AuthorDate: Mon Apr 11 18:08:43 2022 -0400 Fix Travis CI issue - The unauthenticated git protocol on port 9418 is no longer supported. patch by Ekaterina Dimitrova; reviewed by Brandon Williams for CASSANDRA-17545 --- .travis.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.travis.yml b/.travis.yml index e170b510..0bf45ebb 100644 --- a/.travis.yml +++ b/.travis.yml @@ -10,7 +10,7 @@ script: # we use flake8 because it allows us to ignore other warnings # exclude the thrift directories - they contain auto-generated code # - flake8 --ignore=E501,F811,F812,F822,F823,F831,F841,N8,C9 --exclude=thrift_bindings,cassandra-thrift . - - git remote add apache git://github.com/apache/cassandra-dtest.git + - git remote add apache https://github.com/apache/cassandra-dtest.git - git fetch apache # fetch master for the next diff # feed changed lines with no context around them to pycodestyle # I know we don't enforce line length but if you introduce - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17545) Fix Travis CI for Python DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17545:
-
Summary: Fix Travis CI for Python DTests (was: Fix Travis CI for Pyhon
DTests)
> Fix Travis CI for Python DTests
> ---
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-14752) serializers/BooleanSerializer.java is using static bytebuffers which may cause problem for subsequent operations
[
https://issues.apache.org/jira/browse/CASSANDRA-14752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520837#comment-17520837
]
Ekaterina Dimitrova edited comment on CASSANDRA-14752 at 4/12/22 10:05 PM:
---
The upgrade_udtfix_test look suspicious from the perspective they don't fail in
Jenkins (talking about Cassandra-3.11).
I pushed in a loop with the patch:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1532/workflows/dc444e1f-42ca-4993-b053-5a9c69ba1c2d]
Without the patch:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1533/workflows/118fff4b-1d4f-4fd6-8b2d-c33dd8f76bde]
Everything is green and when you try to look at the logs - test runs were just
skipped this made me check Jenkins, it seems those tests are skipped also
there...
Maybe [~jlewandowski], [~brandon.williams] or [~mck] will know something? I see
the three of you were interacting with those tests before.
The rest of the failures are all known with associated tickets.
was (Author: e.dimitrova):
The upgrade_udtfix_test look suspicious from the perspective they don't fail in
Jenkins.
I pushed in a loop with the patch:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1532/workflows/dc444e1f-42ca-4993-b053-5a9c69ba1c2d]
Without the patch:
[https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1533/workflows/118fff4b-1d4f-4fd6-8b2d-c33dd8f76bde]
Everything is green and when you try to look at the logs - test runs were just
skipped this made me check Jenkins, it seems those tests are skipped also
there...
Maybe [~jlewandowski], [~brandon.williams] or [~mck] will know something? I see
the three of you were interacting with those tests before.
The rest of the failures are all known with associated tickets.
> serializers/BooleanSerializer.java is using static bytebuffers which may
> cause problem for subsequent operations
>
>
> Key: CASSANDRA-14752
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14752
> Project: Cassandra
> Issue Type: Bug
> Components: Legacy/Core
>Reporter: Varun Barala
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: patch, patch-modified
>
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L26]
> It has two static Bytebuffer variables:-
> {code:java}
> private static final ByteBuffer TRUE = ByteBuffer.wrap(new byte[]{1});
> private static final ByteBuffer FALSE = ByteBuffer.wrap(new byte[]{0});{code}
> What will happen if the position of these Bytebuffers is being changed by
> some other operations? It'll affect other subsequent operations. -IMO Using
> static is not a good idea here.-
> A potential place where it can become problematic:
> [https://github.com/apache/cassandra/blob/cassandra-2.1.13/src/java/org/apache/cassandra/db/marshal/AbstractCompositeType.java#L243]
> Since we are calling *`.remaining()`* It may give wrong results _i.e 0_ if
> these Bytebuffers have been used previously.
> Solution:
>
> [https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/serializers/BooleanSerializer.java#L42]
> Every time we return new bytebuffer object. Please do let me know If there
> is a better way. I'd like to contribute. Thanks!!
> {code:java}
> public ByteBuffer serialize(Boolean value)
> {
> return (value == null) ? ByteBufferUtil.EMPTY_BYTE_BUFFER
> : value ? ByteBuffer.wrap(new byte[] {1}) : ByteBuffer.wrap(new byte[] {0});
> // false
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17545) Fix Travis CI for Pyhon DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17545:
-
Status: Ready to Commit (was: Review In Progress)
> Fix Travis CI for Pyhon DTests
> --
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-17545) Fix Travis CI for Pyhon DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521354#comment-17521354
]
Brandon Williams commented on CASSANDRA-17545:
--
+1
> Fix Travis CI for Pyhon DTests
> --
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {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-17545) Fix Travis CI for Pyhon DTests
[
https://issues.apache.org/jira/browse/CASSANDRA-17545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17545:
-
Reviewers: Brandon Williams, Brandon Williams
Brandon Williams, Brandon Williams (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Fix Travis CI for Pyhon DTests
> --
>
> Key: CASSANDRA-17545
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17545
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
>
> Seems like in the past month Travis CI is failing with the following issue:
>
> {code:java}
> fatal: remote error:
> The unauthenticated git protocol on port 9418 is no longer supported.
> Please see
> https://github.blog/2021-09-01-improving-git-protocol-security-github/ for
> more information.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521352#comment-17521352 ] Ekaterina Dimitrova edited comment on CASSANDRA-17532 at 4/12/22 10:02 PM: --- Opened and linked to this ticket CASSANDRA-17548, to be clear we don't solve here the limitation of the framework and that this should be done in CASSANDRA-17548. This ticket has the idea of not silently ignoring that checks are not happening until the other one is taken care of. was (Author: e.dimitrova): Opened and linked to this ticket CASSANDRA-17548, to be clear we don't solve here the limitation of the framework and that this should be done in CASSANDRA-17548. > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521352#comment-17521352 ] Ekaterina Dimitrova commented on CASSANDRA-17532: - Opened and linked to this ticket CASSANDRA-17548, to be clear we don't solve here the limitation of the framework and that this should be done in CASSANDRA-17548. > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17537: -- Test and Documentation Plan: new tests Status: Patch Available (was: In Progress) > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- 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-17548) In-jvm framework to plugin yaml config per version
[ https://issues.apache.org/jira/browse/CASSANDRA-17548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17548: Change Category: Quality Assurance Complexity: Normal Component/s: CI Fix Version/s: 4.x Status: Open (was: Triage Needed) > In-jvm framework to plugin yaml config per version > -- > > Key: CASSANDRA-17548 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17548 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Remove Constants.KEY_DTEST_API_CONFIG_CHECK which currently is set to false > for in-jvm upgrade tests which means we don't do the regular checks for > invalid yaml that Cassandra does on startup for those tests. > We need to be able to acknowledge new config parameters added to newer > versions. Those should be ignored in the old Cassandra versions during > upgrade tests instead of ignoring the checks for the whole configuration file > on all Cassandra versions. -- 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-17548) In-jvm framework to plugin yaml config per version
Ekaterina Dimitrova created CASSANDRA-17548: --- Summary: In-jvm framework to plugin yaml config per version Key: CASSANDRA-17548 URL: https://issues.apache.org/jira/browse/CASSANDRA-17548 Project: Cassandra Issue Type: Improvement Reporter: Ekaterina Dimitrova Remove Constants.KEY_DTEST_API_CONFIG_CHECK which currently is set to false for in-jvm upgrade tests which means we don't do the regular checks for invalid yaml that Cassandra does on startup for those tests. We need to be able to acknowledge new config parameters added to newer versions. Those should be ignored in the old Cassandra versions during upgrade tests instead of ignoring the checks for the whole configuration file on all Cassandra versions. -- 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-17537) nodetool compact should support using a key string to find the range to avoid operators having to manually do this
[ https://issues.apache.org/jira/browse/CASSANDRA-17537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell reassigned CASSANDRA-17537: - Assignee: David Capwell > nodetool compact should support using a key string to find the range to avoid > operators having to manually do this > -- > > Key: CASSANDRA-17537 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17537 > Project: Cassandra > Issue Type: New Feature > Components: Local/Compaction, Tool/nodetool >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > > Its common that a single key needs to be compact, and operators need to do > the following > 1) go from key -> token > 2) generate range > 3) call nodetool compact with this range > We can simply this workflow by adding this to compact > nodetool compact ks.tbl -k “key1" -- 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-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17543:
Reviewers: Caleb Rackliffe
> ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE
> coordinator=1 flush=false paging=false] times out sporadically
> ---
>
> Key: CASSANDRA-17543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Andres de la Peña
>Priority: Normal
>
> org.apache.cassandra.distributed.test.ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8:
> strategy=NONE coordinator=1 flush=false paging=false]
> {noformat}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 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)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> 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)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> See
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1075/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/testUnrestrictedQueryOnSkinnyTable_8__strategy_NONE_coordinator_1_flush_false_paging_false_/
--
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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521339#comment-17521339
]
Ekaterina Dimitrova commented on CASSANDRA-17532:
-
{code:java}
The problem we face is that InstanceConfig on trunk gets configs added that
make sense on trunk but not older versions;
{code}
This problem is with all versions, not only trunk. We have new config added to
every major version which doesn't exist in older versions.
{code:java}
I feel this patch doesn't solve the intent, making our tests safer by checking;
as the tests still don't check they are just more verbose.
{code}
Valid point, it was never its intention to solve this limitation, same as the
flag when it was introduced. The reason why I suggested to flip the flag was to
make it verbose to people so they know this flag exists and they check their
config intentionally before setting in a new test until that limitation is
solved.
Otherwise, currently we never check the config by default, most of the people
don't know about the flag and don't check it also manually carefully as they
would expect Cassandra to complain as usual. I documented this behavior on the
config page, but I am not sure how many people will read it at all. So at least
until this is solved people can get an exception for new config and
intentionally check what they set on their own instead of silently config being
ignored and tests passing. Considering a new test is added once in a few
months, it is not a big burden until the limitation is worked out, probably
after the release.
> Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade
> tests
> -
>
> Key: CASSANDRA-17532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17532
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> We reached lazy consensus on this here:
> [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0]
--
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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Capwell updated CASSANDRA-17532:
--
Reviewers: David Capwell
Status: Review In Progress (was: Patch Available)
This patch just moves the below from UpgradeCluster to every test
{code}
set(Constants.KEY_DTEST_API_CONFIG_CHECK, false)
{code}
The problem we face is that InstanceConfig on trunk gets configs added that
make sense on trunk but not older versions; we do not have an ability to
downgrade configs (if using renamed config, switch to old, or if no old exists
drop), so this causes all upgrade tests to fail... we added the flag to
UpgradeCluster due to a lack of versioned config support, so without actually
adding a ability to deal with versioned configs, we don't get a benefit from
this patch.
I feel this patch doesn't solve the intent, making our tests safer by checking;
as the tests still don't check they are just more verbose.
I am +0, I am not a fan but if others want this I will not stand in the way
> Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade
> tests
> -
>
> Key: CASSANDRA-17532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17532
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> We reached lazy consensus on this here:
> [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521330#comment-17521330 ] Stefan Miklosovic edited comment on CASSANDRA-17513 at 4/12/22 8:39 PM: [~maulin.vasavada] your insight is welcomed. was (Author: smiklosovic): [~maulin.vasavada] your insight is welcome. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17513) Add new property to pass keystore for outbound connections
[ https://issues.apache.org/jira/browse/CASSANDRA-17513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521330#comment-17521330 ] Stefan Miklosovic commented on CASSANDRA-17513: --- [~maulin.vasavada] your insight is welcome. > Add new property to pass keystore for outbound connections > -- > > Key: CASSANDRA-17513 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17513 > Project: Cassandra > Issue Type: Bug >Reporter: Jyothsna Konisa >Assignee: Jyothsna Konisa >Priority: Normal > Time Spent: 20m > Remaining Estimate: 0h > > Same keystore is being set for both Inbound and outbound connections but we > should use a keystore with server certificate for Inbound connections and a > keystore with client certificates for outbound connections. So we should add > a new property in Cassandra.yaml to pass outbound keystore and use it in > SSLContextFactory for creating outbound SSL context. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17150) Guardrails for disk usage
[
https://issues.apache.org/jira/browse/CASSANDRA-17150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521327#comment-17521327
]
Stefan Miklosovic commented on CASSANDRA-17150:
---
I am +1, not sure what else we need here. Maybe ping some other committer to
have the second pair of eyes for this.
> Guardrails for disk usage
> -
>
> Key: CASSANDRA-17150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17150
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Add guardrails for disk usage establishing soft/hard limits on the percentage
> of used disk space. For example:
> {code}
> # Warning threshold to warn when local disk usage exceeds threshold. Valid
> values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_warn_threshold: -1
> # Failure threshold to reject write requests if replica disk usage exceeds
> threshold. Valid values: (1, 100]
> # Defaults to -1 to disable.
> # disk_usage_percentage_failure_threshold: -1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yifan Cai updated CASSANDRA-17217:
--
Since Version: 4.0
Source Control Link:
https://github.com/apache/cassandra/commit/2fe1c304835ef39093b70cbb89107383be3c3ee9
Resolution: Fixed
Status: Resolved (was: Ready to Commit)
Committed into trunk as
[2fe1c3048|https://github.com/apache/cassandra/commit/2fe1c304835ef39093b70cbb89107383be3c3ee9]
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
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] branch trunk updated: Fix flaky test LocalReadSizeWarningTest#failThresholdSinglePartition
This is an automated email from the ASF dual-hosted git repository.
ycai pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 2fe1c30483 Fix flaky test
LocalReadSizeWarningTest#failThresholdSinglePartition
2fe1c30483 is described below
commit 2fe1c304835ef39093b70cbb89107383be3c3ee9
Author: Bernardo Botella Corbi
AuthorDate: Tue Apr 12 11:06:41 2022 -0700
Fix flaky test LocalReadSizeWarningTest#failThresholdSinglePartition
patch by Bernardo Botella Corbi; reviewed by Andres de la Peña, Yifan Cai
for CASSANDRA-17217
---
.../trackwarnings/AbstractClientSizeWarning.java | 35 ++
.../trackwarnings/RowIndexSizeWarningTest.java | 8 -
2 files changed, 36 insertions(+), 7 deletions(-)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/AbstractClientSizeWarning.java
b/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/AbstractClientSizeWarning.java
index 42670c7aa1..34b2322a89 100644
---
a/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/AbstractClientSizeWarning.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/AbstractClientSizeWarning.java
@@ -211,15 +211,27 @@ public abstract class AbstractClientSizeWarning extends
TestBaseImpl
}
@Test
-public void failThresholdSinglePartition() throws UnknownHostException
+public void failThresholdSinglePartitionTrackingEnabled() throws
UnknownHostException
{
-failThreshold(CQL_PK_READ);
+failThresholdEnabled(CQL_PK_READ);
}
@Test
-public void failThresholdScan() throws UnknownHostException
+public void failThresholdSinglePartitionTrackingDisabled() throws
UnknownHostException
{
-failThreshold(CQL_TABLE_SCAN);
+failThresholdDisabled(CQL_PK_READ);
+}
+
+@Test
+public void failThresholdScanTrackingEnabled() throws UnknownHostException
+{
+failThresholdEnabled(CQL_TABLE_SCAN);
+}
+
+@Test
+public void failThresholdScanTrackingDisabled() throws UnknownHostException
+{
+failThresholdDisabled(CQL_TABLE_SCAN);
}
protected int failThresholdRowCount()
@@ -227,7 +239,7 @@ public abstract class AbstractClientSizeWarning extends
TestBaseImpl
return 5;
}
-public void failThreshold(String cql) throws UnknownHostException
+public void failThresholdEnabled(String cql) throws UnknownHostException
{
ICoordinator node = CLUSTER.coordinator(1);
for (int i = 0; i < failThresholdRowCount(); i++)
@@ -283,15 +295,26 @@ public abstract class AbstractClientSizeWarning extends
TestBaseImpl
}
assertHistogramUpdated();
assertWarnAborts(0, 2, 1);
+}
+
+public void failThresholdDisabled(String cql) throws UnknownHostException
+{
+ICoordinator node = CLUSTER.coordinator(1);
+for (int i = 0; i < failThresholdRowCount(); i++)
+node.execute("INSERT INTO " + KEYSPACE + ".tbl (pk, ck, v) VALUES
(1, ?, ?)", ConsistencyLevel.ALL, i + 1, bytes(512));
+
+if (shouldFlush())
+CLUSTER.stream().forEach(i -> i.flush(KEYSPACE));
// query should no longer fail
enable(false);
+checkpointHistogram();
SimpleQueryResult result = node.executeWithResult(cql,
ConsistencyLevel.ALL);
assertThat(result.warnings()).isEmpty();
assertHistogramNotUpdated();
assertThat(driverQueryAll(cql).getExecutionInfo().getWarnings()).isEmpty();
assertHistogramNotUpdated();
-assertWarnAborts(0, 2, 0);
+assertWarnAborts(0, 0, 0);
}
protected static void enable(boolean value)
diff --git
a/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/RowIndexSizeWarningTest.java
b/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/RowIndexSizeWarningTest.java
index 5a2957d207..43f3061329 100644
---
a/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/RowIndexSizeWarningTest.java
+++
b/test/distributed/org/apache/cassandra/distributed/test/trackwarnings/RowIndexSizeWarningTest.java
@@ -84,7 +84,13 @@ public class RowIndexSizeWarningTest extends
AbstractClientSizeWarning
}
@Override
-public void failThresholdScan()
+public void failThresholdScanTrackingEnabled()
+{
+Assume.assumeFalse("Ignore Scans", true);
+}
+
+@Override
+public void failThresholdScanTrackingDisabled()
{
Assume.assumeFalse("Ignore Scans", true);
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521284#comment-17521284
]
Yifan Cai edited comment on CASSANDRA-17217 at 4/12/22 8:21 PM:
Starting commit
CI Results:
||Branch||Source||Circle CI||
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|
CI looks good. The flaky test in question did not fail. A few other failures
but not related.
was (Author: yifanc):
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521316#comment-17521316
]
Ekaterina Dimitrova commented on CASSANDRA-17532:
-
Example from 3.0:
MixedModeRangeTombstoneTest
The moment I remove the flag from the test, I get:
{code:java}
Caused by: org.apache.cassandra.exceptions.ConfigurationException: Invalid
yaml. Please remove properties [concurrent_materialized_view_writes,
hints_directory] from your cassandra.yaml
{code}
> Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade
> tests
> -
>
> Key: CASSANDRA-17532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17532
> Project: Cassandra
> Issue Type: Task
> Components: Local/Config
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> We reached lazy consensus on this here:
> [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0]
--
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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521315#comment-17521315 ] Ekaterina Dimitrova commented on CASSANDRA-17532: - We do because, otherwise we try to set properties from the InstanceConfig to older versions and get ConfigurationException. Tested. [~ifesdjeen], is this expected behavior or some bug we found? My understanding is that flag was set exactly to guard this. At the same time it is super confusing as I would expect people to try to set old config to newer version, not newer config to old version. > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17546: -- Status: Ready to Commit (was: Review In Progress) > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521307#comment-17521307 ] Stefan Miklosovic commented on CASSANDRA-17546: --- +1 > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17546: -- Reviewers: Brandon Williams, Stefan Miklosovic (was: Brandon Williams) Status: Review In Progress (was: Needs Committer) > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17532) Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade tests
[ https://issues.apache.org/jira/browse/CASSANDRA-17532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521302#comment-17521302 ] David Capwell commented on CASSANDRA-17532: --- gave feedback that we look to be applying the setting in every test rather than only the tests needed; once this is resolved with review again > Set Constants.KEY_DTEST_API_CONFIG_CHECK=true by default for in-jvm upgrade > tests > - > > Key: CASSANDRA-17532 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17532 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > > We reached lazy consensus on this here: > [https://lists.apache.org/thread/knxs0p220d6jxgggn53v4o99jnk2qbj0] -- 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-17332) Add support for vnodes in jvm-dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17332: -- Fix Version/s: NA (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/6013f16de7ce79be30fbae29d8562b78e11cd325 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Add support for vnodes in jvm-dtest > --- > > Key: CASSANDRA-17332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17332 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: NA > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Right now python dtests need to keep running after being ported to jvm-dtests > as vnode support is not present, to fully deprecate the python dtests, we > need vnode support in jvm-dtest. > Sadly, to add support we need to break binary compatibility, but can maintain > source compatibility… so will need to bump every jar across every branch > (mostly due to TokenSupplier) -- 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-17332) Add support for vnodes in jvm-dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17332: -- Status: Ready to Commit (was: Review In Progress) > Add support for vnodes in jvm-dtest > --- > > Key: CASSANDRA-17332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17332 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Right now python dtests need to keep running after being ported to jvm-dtests > as vnode support is not present, to fully deprecate the python dtests, we > need vnode support in jvm-dtest. > Sadly, to add support we need to break binary compatibility, but can maintain > source compatibility… so will need to bump every jar across every branch > (mostly due to TokenSupplier) -- 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-17332) Add support for vnodes in jvm-dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-17332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17332: -- Status: Review In Progress (was: Patch Available) > Add support for vnodes in jvm-dtest > --- > > Key: CASSANDRA-17332 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17332 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Labels: pull-request-available > Fix For: 4.x > > Time Spent: 6h 20m > Remaining Estimate: 0h > > Right now python dtests need to keep running after being ported to jvm-dtests > as vnode support is not present, to fully deprecate the python dtests, we > need vnode support in jvm-dtest. > Sadly, to add support we need to break binary compatibility, but can maintain > source compatibility… so will need to bump every jar across every branch > (mostly due to TokenSupplier) -- 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] 01/01: Merge branch 'cassandra-3.0' into cassandra-3.11
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit d7a9f41cf14e5b8177a08d36cb5477a3436f21b4 Merge: f32d2b06de 850336217b Author: David Capwell AuthorDate: Tue Apr 12 11:45:34 2022 -0700 Merge branch 'cassandra-3.0' into cassandra-3.11 build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --cc build.xml index 5948eca37f,f443e26a8c..be1168ec4d --- a/build.xml +++ b/build.xml @@@ -378,11 -352,14 +378,11 @@@ - + - - - - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] 01/01: Merge branch 'cassandra-3.11' into cassandra-4.0
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git commit 1ebdc7e758ea3ab87d31cbaee0b8c6eb5efb3b1c Merge: ce6a65cb29 d7a9f41cf1 Author: David Capwell AuthorDate: Tue Apr 12 11:46:53 2022 -0700 Merge branch 'cassandra-3.11' into cassandra-4.0 build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --cc build.xml index 563022896b,be1168ec4d..eafaeb50c5 --- a/build.xml +++ b/build.xml @@@ -539,35 -382,30 +539,35 @@@ + + + + - + - - - - - - + + + + + + - + + - + - - + + - - - - + + + + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.0 updated: Add support for vnodes in jvm-dtest
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a commit to branch cassandra-3.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git The following commit(s) were added to refs/heads/cassandra-3.0 by this push: new 850336217b Add support for vnodes in jvm-dtest 850336217b is described below commit 850336217b438ca8623e26c7efe02c993f82c46b Author: David Capwell AuthorDate: Mon Apr 11 09:38:40 2022 -0700 Add support for vnodes in jvm-dtest patch by David Capwell; reviewed by Alex Petrov, Josh McKenzie for CASSANDRA-17332 --- build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/build.xml b/build.xml index 808a4c97d8..f443e26a8c 100644 --- a/build.xml +++ b/build.xml @@ -359,7 +359,7 @@ - + - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated (20175bf77e -> 6013f16de7)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch trunk in repository https://gitbox.apache.org/repos/asf/cassandra.git from 20175bf77e Remove guardrails global enable flag new 850336217b Add support for vnodes in jvm-dtest new d7a9f41cf1 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1ebdc7e758 Merge branch 'cassandra-3.11' into cassandra-4.0 new 6013f16de7 Merge branch 'cassandra-4.0' into trunk The 4 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: .build/build-resolver.xml | 2 + .circleci/config-2_1.yml | 47 +++- .circleci/config.yml | 253 +++- .circleci/config.yml.HIGHRES | 253 +++- .circleci/config.yml.LOWRES| 253 +++- .circleci/config.yml.MIDRES| 261 +++-- CHANGES.txt| 1 + build.xml | 10 +- .../cassandra/distributed/action/GossipHelper.java | 8 +- .../distributed/impl/AbstractCluster.java | 77 +- .../distributed/impl/AbstractClusterTest.java | 251 .../cassandra/distributed/impl/InstanceConfig.java | 25 +- .../cassandra/distributed/shared/ClusterUtils.java | 17 +- .../apache/cassandra/distributed/test/CASTest.java | 5 +- .../cassandra/distributed/test/GossipTest.java | 12 +- .../cassandra/distributed/test/MoveTest.java | 2 + .../distributed/test/PaxosRepairTest.java | 51 ++-- .../distributed/test/PreviewRepairTest.java| 7 +- .../cassandra/distributed/test/ReadRepairTest.java | 3 +- .../cassandra/distributed/test/RepairTest.java | 7 +- .../test/ReplicaFilteringProtectionTest.java | 8 +- .../DebuggableThreadPoolExecutorTest.java | 24 +- .../apache/cassandra/utils/FailingRunnable.java| 15 +- 23 files changed, 1464 insertions(+), 128 deletions(-) create mode 100644 test/distributed/org/apache/cassandra/distributed/impl/AbstractClusterTest.java copy src/java/org/apache/cassandra/utils/WrappedRunnable.java => test/unit/org/apache/cassandra/utils/FailingRunnable.java (79%) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-4.0 updated (ce6a65cb29 -> 1ebdc7e758)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-4.0 in repository https://gitbox.apache.org/repos/asf/cassandra.git from ce6a65cb29 Clean up schema migration coordinator and tests new 850336217b Add support for vnodes in jvm-dtest new d7a9f41cf1 Merge branch 'cassandra-3.0' into cassandra-3.11 new 1ebdc7e758 Merge branch 'cassandra-3.11' into cassandra-4.0 The 3 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: build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch cassandra-3.11 updated (f32d2b06de -> d7a9f41cf1)
This is an automated email from the ASF dual-hosted git repository. dcapwell pushed a change to branch cassandra-3.11 in repository https://gitbox.apache.org/repos/asf/cassandra.git from f32d2b06de Upgrade slf4j to 1.7.25 new 850336217b Add support for vnodes in jvm-dtest new d7a9f41cf1 Merge branch 'cassandra-3.0' into cassandra-3.11 The 2 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: build.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521284#comment-17521284
]
Yifan Cai commented on CASSANDRA-17217:
---
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||
|trunk|[branch|https://github.com/yifan-c/cassandra/tree/commit_remote_branch/CASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|[build|https://app.circleci.com/pipelines/github/yifan-c/cassandra?branch=commit_remote_branch%2FCASSANDRA-17217-trunk-1710429A-1133-4BAE-8E13-41C9CCD27A4F]|
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
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-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
[ https://issues.apache.org/jira/browse/CASSANDRA-17547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan West updated CASSANDRA-17547: Bug Category: Parent values: Documentation(13562) Complexity: Low Hanging Fruit Component/s: Documentation/Website Discovered By: Code Inspection Severity: Normal Status: Open (was: Triage Needed) > Documentation from Partition Denylist Lost in Document Migration + Minor Fixes > -- > > Key: CASSANDRA-17547 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 > Project: Cassandra > Issue Type: Bug > Components: Documentation/Website >Reporter: Jordan West >Assignee: Jordan West >Priority: Normal > > The documentation added in > https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the > documents were migrated to the new format. We just need to bring the doc > back. Along with this fix there are a couple minor edits to make to the > document itself to correct the examples. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17547) Documentation from Partition Denylist Lost in Document Migration + Minor Fixes
Jordan West created CASSANDRA-17547: --- Summary: Documentation from Partition Denylist Lost in Document Migration + Minor Fixes Key: CASSANDRA-17547 URL: https://issues.apache.org/jira/browse/CASSANDRA-17547 Project: Cassandra Issue Type: Bug Reporter: Jordan West Assignee: Jordan West The documentation added in https://issues.apache.org/jira/browse/CASSANDRA-12106 went missing when the documents were migrated to the new format. We just need to bring the doc back. Along with this fix there are a couple minor edits to make to the document itself to correct the examples. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17217) LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
[
https://issues.apache.org/jira/browse/CASSANDRA-17217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521273#comment-17521273
]
Yifan Cai commented on CASSANDRA-17217:
---
Hi [~sathyakplm], the question is not related with the ticket. For those
questions, I'd encourage to post them on the user mailing list / slack instead.
See [https://cassandra.apache.org/_/community.html] on how to join, just in
case not known yet.
A brief answer to your question... I do not think that _at the node level_
Cassandra ensures monotonic read, i.e. R1 reads state prior to the one R2
reads. The read commands are served in parallel within a node.
> LocalReadSizeWarningTest#failThresholdSinglePartition is flaky
> --
>
> Key: CASSANDRA-17217
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17217
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Andres de la Peña
>Assignee: Bernardo Botella Corbi
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The test
> {{org.apache.cassandra.distributed.test.trackwarnings.LocalReadSizeWarningTest#failThresholdSinglePartition}}
> seems to be flaky.
> It was discovered during CASSANDRA-17195 with [this CI
> run|https://app.circleci.com/pipelines/github/adelapena/cassandra/1217/workflows/b366e352-0862-485a-acdc-5b75fe1ef575/jobs/11188].
> The failure can be reproduced running the test repeatedly for trunk, as it
> can be seen
> [here|https://app.circleci.com/pipelines/github/adelapena/cassandra/1219/workflows/a0c1fb7f-8a07-4fcf-97a4-7caf207dad78].
--
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-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña reassigned CASSANDRA-17543:
-
Assignee: Andres de la Peña
> ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE
> coordinator=1 flush=false paging=false] times out sporadically
> ---
>
> Key: CASSANDRA-17543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Assignee: Andres de la Peña
>Priority: Normal
>
> org.apache.cassandra.distributed.test.ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8:
> strategy=NONE coordinator=1 flush=false paging=false]
> {noformat}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 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)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> 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)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> See
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1075/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/testUnrestrictedQueryOnSkinnyTable_8__strategy_NONE_coordinator_1_flush_false_paging_false_/
--
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-17509) Add Guardrail to disable GROUP BY functionality
[ https://issues.apache.org/jira/browse/CASSANDRA-17509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521237#comment-17521237 ] Andres de la Peña commented on CASSANDRA-17509: --- The failures at [testMetricsCleanupOnDrop|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1977] and [testConnectionsAreRejectedWithInvalidConfig|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/211/workflows/2cbb5465-a970-440b-a502-06e380ce6851/jobs/1983] in the runs above don't seem related to the changes, so I think the results look good. Those tests failures don't appear on [Butler|https://butler.cassandra.apache.org/#/ci/upstream/compare/Cassandra-trunk/trunk] though, and I haven't found tickets for them, so we should probably create tickets for them. > Add Guardrail to disable GROUP BY functionality > --- > > Key: CASSANDRA-17509 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17509 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Time Spent: 1h 20m > Remaining Estimate: 0h > > GROUP BY can be expensive and troublesome on large tables. We should have a > guardrail to disable this in clusters where we don't want users to have this > functionality. -- 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-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521216#comment-17521216
]
Caleb Rackliffe commented on CASSANDRA-17543:
-
[~adelapena] We could quarter that baby into "point", "slice", "range", and
"collection" queries with a superclass to hold the {{Tester}} and define the
parameters. I'd probably go that direction, given raising the timeout could
blow up runtimes elsewhere?
> ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE
> coordinator=1 flush=false paging=false] times out sporadically
> ---
>
> Key: CASSANDRA-17543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
>
> org.apache.cassandra.distributed.test.ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8:
> strategy=NONE coordinator=1 flush=false paging=false]
> {noformat}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 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)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> 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)
> at org.apache.cassandra.anttasks.TestHelper.execute(TestHelper.java:53)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
> See
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1075/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/testUnrestrictedQueryOnSkinnyTable_8__strategy_NONE_coordinator_1_flush_false_paging_false_/
--
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-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17456:
--
Reviewers: Andres de la Peña, Josh McKenzie
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17546: - Status: Needs Committer (was: Patch Available) > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521169#comment-17521169 ] Brandon Williams commented on CASSANDRA-17546: -- +1 > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521162#comment-17521162 ] Brandon Williams commented on CASSANDRA-17546: -- Also if we caught these things in review we could provide that as guidance in the feedback. But tickets are free and incremental changes are easier to process. > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521158#comment-17521158 ] Brad Schoening commented on CASSANDRA-17546: [~smiklosovic] the pyflake's have been resolved. There are a *large* number of pylint issues, its far too much to resolve all at once. > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17493) Shutdown all ScheduledExecutors as part of node drainage
[ https://issues.apache.org/jira/browse/CASSANDRA-17493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521148#comment-17521148 ] Stefan Miklosovic commented on CASSANDRA-17493: --- [https://app.circleci.com/pipelines/github/instaclustr/cassandra/915/workflows/ac6f220f-a346-4728-8bcd-6ccc711f6951] https://github.com/apache/cassandra/pull/1563 > Shutdown all ScheduledExecutors as part of node drainage > > > Key: CASSANDRA-17493 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17493 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Core >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > Time Spent: 10m > Remaining Estimate: 0h > > We are currently shutting down only non-periodic executors in > StorageService#drain. We should shut down all of them. As of now, there does > not seem to be any reason why these executors should be active. -- 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-17450) Drop python 3.6 support
[
https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17450:
---
Description:
Python 3.6 became EOL as of 12/23/21. There will be no further releases or
security fixes for Python 3.6.
[https://github.com/httpie/httpie/issues/1177]
[https://devguide.python.org/#status-of-python-branches]
This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
which have deprecated and/or EOL python 3.6.
Developers on MacOS with homebrew can no longer install Python 3.6:
{quote}{{% brew install python@3.6}}
{{Warning: No available formula with the name "python@3.6". Did you mean
python@3.9, python@3.8, python@3.7, python@3.10 or python-yq?}}
{quote}
was:
Python 3.6 became EOL as of 12/23/21. There will be no further releases or
security fixes for Python 3.6.
[https://github.com/httpie/httpie/issues/1177]
[https://devguide.python.org/#status-of-python-branches]
This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
which have deprecated and/or EOL python 3.6.
> Drop python 3.6 support
> ---
>
> Key: CASSANDRA-17450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17450
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> Python 3.6 became EOL as of 12/23/21. There will be no further releases or
> security fixes for Python 3.6.
> [https://github.com/httpie/httpie/issues/1177]
> [https://devguide.python.org/#status-of-python-branches]
>
> This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
> which have deprecated and/or EOL python 3.6.
> Developers on MacOS with homebrew can no longer install Python 3.6:
> {quote}{{% brew install python@3.6}}
> {{Warning: No available formula with the name "python@3.6". Did you mean
> python@3.9, python@3.8, python@3.7, python@3.10 or python-yq?}}
> {quote}
--
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-17450) Drop python 3.6 support
[
https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brad Schoening updated CASSANDRA-17450:
---
Description:
Python 3.6 became EOL as of 12/23/21. There will be no further releases or
security fixes for Python 3.6.
[https://github.com/httpie/httpie/issues/1177]
[https://devguide.python.org/#status-of-python-branches]
This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
which have deprecated and/or EOL python 3.6.
Developers on MacOS with homebrew can no longer install and use Python 3.6:
{quote}{{% brew install python@3.6}}
{{Warning: No available formula with the name "python@3.6". Did you mean
python@3.9, python@3.8, python@3.7, python@3.10 or python-yq?}}
{quote}
was:
Python 3.6 became EOL as of 12/23/21. There will be no further releases or
security fixes for Python 3.6.
[https://github.com/httpie/httpie/issues/1177]
[https://devguide.python.org/#status-of-python-branches]
This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
which have deprecated and/or EOL python 3.6.
Developers on MacOS with homebrew can no longer install Python 3.6:
{quote}{{% brew install python@3.6}}
{{Warning: No available formula with the name "python@3.6". Did you mean
python@3.9, python@3.8, python@3.7, python@3.10 or python-yq?}}
{quote}
> Drop python 3.6 support
> ---
>
> Key: CASSANDRA-17450
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17450
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> Python 3.6 became EOL as of 12/23/21. There will be no further releases or
> security fixes for Python 3.6.
> [https://github.com/httpie/httpie/issues/1177]
> [https://devguide.python.org/#status-of-python-branches]
>
> This would be aligned with Apache Airflow, Beam, PyArrow and Spark projects
> which have deprecated and/or EOL python 3.6.
> Developers on MacOS with homebrew can no longer install and use Python 3.6:
> {quote}{{% brew install python@3.6}}
> {{Warning: No available formula with the name "python@3.6". Did you mean
> python@3.9, python@3.8, python@3.7, python@3.10 or python-yq?}}
> {quote}
--
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-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1752#comment-1752
]
Andres de la Peña edited comment on CASSANDRA-17543 at 4/12/22 12:22 PM:
-
The {{ReadRepairQueryTypesTest}} test suite seems very stable on CircleCI, as
it's shown by the success of these 1000-iteration runs:
||branch||CI||
|4.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/c183b8ac-4a34-4774-865e-4fe85f3aa191]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/d5fd42da-098f-4752-8810-d1063a504850]|
|trunk|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/843f5ceb-f0f8-4b81-8a5d-61e333118ca6]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/21f52bdc-9a1e-4eab-8ae2-e99721d24e57]|
However, it seems that a particularly slow run on Jenkins can hit the config
limit defined by
[{{test.distributed.timeout}}|https://github.com/apache/cassandra/blob/2fde9af74f12179fd8b3d592adc9a24d8b2d8f23/build.xml#L116].
The reported run times for the the last Jenkins runs show great variability,
with some runs being close to the limit:
||mm:ss||
|[09:26|https://ci-cassandra.apache.org/job/Cassandra-trunk/1074/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[11:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1073/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[09:09|https://ci-cassandra.apache.org/job/Cassandra-trunk/1072/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[15:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1070/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1069/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1068/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[06:17|https://ci-cassandra.apache.org/job/Cassandra-trunk/1067/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[03:53|https://ci-cassandra.apache.org/job/Cassandra-trunk/1066/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[15:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1065/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[04:33|https://ci-cassandra.apache.org/job/Cassandra-trunk/1064/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
I think there is nothing wrong with having a test that takes long because it
evaluates many parameters, so we could just further increase the value of
[{{test.distributed.timeout}}|https://github.com/apache/cassandra/blob/2fde9af74f12179fd8b3d592adc9a24d8b2d8f23/build.xml#L116].
Alternatively, we could solomonically split the test into two or more tests.
[~maedhroz] wdyt?
was (Author: adelapena):
The {{ReadRepairQueryTypesTest}} test suite seems very stable on CircleCI, as
it's shown by the success of these 1000-iteration runs:
||branch||CI||
|4.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/c183b8ac-4a34-4774-865e-4fe85f3aa191]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/d5fd42da-098f-4752-8810-d1063a504850]|
|trunk|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/843f5ceb-f0f8-4b81-8a5d-61e333118ca6]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/21f52bdc-9a1e-4eab-8ae2-e99721d24e57]|
However, it seems that a particularly slow run on Jenkins can hit the config
limit defined by
[{{test.distributed.timeout}}|https://github.com/apache/cassandra/blob/2fde9af74f12179fd8b3d592adc9a24d8b2d8f23/build.xml#L116].
The run times for the the last Jenkins run show great variability, with some
runs being close to the limit:
||mm:ss||
|[09:26|https://ci-cassandra.apache.org/job/Cassandra-trunk/1074/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[11:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1073/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[09:09|https://ci-cassandra.apache.org/job/Cassandra-trunk/1072/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[15:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1070/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1069/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1068/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
[jira] [Commented] (CASSANDRA-17543) ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE coordinator=1 flush=false paging=false] times out sporadically
[
https://issues.apache.org/jira/browse/CASSANDRA-17543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1752#comment-1752
]
Andres de la Peña commented on CASSANDRA-17543:
---
The {{ReadRepairQueryTypesTest}} test suite seems very stable on CircleCI, as
it's shown by the success of these 1000-iteration runs:
||branch||CI||
|4.0|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/c183b8ac-4a34-4774-865e-4fe85f3aa191]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1471/workflows/d5fd42da-098f-4752-8810-d1063a504850]|
|trunk|[j8|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/843f5ceb-f0f8-4b81-8a5d-61e333118ca6]
[j11|https://app.circleci.com/pipelines/github/adelapena/cassandra/1470/workflows/21f52bdc-9a1e-4eab-8ae2-e99721d24e57]|
However, it seems that a particularly slow run on Jenkins can hit the config
limit defined by
[{{test.distributed.timeout}}|https://github.com/apache/cassandra/blob/2fde9af74f12179fd8b3d592adc9a24d8b2d8f23/build.xml#L116].
The run times for the the last Jenkins run show great variability, with some
runs being close to the limit:
||mm:ss||
|[09:26|https://ci-cassandra.apache.org/job/Cassandra-trunk/1074/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[11:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1073/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[09:09|https://ci-cassandra.apache.org/job/Cassandra-trunk/1072/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[15:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1070/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1069/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[10:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1068/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[06:17|https://ci-cassandra.apache.org/job/Cassandra-trunk/1067/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[03:53|https://ci-cassandra.apache.org/job/Cassandra-trunk/1066/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[15:00|https://ci-cassandra.apache.org/job/Cassandra-trunk/1065/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
|[04:33|https://ci-cassandra.apache.org/job/Cassandra-trunk/1064/testReport/org.apache.cassandra.distributed.test/ReadRepairQueryTypesTest/]|
I think there is nothing wrong with having a test that takes long because it
evaluates many parameters, so we could just further increase the value of
[{{test.distributed.timeout}}|https://github.com/apache/cassandra/blob/2fde9af74f12179fd8b3d592adc9a24d8b2d8f23/build.xml#L116].
Alternatively, we could solomonically split the test into two or more tests.
[~maedhroz] wdyt?
> ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8: strategy=NONE
> coordinator=1 flush=false paging=false] times out sporadically
> ---
>
> Key: CASSANDRA-17543
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17543
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Caleb Rackliffe
>Priority: Normal
>
> org.apache.cassandra.distributed.test.ReadRepairQueryTypesTest.testUnrestrictedQueryOnSkinnyTable[8:
> strategy=NONE coordinator=1 flush=false paging=false]
> {noformat}
> Error Message
> Timeout occurred. Please note the time in the report does not reflect the
> time until the timeout.
> Stacktrace
> junit.framework.AssertionFailedError: Timeout occurred. Please note the time
> in the report does not reflect the time until the timeout.
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.util.Vector.forEach(Vector.java:1388)
> at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] [Assigned] (CASSANDRA-17270) cassandra-harry: the cassandra-harry script uses the wrong way to check if the variable is set or not
[ https://issues.apache.org/jira/browse/CASSANDRA-17270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov reassigned CASSANDRA-17270: --- Assignee: Efraimov Oren (was: Alex Petrov) > cassandra-harry: the cassandra-harry script uses the wrong way to check if > the variable is set or not > - > > Key: CASSANDRA-17270 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17270 > Project: Cassandra > Issue Type: Bug > Components: Test/fuzz >Reporter: Efraimov Oren >Assignee: Efraimov Oren >Priority: Normal > Fix For: NA > > > For more information please check the following link: > [https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash] > > https://github.com/apache/cassandra-harry/pull/13 -- 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-17270) cassandra-harry: the cassandra-harry script uses the wrong way to check if the variable is set or not
[ https://issues.apache.org/jira/browse/CASSANDRA-17270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17270: Resolution: Fixed Status: Resolved (was: Open) > cassandra-harry: the cassandra-harry script uses the wrong way to check if > the variable is set or not > - > > Key: CASSANDRA-17270 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17270 > Project: Cassandra > Issue Type: Bug > Components: Test/fuzz >Reporter: Efraimov Oren >Assignee: Alex Petrov >Priority: Normal > Fix For: NA > > > For more information please check the following link: > [https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash] > > https://github.com/apache/cassandra-harry/pull/13 -- 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-17270) cassandra-harry: the cassandra-harry script uses the wrong way to check if the variable is set or not
[ https://issues.apache.org/jira/browse/CASSANDRA-17270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-17270: Mentor: (was: Alex Petrov) > cassandra-harry: the cassandra-harry script uses the wrong way to check if > the variable is set or not > - > > Key: CASSANDRA-17270 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17270 > Project: Cassandra > Issue Type: Bug > Components: Test/fuzz >Reporter: Efraimov Oren >Assignee: Alex Petrov >Priority: Normal > Fix For: NA > > > For more information please check the following link: > [https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash] > > https://github.com/apache/cassandra-harry/pull/13 -- 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-17270) cassandra-harry: the cassandra-harry script uses the wrong way to check if the variable is set or not
[ https://issues.apache.org/jira/browse/CASSANDRA-17270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521110#comment-17521110 ] Alex Petrov commented on CASSANDRA-17270: - Committed with [c0f9da20bf40cff3341eb4db21aa16a234a3e923|https://github.com/apache/cassandra-harry/commit/c0f9da20bf40cff3341eb4db21aa16a234a3e923] > cassandra-harry: the cassandra-harry script uses the wrong way to check if > the variable is set or not > - > > Key: CASSANDRA-17270 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17270 > Project: Cassandra > Issue Type: Bug > Components: Test/fuzz >Reporter: Efraimov Oren >Assignee: Alex Petrov >Priority: Normal > Fix For: NA > > > For more information please check the following link: > [https://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash] > > https://github.com/apache/cassandra-harry/pull/13 -- 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-harry] branch trunk updated: fix(scripts/cassandra-harry): Fixing bash if condition
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-harry.git
The following commit(s) were added to refs/heads/trunk by this push:
new c0f9da2 fix(scripts/cassandra-harry): Fixing bash if condition
c0f9da2 is described below
commit c0f9da20bf40cff3341eb4db21aa16a234a3e923
Author: Efraimov Oren
AuthorDate: Wed Jan 19 16:31:04 2022 +0200
fix(scripts/cassandra-harry): Fixing bash if condition
Some IFs were contained incorrect conditions because of test leftover.
---
scripts/cassandra-harry | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/scripts/cassandra-harry b/scripts/cassandra-harry
index 7cd4592..bacffc6 100755
--- a/scripts/cassandra-harry
+++ b/scripts/cassandra-harry
@@ -1,6 +1,6 @@
#!/bin/sh
-if [ -z ${HARRY_HOME1+x} ]; then
+if [ -z ${HARRY_HOME+x} ]; then
HARRY_HOME=~/cassandra-harry
fi
@@ -47,7 +47,7 @@ fi
if [ ! -z ${run_time+x} ]; then
sed -i -e "s/run_time:.*/run_time: $run_time/g"
$HARRY_HOME/conf/external.yaml
fi
-if [ ! -z ${run_time_unit+} ]; then
+if [ ! -z ${run_time_unit+x} ]; then
sed -i -e "s/run_time_unit:.*/run_time_unit: \"$run_time_unit\"/g"
$HARRY_HOME/conf/external.yaml
fi
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521106#comment-17521106 ] Stefan Miklosovic commented on CASSANDRA-17546: --- I was telling Brad in the comments for some other PR that I would personally welcome if we do this in one bigger patch to resolve "everything Python" when it comes to pylint etc. I just find myself repeatedly returning to the same stuff all over again. We just do not need to rush that, when it is all ready, it is all ready. > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521105#comment-17521105 ] Brandon Williams commented on CASSANDRA-17546: -- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17546], circle on [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/432/workflows/c375df91-d399-41ad-b716-c6e52d8cbdea], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/432/workflows/cbf97d2c-326d-4aee-9734-c5df08ab6969]. > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17546: - Test and Documentation Plan: run CI Status: Patch Available (was: Open) > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17546: - Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: CQL/Interpreter Fix Version/s: 4.x Reviewers: Brandon Williams Assignee: Brad Schoening Status: Open (was: Triage Needed) > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-17546) Resolve additional pylint issues in pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521103#comment-17521103 ] Brandon Williams commented on CASSANDRA-17546: -- Apparently not all. > Resolve additional pylint issues in pylib > - > > Key: CASSANDRA-17546 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17546 > Project: Cassandra > Issue Type: Task >Reporter: Brad Schoening >Priority: Normal > > Resolve minor pylint and PEP8 issues: > * Lines too long > * Unused args in functions > * Exceptions defined too broadly > * Redundant parenthesis > * Unnecessary escapes in regex > * Update select.error merged into OSError (python 3.3+, PEP 3151) > * Variable names reused in inner scope > * Obsolete EINTR handling (python 3.5+, PEP 475) -- 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-10709) Synchronize TOC and digest
[ https://issues.apache.org/jira/browse/CASSANDRA-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Sokol updated CASSANDRA-10709: - Test and Documentation Plan: n/a Status: Patch Available (was: Open) > Synchronize TOC and digest > -- > > Key: CASSANDRA-10709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10709 > Project: Cassandra > Issue Type: Bug >Reporter: Stefania Alborghetti >Assignee: Maciej Sokol >Priority: Low > Fix For: 2.2.x, 3.11.x > > > The TOC and DIGEST components are not synchronized at the moment (the file is > not fsynch-ed to disk after it is written). This could cause inconsistencies > in case of power failures. At the moment these component sstable files are > only used by standalone tools but we should fix them nonetheless. > Refer to the discussion on CASSANDRA-10534 for more details. -- 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-10709) Synchronize TOC and digest
[ https://issues.apache.org/jira/browse/CASSANDRA-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521102#comment-17521102 ] Maciej Sokol commented on CASSANDRA-10709: -- Patch based on 3.11 [here,|https://github.com/apache/cassandra/pull/1566] [CI|https://app.circleci.com/pipelines/github/masokol/cassandra/3/workflows/cb9329bd-8806-4951-8ba4-8eb6e5bd7959] > Synchronize TOC and digest > -- > > Key: CASSANDRA-10709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10709 > Project: Cassandra > Issue Type: Bug >Reporter: Stefania Alborghetti >Assignee: Maciej Sokol >Priority: Low > Fix For: 2.2.x, 3.11.x > > > The TOC and DIGEST components are not synchronized at the moment (the file is > not fsynch-ed to disk after it is written). This could cause inconsistencies > in case of power failures. At the moment these component sstable files are > only used by standalone tools but we should fix them nonetheless. > Refer to the discussion on CASSANDRA-10534 for more details. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521097#comment-17521097 ] Bowen Song commented on CASSANDRA-16456: I see. Now is a good time to make changes then, before it's released. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521078#comment-17521078 ] Stefan Miklosovic edited comment on CASSANDRA-16456 at 4/12/22 11:08 AM: - I dont think we have to be backward compatible as credentials stuff you did is not released yet. What I checked is that it is going to be released for the first time in 4.1 so we have still some room to mess with that. For this very specific case I would go with camel case as it would be super easy to map it to classname in auth_provider section. was (Author: smiklosovic): I dont think we have to be backward compatible as credentials stuff you did is not released yet. What I checked is that it is going to be released for the first time in 4.1 so we have still some room to mess with that. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521078#comment-17521078 ] Stefan Miklosovic commented on CASSANDRA-16456: --- I dont think we have to be backward compatible as credentials stuff you did is not released yet. What I checked is that it is going to be released for the first time in 4.1 so we have still some room to mess with that. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521075#comment-17521075 ] Bowen Song commented on CASSANDRA-16456: [~smiklosovic] I just want to point out that AFAIK INI file section names are not always case sensitive. It's an implementation defined behaviour. "[PlainTextAuthProvider]" could be treated the same as "[plaintextauthprovider]". Also, if we decide to rename the "plain_text_auth" to "plaintextauthprovider" or "PlainTextAuthProvider", we may need to provide backward compatibility. > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Assignee: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > Time Spent: 2h 10m > Remaining Estimate: 0h > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17499) Remove global Guardrails Enable flag
[
https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521074#comment-17521074
]
Andres de la Peña commented on CASSANDRA-17499:
---
Committed to {{trunk}} as
[20175bf77e2c6f72c25240ee445b583805a37630|https://github.com/apache/cassandra/commit/20175bf77e2c6f72c25240ee445b583805a37630].
> Remove global Guardrails Enable flag
>
>
> Key: CASSANDRA-17499
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17499
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Guardrails
>Reporter: Savni Nagarkar
>Assignee: Savni Nagarkar
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> This ticket removes the global Guardrails enable flag. Currently the flag
> turns all Guardrails on and off regardless of the individual setting of the
> guardrail property. This presents a problem for maximum replication factor
> and minimum replication factor configurations which will soon be moved to
> guardrails. Those configurations will always need to be enabled so no
> problems arise as Cassandra users create keyspaces. This ensures all
> Guardrail properties follow the same enable / disable procedure.
--
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-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17499: -- Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/20175bf77e2c6f72c25240ee445b583805a37630 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.1 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- 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] branch trunk updated: Remove guardrails global enable flag
This is an automated email from the ASF dual-hosted git repository.
adelapena pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 20175bf77e Remove guardrails global enable flag
20175bf77e is described below
commit 20175bf77e2c6f72c25240ee445b583805a37630
Author: Savni Nagarkar
AuthorDate: Tue Mar 29 14:40:55 2022 -0500
Remove guardrails global enable flag
patch by Savni Nagarkar; reviewed by Andrés de la Peña and Joshua McKenzie
for CASSANDRA-17499
---
CHANGES.txt| 1 +
conf/cassandra.yaml| 2 -
src/java/org/apache/cassandra/config/Config.java | 1 -
.../apache/cassandra/config/GuardrailsOptions.java | 22 ---
.../statements/schema/CreateTableStatement.java| 45 ++
.../apache/cassandra/db/guardrails/Guardrail.java | 8 ++--
.../apache/cassandra/db/guardrails/Guardrails.java | 24
.../cassandra/db/guardrails/GuardrailsConfig.java | 10 -
.../cassandra/db/guardrails/GuardrailsMBean.java | 14 ---
.../GuardrailCollectionSizeOnSSTableWriteTest.java | 1 -
...rdrailItemsPerCollectionOnSSTableWriteTest.java | 3 +-
.../cassandra/db/guardrails/GuardrailTester.java | 1 -
12 files changed, 26 insertions(+), 106 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index d450f81726..114859c755 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * Remove guardrails global enable flag (CASSANDRA-17499)
* Clients using JMX are unable to handle non-standard java types but we leak
this into our interfaces (CASSANDRA-17527)
* Remove stress server functionality (CASSANDRA-17535)
* Reduce histogram snapshot long[] allocation overhead during speculative
read and write threshold updates (CASSANDRA-17523)
diff --git a/conf/cassandra.yaml b/conf/cassandra.yaml
index 1a876ca934..668ab83db4 100644
--- a/conf/cassandra.yaml
+++ b/conf/cassandra.yaml
@@ -1599,8 +1599,6 @@ drop_compact_storage_enabled: false
# warn_threshold_kb: 0
# abort_threshold_kb: 0
-# Whether guardrails are enabled or not. Guardrails are disabled by default.
-# guardrails_enabled: false
# Guardrail to warn or fail when creating more user keyspaces than threshold.
# The two thresholds default to -1 to disable.
# keyspaces_warn_threshold: -1
diff --git a/src/java/org/apache/cassandra/config/Config.java
b/src/java/org/apache/cassandra/config/Config.java
index e0dc5767c6..9717dbc135 100644
--- a/src/java/org/apache/cassandra/config/Config.java
+++ b/src/java/org/apache/cassandra/config/Config.java
@@ -775,7 +775,6 @@ public class Config
public static final int DISABLED_GUARDRAIL = -1;
public static final DataStorageSpec DISABLED_SIZE_GUARDRAIL =
DataStorageSpec.inBytes(0);
-public volatile boolean guardrails_enabled = false;
public volatile int keyspaces_warn_threshold = DISABLED_GUARDRAIL;
public volatile int keyspaces_fail_threshold = DISABLED_GUARDRAIL;
public volatile int tables_warn_threshold = DISABLED_GUARDRAIL;
diff --git a/src/java/org/apache/cassandra/config/GuardrailsOptions.java
b/src/java/org/apache/cassandra/config/GuardrailsOptions.java
index d08f8c555a..5047cbaa2b 100644
--- a/src/java/org/apache/cassandra/config/GuardrailsOptions.java
+++ b/src/java/org/apache/cassandra/config/GuardrailsOptions.java
@@ -42,9 +42,6 @@ import static java.util.stream.Collectors.toSet;
* code checking each guarded constraint. That code should use the higher
level abstractions defined in
* {@link Guardrails}).
*
- * This contains a main setting, {@code enabled}, controlling if guardrails
are globally active or not, and
- * individual settings to control each guardrail.
- *
* We have 2 variants of guardrails, soft (warn) and hard (fail) limits,
each guardrail having either one of the
* variants or both. Note in particular that hard limits only make sense for
guardrails triggering during query
* execution. For other guardrails, say one triggering during compaction,
aborting that compaction does not make sense.
@@ -82,25 +79,6 @@ public class GuardrailsOptions implements GuardrailsConfig
validateIntThreshold(config.fields_per_udt_warn_threshold,
config.fields_per_udt_fail_threshold, "fields_per_udt");
}
-@Override
-public boolean getEnabled()
-{
-return config.guardrails_enabled;
-}
-
-/**
- * Enable/disable guardrails.
- *
- * @param enabled {@code true} for enabling guardrails, {@code false} for
disabling them.
- */
-public void setEnabled(boolean enabled)
-{
-updatePropertyWithLogging("guardrails_enabled",
- enabled,
- () -> config.guardrails_enabled,
- x -> config.guardrails_enabled = x);
-}
-
@Override
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521067#comment-17521067
]
Stefan Miklosovic commented on CASSANDRA-16456:
---
Just to add what [~Bowen Song] said, when you get to the implementation, I
would pass all content of credentials file (for that auth provider) into the
constructors arguments, together with all other settings for auth provider in
cqlshrc, credentials replacing possible duplicities in cqlshrc.
I am not sure if it is necessary to store credentials per auth provider in
credentials file (like there would be multiple sections and you would choose
which one to include based on what auth provider is active in cqlshrc), if you
manage to do that that would be nice but it is not required.
If I have this
{code}
cat ~/.cassandra/credentials
[plain_text_auth]
username = cassandra
password = cassandra
{code}
and this
{code}
cat ~/.cassandra/cqlshrc
[authentication]
credentials = /home/smiklosovic/.cassandra/credentials
[auth_provider]
module = cassandra.auth
classname = PlainTextAuthProvider
{code}
I am not sure how we want to map the content of credentials to that auth
provider because we need to somehow map "plain_text_auth" to
"PlainTextAuthProvider". I would hence start to do it like this:
{code}
cat ~/.cassandra/credentials
[PlainTextAuthProvider]
username = cassandra
password = cassandra
{code}
> Add Plugin Support for CQLSH
>
>
> Key: CASSANDRA-16456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16456
> Project: Cassandra
> Issue Type: New Feature
> Components: Tool/cqlsh
>Reporter: Brian Houser
>Assignee: Brian Houser
>Priority: Normal
> Labels: gsoc2021, mentor
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently the Cassandra drivers offer a plugin authenticator architecture for
> the support of different authentication methods. This has been leveraged to
> provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately,
> cqlsh, the included CLI tool, does not offer such support. Switching to a new
> enhanced authentication scheme thus means being cut off from using cqlsh in
> normal operation.
> We should have a means of using the same plugins and authentication providers
> as the Python Cassandra driver.
> Here's a link to an initial draft of
> [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing].
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-10537) CONTAINS and CONTAINS KEY support for Lightweight Transactions
[
https://issues.apache.org/jira/browse/CASSANDRA-10537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17520467#comment-17520467
]
Berenguer Blasi edited comment on CASSANDRA-10537 at 4/12/22 10:23 AM:
---
Let's see what
[CI|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1592/] has to say
:-)
CI was broken yesterday. Take 2
[here|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1608/]
was (Author: bereng):
Let's see what
[CI|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1592/] has to say
:-)
> CONTAINS and CONTAINS KEY support for Lightweight Transactions
> --
>
> Key: CASSANDRA-10537
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10537
> Project: Cassandra
> Issue Type: Improvement
> Components: Legacy/CQL
>Reporter: Nimi Wariboko Jr.
>Assignee: ROCHETEAU Antoine
>Priority: Normal
> Labels: AdventCalendar2021, CQL, lhf
> Fix For: 4.x
>
> Time Spent: 3h 10m
> Remaining Estimate: 0h
>
> Conditional updates currently do not support CONTAINS and CONTAINS KEY
> conditions. Queries such as
> {{UPDATE mytable SET somefield = 4 WHERE pk = 'pkv' IF set_column CONTAINS
> 5;}}
> are not possible.
> Would it also be possible to support the negation of these (ex. testing that
> a value does not exist inside a set)?
> +Additional Information for newcomers:+
> Negation should not be supported as for the moment we do not support it
> within restrictions either.
> One way to approch this bug is to use test driven development. You can modify
> {{InsertUpdateIfConditionCollectionsTest}} to allow CONTAINS and CONTAINS KEY
> operators and go through the different failures.
> The following changes will need to be done.
> * The {{columnCondition}} rule from the ANTLR {{Parser.g}} file should be
> updated to accept {{containsOperator}}.
> * {{ColumnCondition.Raw#prepareTerms}} should be modified in the case where
> the operator is a CONTAINS or CONTAINS KEY as the {{receiver}} is not the
> collection but keys or values of the collection. Look at
> {{SingleColumnRelation#makeCollectionReceiver}}.
> * {{ColumnCollection.MultiCellCollectionBound#valueAppliesTo}} will need to
> be changed for {{Map}} and {{Set}} to process CONTAINS operators.
>
--
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-17539) 'if not exists' clause should be produced on normal DESCRIBE cqlsh command
[ https://issues.apache.org/jira/browse/CASSANDRA-17539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17539: -- Resolution: Won't Do Status: Resolved (was: Open) > 'if not exists' clause should be produced on normal DESCRIBE cqlsh command > -- > > Key: CASSANDRA-17539 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17539 > Project: Cassandra > Issue Type: Bug > Components: CQL/Interpreter >Reporter: Stefan Miklosovic >Assignee: Stefan Miklosovic >Priority: Normal > Fix For: 4.x > > > IF NOT EXISTS is saved when one takes, for example, a snapshot and it is > added in schema.cql. However, I noticed that if one creates a table (or any > other CQL entity for that matter), on DESCRIBE, it will not create the output > with IF NOT EXISTS. I believe this is a discrepancy and it should be > targetted. -- 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-10709) Synchronize TOC and digest
[ https://issues.apache.org/jira/browse/CASSANDRA-10709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maciej Sokol reassigned CASSANDRA-10709: Assignee: Maciej Sokol > Synchronize TOC and digest > -- > > Key: CASSANDRA-10709 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10709 > Project: Cassandra > Issue Type: Bug >Reporter: Stefania Alborghetti >Assignee: Maciej Sokol >Priority: Low > Fix For: 2.2.x, 3.11.x > > > The TOC and DIGEST components are not synchronized at the moment (the file is > not fsynch-ed to disk after it is written). This could cause inconsistencies > in case of power failures. At the moment these component sstable files are > only used by standalone tools but we should fix them nonetheless. > Refer to the discussion on CASSANDRA-10534 for more details. -- 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-17499) Remove global Guardrails Enable flag
[ https://issues.apache.org/jira/browse/CASSANDRA-17499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andres de la Peña updated CASSANDRA-17499: -- Status: Ready to Commit (was: Review In Progress) > Remove global Guardrails Enable flag > > > Key: CASSANDRA-17499 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17499 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Guardrails >Reporter: Savni Nagarkar >Assignee: Savni Nagarkar >Priority: Normal > Fix For: 4.x > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket removes the global Guardrails enable flag. Currently the flag > turns all Guardrails on and off regardless of the individual setting of the > guardrail property. This presents a problem for maximum replication factor > and minimum replication factor configurations which will soon be moved to > guardrails. Those configurations will always need to be enabled so no > problems arise as Cassandra users create keyspaces. This ensures all > Guardrail properties follow the same enable / disable procedure. -- 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-17456) Test Failures: write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
[
https://issues.apache.org/jira/browse/CASSANDRA-17456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov reassigned CASSANDRA-17456:
Assignee: Aleksandr Sorokoumov (was: Josh McKenzie)
> Test Failures:
> write_failures_test.TestMultiDCWriteFailures.test_oversized_mutation
> ---
>
> Key: CASSANDRA-17456
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17456
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Ekaterina Dimitrova
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1002/testReport/dtest-offheap.write_failures_test/TestMultiDCWriteFailures/test_oversized_mutation/
> {code:java}
> Error Message
> AssertionError: assert 0 == 8 + where 8 = JolokiaAgent.read_attribute of 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count') +where > =
> .read_attribute +
> and 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> Stacktrace
> self =
> def test_oversized_mutation(self):
> """
> Test that multi-DC write failures return operation failed rather
> than a timeout.
> @jira_ticket CASSANDRA-16334.
> """
>
> cluster = self.cluster
> cluster.populate([2, 2])
> cluster.set_configuration_options(values={'max_mutation_size_in_kb':
> 128})
> cluster.start()
>
> node1 = cluster.nodelist()[0]
> session = self.patient_exclusive_cql_connection(node1)
>
> session.execute("CREATE KEYSPACE k WITH replication = {'class':
> 'NetworkTopologyStrategy', 'dc1': 2, 'dc2': 2}")
> session.execute("CREATE TABLE k.t (key int PRIMARY KEY, val blob)")
>
> payload = '1' * 1024 * 256
> query = "INSERT INTO k.t (key, val) VALUES (1,
> textAsBlob('{}'))".format(payload)
>
> assert_write_failure(session, query, ConsistencyLevel.LOCAL_ONE)
> assert_write_failure(session, query, ConsistencyLevel.ONE)
>
> # verify that no hints are created
> with JolokiaAgent(node1) as jmx:
> > assert 0 == jmx.read_attribute(make_mbean('metrics',
> > type='Storage', name='TotalHints'), 'Count')
> E AssertionError: assert 0 == 8
> E+ where 8 = 0x7f1fca78dac0>>('org.apache.cassandra.metrics:type=Storage,name=TotalHints',
> 'Count')
> E+where > =
> .read_attribute
> E+and
> 'org.apache.cassandra.metrics:type=Storage,name=TotalHints' =
> make_mbean('metrics', type='Storage', name='TotalHints')
> write_failures_test.py:277: AssertionError
> REST API
> CloudBees CI Client Controller 2.319.3.4-rolling
> {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
