[jira] [Updated] (CASSANDRASC-105) RestoreSliceTask could be stuck due to missing exception handling
[ https://issues.apache.org/jira/browse/CASSANDRASC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-105: -- Fix Version/s: 1.0 Source Control Link: https://github.com/apache/cassandra-sidecar/commit/9b56cdd11a25550f0628e99ba35650c44663eb19 Resolution: Fixed Status: Resolved (was: Ready to Commit) > RestoreSliceTask could be stuck due to missing exception handling > - > > Key: CASSANDRASC-105 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-105 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > Fix For: 1.0 > > > In RestoreSliceTask, there are a few places could throw exceptions but > missing exception handling in call-sites. As a result, the RetoreSliceTask > never fulfill the promise, i.e. the task is stuck. > For example, downloadObjectIfAbsent could throw instead of returning a > future, in such case, the task will never fail or complete. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-105) RestoreSliceTask could be stuck due to missing exception handling
[ https://issues.apache.org/jira/browse/CASSANDRASC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-105: -- Reviewers: Francisco Guerrero, Yifan Cai, Yifan Cai (was: Francisco Guerrero, Yifan Cai) Status: Review In Progress (was: Patch Available) > RestoreSliceTask could be stuck due to missing exception handling > - > > Key: CASSANDRASC-105 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-105 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > > In RestoreSliceTask, there are a few places could throw exceptions but > missing exception handling in call-sites. As a result, the RetoreSliceTask > never fulfill the promise, i.e. the task is stuck. > For example, downloadObjectIfAbsent could throw instead of returning a > future, in such case, the task will never fail or complete. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-105) RestoreSliceTask could be stuck due to missing exception handling
[ https://issues.apache.org/jira/browse/CASSANDRASC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yifan Cai updated CASSANDRASC-105: -- Status: Ready to Commit (was: Review In Progress) > RestoreSliceTask could be stuck due to missing exception handling > - > > Key: CASSANDRASC-105 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-105 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > > In RestoreSliceTask, there are a few places could throw exceptions but > missing exception handling in call-sites. As a result, the RetoreSliceTask > never fulfill the promise, i.e. the task is stuck. > For example, downloadObjectIfAbsent could throw instead of returning a > future, in such case, the task will never fail or complete. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRASC-105) RestoreSliceTask could be stuck due to missing exception handling
[ https://issues.apache.org/jira/browse/CASSANDRASC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828132#comment-17828132 ] ASF subversion and git services commented on CASSANDRASC-105: - Commit 9b56cdd11a25550f0628e99ba35650c44663eb19 in cassandra-sidecar's branch refs/heads/trunk from Saranya Krishnakumar [ https://gitbox.apache.org/repos/asf?p=cassandra-sidecar.git;h=9b56cdd ] CASSANDRASC-105 RestoreSliceTask could be stuck due to missing exception handling (#107) patch by Saranya Krishnakumar; reviewed by Francisco Guerrero, Yifan Cai for CASSANDRASC-105 > RestoreSliceTask could be stuck due to missing exception handling > - > > Key: CASSANDRASC-105 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-105 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > > In RestoreSliceTask, there are a few places could throw exceptions but > missing exception handling in call-sites. As a result, the RetoreSliceTask > never fulfill the promise, i.e. the task is stuck. > For example, downloadObjectIfAbsent could throw instead of returning a > future, in such case, the task will never fail or complete. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRASC-105) RestoreSliceTask could be stuck due to missing exception handling
[ https://issues.apache.org/jira/browse/CASSANDRASC-105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRASC-105: --- Labels: pull-request-available (was: ) > RestoreSliceTask could be stuck due to missing exception handling > - > > Key: CASSANDRASC-105 > URL: https://issues.apache.org/jira/browse/CASSANDRASC-105 > Project: Sidecar for Apache Cassandra > Issue Type: Bug > Components: Rest API >Reporter: Yifan Cai >Assignee: Saranya Krishnakumar >Priority: Normal > Labels: pull-request-available > > In RestoreSliceTask, there are a few places could throw exceptions but > missing exception handling in call-sites. As a result, the RetoreSliceTask > never fulfill the promise, i.e. the task is stuck. > For example, downloadObjectIfAbsent could throw instead of returning a > future, in such case, the task will never fail or complete. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-sidecar) branch trunk updated: CASSANDRASC-105 RestoreSliceTask could be stuck due to missing exception handling (#107)
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-sidecar.git
The following commit(s) were added to refs/heads/trunk by this push:
new 9b56cdd CASSANDRASC-105 RestoreSliceTask could be stuck due to
missing exception handling (#107)
9b56cdd is described below
commit 9b56cdd11a25550f0628e99ba35650c44663eb19
Author: Saranya Krishnakumar
AuthorDate: Mon Mar 18 16:49:57 2024 -0700
CASSANDRASC-105 RestoreSliceTask could be stuck due to missing exception
handling (#107)
patch by Saranya Krishnakumar; reviewed by Francisco Guerrero, Yifan Cai
for CASSANDRASC-105
---
CHANGES.txt| 1 +
.../sidecar/restore/RestoreSliceTask.java | 58 ++-
.../sidecar/utils/AsyncFileDigestVerifier.java | 4 +-
.../sidecar/restore/RestoreSliceTaskTest.java | 112 -
4 files changed, 145 insertions(+), 30 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 0fdc914..e625cde 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,5 +1,6 @@
1.0.0
-
+ * RestoreSliceTask could be stuck due to missing exception handling
(CASSANDRASC-105)
* Make hash algorithm implementation pluggable (CASSANDRASC-114)
* Fix ClosedChannelException when downloading from S3 (CASSANDRASC-112)
* Fix NPE thrown when getting StorageClient from pool (CASSANDRASC-110)
diff --git
a/src/main/java/org/apache/cassandra/sidecar/restore/RestoreSliceTask.java
b/src/main/java/org/apache/cassandra/sidecar/restore/RestoreSliceTask.java
index ecd0734..4e942c7 100644
--- a/src/main/java/org/apache/cassandra/sidecar/restore/RestoreSliceTask.java
+++ b/src/main/java/org/apache/cassandra/sidecar/restore/RestoreSliceTask.java
@@ -107,7 +107,7 @@ public class RestoreSliceTask implements
Handler>
slice.compressedSize() +
slice.uncompressedSize(),
requiredUsableSpacePercentage,
executorPool)
-.onSuccess(ignored -> {
+.compose(v -> {
RestoreJob job = slice.job();
if (job.isManagedBySidecar())
{
@@ -120,55 +120,63 @@ public class RestoreSliceTask implements
Handler>
slice.completeStagePhase(); // update the flag if
missed
sliceDatabaseAccessor.updateStatus(slice);
event.tryComplete(slice);
-return;
+return Future.succeededFuture();
}
// 1. check object existence and validate eTag / checksum
-checkObjectExistence(event)
+CompletableFuture fut = checkObjectExistence(event)
// 2. download slice/object when the remote object exists
.thenCompose(headObject -> downloadSlice(event))
// 3. persist status
-.thenAccept(x -> {
+.thenAccept(file -> {
slice.completeStagePhase();
sliceDatabaseAccessor.updateStatus(slice);
// completed staging. A new task is produced when it
comes to import
event.tryComplete(slice);
+})
+.whenComplete((x, cause) -> {
+if (cause != null)
+{
+// handle unexpected errors thrown during download
slice call, that do not close event
+
event.tryFail(RestoreJobExceptions.ofSlice(cause.getMessage(), slice, cause));
+}
});
+
+return Future.fromCompletionStage(fut);
}
else if (job.status == RestoreJobStatus.STAGED)
{
-unzipAndImport(event, slice.stagedObjectPath().toFile(),
- // persist status
- () ->
sliceDatabaseAccessor.updateStatus(slice));
+return unzipAndImport(event,
slice.stagedObjectPath().toFile(),
+ // persist status
+ () ->
sliceDatabaseAccessor.updateStatus(slice));
}
else
{
String msg = "Unexpected restore job status. Expected only
CREATED or STAGED when " +
"processing active slices. Found status: " +
job.status;
Exception unexpectedState = new IllegalStateException(msg);
-
event.tryFail(RestoreJobExceptions.ofFatalSlice("Unexpected restore job status",
-slice,
unexpectedState));
+return
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828117#comment-17828117
]
Michael Semb Wever commented on CASSANDRA-19467:
This following isn't working with the patch yet
{code}
python_version=3.6 .build/docker/run-tests.sh cqlsh-test
{code}
as it gives the following
{noformat}
update-alternatives: error: alternative /usr/bin/python3.6 for python not
registered; not setting
{noformat}
so the default of python3.8 will be used.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18661) Update cassandra-stress to use Apache Commons CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828088#comment-17828088
]
Brad Schoening commented on CASSANDRA-18661:
{{Improving and modernizing the projects stress testing tools is overdue and
easy-caas-stress looks sophisticated and easy to use. }}Perhaps that a topic
for the ML or even a CEP?
> Update cassandra-stress to use Apache Commons CLI
> -
>
> Key: CASSANDRA-18661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18661
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/stress
>Reporter: Brad Schoening
>Assignee: Claude Warren
>Priority: Normal
> Labels: lhf
>
> The Apache Commons CLI library provides an API for parsing command line
> options with the package org.apache.commons.cli and this is already used by a
> dozen of existing Cassandra utilities including:
> {quote}SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
> SSTableExport, BulkLoader, and others.
> {quote}
> However, cassandra-stress is an outlier which uses its own custom classes to
> parse command line options with classes such as OptionsSimple. In addition,
> the options syntax for username, password, and others are not aligned with
> the format used by CQLSH.
> Currently, there are > 5K lines of code in 'settings' which appears to just
> process command line args.
> This suggestion is to:
>
> a) Upgrade cassandra-stress to use Apache Commons CLI (no new dependencies
> are required as this library is already used by the project)
>
> b) Align the cassandra-stress CLI options with those in CQLSH,
>
> {quote}For example, using the new syntax like CQLSH:
> {quote}
>
> cassandra-stress -username foo -password bar
> {quote}and replacing the old syntax:
> {quote}
> cassandra-stress -mode username=foo and password=bar
>
> This will simplify and unify the code base, eliminate code and reduce the
> confusion between similar named classes such as
> org.apache.cassandra.stress.settings.\{Option, OptionsMulti, OptionsSimple}
> and org.apache.commons.cli.{Option, OptionGroup, Options)
>
> Note: documentation will need to be updated as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18661) Update cassandra-stress to use Apache Commons CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828088#comment-17828088
]
Brad Schoening edited comment on CASSANDRA-18661 at 3/18/24 8:14 PM:
-
Improving and modernizing the projects stress testing tools is overdue and
easy-caas-stress looks sophisticated and easy to use. }}Perhaps that a topic
for the ML or even a CEP?
was (Author: bschoeni):
{{Improving and modernizing the projects stress testing tools is overdue and
easy-caas-stress looks sophisticated and easy to use. }}Perhaps that a topic
for the ML or even a CEP?
> Update cassandra-stress to use Apache Commons CLI
> -
>
> Key: CASSANDRA-18661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18661
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/stress
>Reporter: Brad Schoening
>Assignee: Claude Warren
>Priority: Normal
> Labels: lhf
>
> The Apache Commons CLI library provides an API for parsing command line
> options with the package org.apache.commons.cli and this is already used by a
> dozen of existing Cassandra utilities including:
> {quote}SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
> SSTableExport, BulkLoader, and others.
> {quote}
> However, cassandra-stress is an outlier which uses its own custom classes to
> parse command line options with classes such as OptionsSimple. In addition,
> the options syntax for username, password, and others are not aligned with
> the format used by CQLSH.
> Currently, there are > 5K lines of code in 'settings' which appears to just
> process command line args.
> This suggestion is to:
>
> a) Upgrade cassandra-stress to use Apache Commons CLI (no new dependencies
> are required as this library is already used by the project)
>
> b) Align the cassandra-stress CLI options with those in CQLSH,
>
> {quote}For example, using the new syntax like CQLSH:
> {quote}
>
> cassandra-stress -username foo -password bar
> {quote}and replacing the old syntax:
> {quote}
> cassandra-stress -mode username=foo and password=bar
>
> This will simplify and unify the code base, eliminate code and reduce the
> confusion between similar named classes such as
> org.apache.cassandra.stress.settings.\{Option, OptionsMulti, OptionsSimple}
> and org.apache.commons.cli.{Option, OptionGroup, Options)
>
> Note: documentation will need to be updated as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-18661) Update cassandra-stress to use Apache Commons CLI
[
https://issues.apache.org/jira/browse/CASSANDRA-18661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828088#comment-17828088
]
Brad Schoening edited comment on CASSANDRA-18661 at 3/18/24 8:14 PM:
-
Improving and modernizing the projects stress testing tools is overdue and
easy-caas-stress looks sophisticated and easy to use. Perhaps that is a topic
for the ML or even a CEP?
was (Author: bschoeni):
Improving and modernizing the projects stress testing tools is overdue and
easy-caas-stress looks sophisticated and easy to use. }}Perhaps that a topic
for the ML or even a CEP?
> Update cassandra-stress to use Apache Commons CLI
> -
>
> Key: CASSANDRA-18661
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18661
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/stress
>Reporter: Brad Schoening
>Assignee: Claude Warren
>Priority: Normal
> Labels: lhf
>
> The Apache Commons CLI library provides an API for parsing command line
> options with the package org.apache.commons.cli and this is already used by a
> dozen of existing Cassandra utilities including:
> {quote}SSTableMetadataViewer, StandaloneScrubber, StandaloneSplitter,
> SSTableExport, BulkLoader, and others.
> {quote}
> However, cassandra-stress is an outlier which uses its own custom classes to
> parse command line options with classes such as OptionsSimple. In addition,
> the options syntax for username, password, and others are not aligned with
> the format used by CQLSH.
> Currently, there are > 5K lines of code in 'settings' which appears to just
> process command line args.
> This suggestion is to:
>
> a) Upgrade cassandra-stress to use Apache Commons CLI (no new dependencies
> are required as this library is already used by the project)
>
> b) Align the cassandra-stress CLI options with those in CQLSH,
>
> {quote}For example, using the new syntax like CQLSH:
> {quote}
>
> cassandra-stress -username foo -password bar
> {quote}and replacing the old syntax:
> {quote}
> cassandra-stress -mode username=foo and password=bar
>
> This will simplify and unify the code base, eliminate code and reduce the
> confusion between similar named classes such as
> org.apache.cassandra.stress.settings.\{Option, OptionsMulti, OptionsSimple}
> and org.apache.commons.cli.{Option, OptionGroup, Options)
>
> Note: documentation will need to be updated as well
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19475:
-
Status: Ready to Commit (was: Review In Progress)
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828073#comment-17828073
]
Brandon Williams commented on CASSANDRA-19475:
--
Indeed, and I don't think we need to multiplex it for flakiness :) I am +1.
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-19475:
-
Reviewers: Brandon Williams
Status: Review In Progress (was: Needs Committer)
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828071#comment-17828071
]
Stefan Miklosovic commented on CASSANDRA-19475:
---
[~brandon.williams] is that better now?
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19475:
--
Test and Documentation Plan: CI
Status: Patch Available (was: In Progress)
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-19475:
--
Status: Needs Committer (was: Patch Available)
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19467:
Reviewers: Brandon Williams, Michael Semb Wever (was: Brandon Williams)
Status: Review In Progress (was: Patch Available)
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19467:
Status: Patch Available (was: In Progress)
Trunk patch here: https://github.com/apache/cassandra/pull/3183
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19185) Vector search tests are failing on recall accuracy
[ https://issues.apache.org/jira/browse/CASSANDRA-19185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828055#comment-17828055 ] Mike Adamson commented on CASSANDRA-19185: -- Thanks, I've done a few commits now so should be good, but thanks for the offer. I'll get trunk propagated and tested and commit if good. > Vector search tests are failing on recall accuracy > -- > > Key: CASSANDRA-19185 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19185 > Project: Cassandra > Issue Type: Bug > Components: Feature/SAI >Reporter: Mike Adamson >Assignee: Mike Adamson >Priority: Normal > Fix For: 5.0.x, 5.x > > Time Spent: 0.5h > Remaining Estimate: 0h > > Vector tests are failing randomly because they do not meet recall assertion > values. Currently, the following tests have been reported as failing: > VectorSegmentationTest.testMultipleSegmentsForCompaction > VectorDistributedTest.rangeRestrictedTest > VectorDistributedTest.testPartitionRestrictedVectorSearch > Since the vector searches are approximate and the vectors used in the tests > are random, it is unlikely that they will always meet a high recall. The > recall assertions are looking for recall values of 0.9 and above. Part of > this issue is related to the use of random values in the vectors being > tested. We have seen, with other tests, that the vector search performs > better with non-random generated datasets like the Glove datasets. As such, > there are the following available to fix these tests. > # Downgrade the assertions to a value that is likely to always pass. The > problem is that there is no guarantee that a test will always pass any recall > value we give it. > # Use generated datasets for these tests to see if that improves the recall > results. > # Remove the recall assertions unless they are specifically asked for. We > could use a system property to enable recall testing for targeted vector > testing. > I don't think option 1 is a viable long-term solution as we can never be > certain that it will always work. Option 2 has more promise but it could > still result in failures because of the approximate nature of the vector > searches. As such, option 3 seems the only viable solution here but means > that, in most cases, we are only really testing that we are returning results > from the search, not how accurate those results are. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-19467:
Status: In Progress (was: Changes Suggested)
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828046#comment-17828046
]
Caleb Rackliffe commented on CASSANDRA-19467:
-
Trunk looks
[clean|https://app.circleci.com/pipelines/github/driftx/cassandra/1529/workflows/853803b5-510d-48b8-9388-2b60151a923b].
Any objections to moving forward (w/ the non-cqlsh changes reverted now and
CASSANDRA-19478 created)?
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828045#comment-17828045
]
Brandon Williams commented on CASSANDRA-19467:
--
bq. and something there is probably broken
Good thing I am not infallible; trunk looks clean.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828040#comment-17828040
]
Caleb Rackliffe edited comment on CASSANDRA-19467 at 3/18/24 4:31 PM:
--
RE the {{.build/run-python-dtests.sh}} change, I think I can just revert that
in the patch.
EDIT: This is done
was (Author: maedhroz):
RE the {{.build/run-python-dtests.sh}} change, I think I can just revert that
in the patch.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828043#comment-17828043
]
Brandon Williams edited comment on CASSANDRA-19467 at 3/18/24 4:28 PM:
---
We probably do to make sure we don't add any non-py36 changes. I don't think
it would be great to say you can run it as is in 5.0.0 but then break it
accidentally in 5.0.1.
was (Author: brandon.williams):
We probably do to make sure we don't add any non-py36 changes.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19480) [Analytics] Report task level job stats from analytics
Arjun Ashok created CASSANDRA-19480: --- Summary: [Analytics] Report task level job stats from analytics Key: CASSANDRA-19480 URL: https://issues.apache.org/jira/browse/CASSANDRA-19480 Project: Cassandra Issue Type: Task Components: Analytics Library Reporter: Arjun Ashok This is an extension of https://issues.apache.org/jira/browse/CASSANDRA-19418. to instrument spark task level metrics such as max task retries and task execution time stats (max, median, p90 across tasks within the job) from the analytics library. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828042#comment-17828042
]
Caleb Rackliffe edited comment on CASSANDRA-19467 at 3/18/24 4:25 PM:
--
If 3.6 and 3.7 are still deprecated, and we're allowing them on a sort of
"as-is" basis for running cqlsh, do we need CASSANDRA-19478?
was (Author: maedhroz):
If 3.6 and 3.7 are still deprecated, and we're allowing them in a sort of
"as-is" for running cqlsh, do we need CASSANDRA-19478?
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828034#comment-17828034
]
Caleb Rackliffe edited comment on CASSANDRA-19467 at 3/18/24 4:23 PM:
--
> Trunk doesn't need to be 3.6 compatible.
At least from [the Slack
conversation|https://the-asf.slack.com/archives/CK23JSY2K/p1710255088441369],
it looks like the idea was to actually remove all support in 6.0, so we'd still
want this in trunk, which will be 5.1?
was (Author: maedhroz):
> Trunk doesn't need to be 3.6 compatible.
At least from [the Slack
conversation|http://example.com]https://the-asf.slack.com/archives/CK23JSY2K/p1710255088441369,
it looks like the idea was to actually remove all support in 6.0, so we'd
still want this in trunk, which will be 5.1?
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828040#comment-17828040
]
Caleb Rackliffe commented on CASSANDRA-19467:
-
RE the {{.build/run-python-dtests.sh}} change, I think I can just revert that
in the patch.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19479) Provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski updated CASSANDRA-19479: -- Change Category: Quality Assurance Complexity: Normal Fix Version/s: 5.0-rc 5.0 Status: Open (was: Triage Needed) > Provide tests for type compatibility between 4.1 and 5.0 > > > Key: CASSANDRA-19479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19479 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > Fix For: 5.0-rc, 5.0 > > > Part of CASSANDRA-14476, we should verify whether the type compatibility > matrix is upgradable from 4.0 and 4.1 to 5.0 and if not, fix the remaining > issues. > The test were implemented under CASSANDRA-14476, we need to verify that in > that certain upgrade paths. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828035#comment-17828035
]
Brandon Williams commented on CASSANDRA-19467:
--
Ah, good point, and something there is probably broken:
https://app.circleci.com/pipelines/github/driftx/cassandra/1529/workflows/853803b5-510d-48b8-9388-2b60151a923b
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-19479) Provide tests for type compatibility between 4.1 and 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Lewandowski reassigned CASSANDRA-19479: - Assignee: Jacek Lewandowski > Provide tests for type compatibility between 4.1 and 5.0 > > > Key: CASSANDRA-19479 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19479 > Project: Cassandra > Issue Type: Task > Components: Test/unit >Reporter: Jacek Lewandowski >Assignee: Jacek Lewandowski >Priority: Normal > > Part of CASSANDRA-14476, we should verify whether the type compatibility > matrix is upgradable from 4.0 and 4.1 to 5.0 and if not, fix the remaining > issues. > The test were implemented under CASSANDRA-14476, we need to verify that in > that certain upgrade paths. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19479) Provide tests for type compatibility between 4.1 and 5.0
Jacek Lewandowski created CASSANDRA-19479: - Summary: Provide tests for type compatibility between 4.1 and 5.0 Key: CASSANDRA-19479 URL: https://issues.apache.org/jira/browse/CASSANDRA-19479 Project: Cassandra Issue Type: Task Components: Test/unit Reporter: Jacek Lewandowski Part of CASSANDRA-14476, we should verify whether the type compatibility matrix is upgradable from 4.0 and 4.1 to 5.0 and if not, fix the remaining issues. The test were implemented under CASSANDRA-14476, we need to verify that in that certain upgrade paths. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828034#comment-17828034
]
Caleb Rackliffe commented on CASSANDRA-19467:
-
> Trunk doesn't need to be 3.6 compatible.
At least from [the Slack
conversation|http://example.com]https://the-asf.slack.com/archives/CK23JSY2K/p1710255088441369,
it looks like the idea was to actually remove all support in 6.0, so we'd
still want this in trunk, which will be 5.1?
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828027#comment-17828027
]
Michael Semb Wever commented on CASSANDRA-19467:
Correct (aside from the commented intent). TBC the patch as-is doesn't fix what
it is intending to.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828018#comment-17828018
]
Brandon Williams commented on CASSANDRA-19475:
--
It would be good to add a test for this.
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828016#comment-17828016
]
Brandon Williams commented on CASSANDRA-19467:
--
bq. But it won't work for 3.6 and 3.7
So this didn't actually break anything, we just need 3.6 support? That is
CASSANDRA-19478.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828015#comment-17828015
]
Stefan Miklosovic commented on CASSANDRA-19475:
---
[CASSANDRA-19475-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19475-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py3116m 2s
✓ j17_cqlsh_dtests_py311_vnode 6m 12s
✓ j17_cqlsh_dtests_py385m 51s
✓ j17_cqlsh_dtests_py38_vnode 6m 35s
✓ j17_cqlshlib_cython_tests7m 20s
✓ j17_cqlshlib_tests 6m 13s
✓ j17_dtests 31m 29s
✓ j17_dtests_latest_repeat 0m 40s
✓ j17_dtests_vnode32m 51s
✓ j17_jvm_dtests 21m 25s
✓ j17_jvm_dtests_latest_vnode 14m 28s
✓ j17_jvm_dtests_latest_vnode_repeat 0m 12s
✓ j17_unit_tests 15m 0s
✓ j17_unit_tests_repeat3m 21s
✓ j17_utests_latest 15m 22s
✓ j17_utests_latest_repeat 3m 27s
✓ j17_utests_oa 15m 37s
✓ j17_utests_oa_repeat 3m 22s
✕ j17_dtests_latest 31m 58s
configuration_test.TestConfiguration test_change_durable_writes
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ff89694a-7940-4023-a588-d61e0898ed98]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/5455310a-c21e-4319-bcea-a06482b79ab8]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ef77db14-9214-40e6-abc6-78a2f0bf1f23]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/c558fc05-7e5b-4e2c-81da-15743ea2d28a]
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[ https://issues.apache.org/jira/browse/CASSANDRA-19475 ]
Stefan Miklosovic deleted comment on CASSANDRA-19475:
---
was (Author: smiklosovic):
[CASSANDRA-19475-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19475-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py3116m 2s
✓ j17_cqlsh_dtests_py311_vnode 6m 12s
✓ j17_cqlsh_dtests_py385m 51s
✓ j17_cqlsh_dtests_py38_vnode 6m 35s
✓ j17_cqlshlib_cython_tests7m 20s
✓ j17_cqlshlib_tests 6m 13s
✓ j17_dtests 31m 29s
✓ j17_dtests_latest_repeat 0m 40s
✓ j17_dtests_vnode32m 51s
✓ j17_jvm_dtests 21m 25s
✓ j17_jvm_dtests_latest_vnode 14m 28s
✓ j17_jvm_dtests_latest_vnode_repeat 0m 12s
✓ j17_unit_tests 15m 0s
✓ j17_unit_tests_repeat3m 21s
✓ j17_utests_latest 15m 22s
✓ j17_utests_latest_repeat 3m 27s
✓ j17_utests_oa 15m 37s
✓ j17_utests_oa_repeat 3m 22s
✕ j17_dtests_latest 31m 58s
configuration_test.TestConfiguration test_change_durable_writes
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ff89694a-7940-4023-a588-d61e0898ed98]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/5455310a-c21e-4319-bcea-a06482b79ab8]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ef77db14-9214-40e6-abc6-78a2f0bf1f23]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/c558fc05-7e5b-4e2c-81da-15743ea2d28a]
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17828014#comment-17828014
]
Stefan Miklosovic commented on CASSANDRA-19475:
---
[CASSANDRA-19475-trunk|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19475-trunk]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 38s
✓ j17_cqlsh_dtests_py311 7m 12s
✓ j17_cqlsh_dtests_py311_vnode 7m 8s
✓ j17_cqlsh_dtests_py387m 12s
✓ j17_cqlsh_dtests_py38_vnode 7m 10s
✓ j17_cqlshlib_cython_tests7m 16s
✓ j17_cqlshlib_tests 6m 47s
✓ j17_dtests 36m 9s
✓ j17_dtests_latest_repeat 0m 49s
✓ j17_dtests_vnode34m 28s
✓ j17_jvm_dtests_latest_vnode 22m 51s
✓ j17_jvm_dtests_latest_vnode_repeat 0m 37s
✓ j17_unit_tests 14m 47s
✓ j17_unit_tests_repeat7m 16s
✓ j17_utests_latest15m 5s
✓ j17_utests_latest_repeat 4m 33s
✓ j17_utests_oa 15m 38s
✓ j17_utests_oa_repeat 4m 49s
✕ j17_dtests_latest 35m 13s
bootstrap_test.TestBootstrap test_bootstrap_with_reset_bootstrap_state
offline_tools_test.TestOfflineTools test_sstablelevelreset
offline_tools_test.TestOfflineTools test_sstableofflinerelevel
configuration_test.TestConfiguration test_change_durable_writes
✕ j17_jvm_dtests 26m 9s
org.apache.cassandra.fuzz.ring.ConsistentBootstrapTest
coordinatorIsBehindTest
java17_separate_tests
✓ j17_build3m 50s
✓ j17_dtests_vnode33m 36s
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4036/workflows/d1d2958b-ac08-4cb4-862f-3e1bba46daab]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4036/workflows/7e891c0e-bc9a-4e17-9499-5c91ea08642f]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4036/workflows/9f7aacfd-bf42-4399-81a1-eac5b7913bcf]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4036/workflows/512cb92e-9b20-41b2-af1a-d6a398469724]
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827979#comment-17827979
]
Michael Semb Wever commented on CASSANDRA-19467:
First up the {{.build/run-python-dtests.sh}} isn't used to run cqlsh tests, and
AFAIK the python dtests should all remain python >=3.8 from 5.0 up.
The scripts that run the cqlsh tests ({{pylib/cqlshlib/test/run_cqlsh.py}}) are
{{.build/run-tests.sh}} and {{.build/docker/run-tests.sh}}
The former doesn't have any python version validation in it. (It should!)
It sets the python_version here:
https://github.com/apache/cassandra/blob/cassandra-5.0/.build/docker/run-tests.sh#L225
But it won't work for 3.6 and 3.7 because these pyenv are not available in the
image:
https://github.com/apache/cassandra/blob/cassandra-5.0/.build/docker/ubuntu2004_test.docker#L50-L60
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-19467:
---
Status: Changes Suggested (was: Ready to Commit)
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827953#comment-17827953
]
Michael Semb Wever edited comment on CASSANDRA-19467 at 3/18/24 12:36 PM:
--
this broke .build/docker/run-tests.sh
The docker test image needs to be updated for the .build/run-tests.sh change to
work.
https://github.com/apache/cassandra/blob/cassandra-5.0/.build/docker/ubuntu2004_test.docker
was (Author: michaelsembwever):
this broke .build/docker/run-tests.sh
The docker test image need to be updated for the .build/run-tests.sh change to
work.
https://github.com/apache/cassandra/blob/cassandra-5.0/.build/docker/ubuntu2004_test.docker
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827953#comment-17827953
]
Michael Semb Wever commented on CASSANDRA-19467:
this broke .build/docker/run-tests.sh
The docker test image need to be updated for the .build/run-tests.sh change to
work.
https://github.com/apache/cassandra/blob/cassandra-5.0/.build/docker/ubuntu2004_test.docker
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827951#comment-17827951
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:33 PM:
---
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
was (Author: JIRAUSER303038):
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827951#comment-17827951
]
Arun Ganesh commented on CASSANDRA-19150:
-
Additionally,
# I noticed some deadcode. There are multiple places with code like this,
{code:java}
return bval if colormap is NO_COLOR_MAP else ...
{code}
When the {{--no-color}} flag is passed, or the tty is "dumb", we do this
{code:python}
if addcolor is False:
colormap = empty_colormap
{code}
where {{{}empty_colormap = defaultdict(lambda: ''){}}}. The {{NO_COLOR_MAP}} is
just a plain {{{}dict(){}}}.
{{colormap is NO_COLOR_MAP}} will always be {{{}False{}}}.
{code:python}
$ python3
Python 3.8.18 (default, Dec 16 2023, 04:10:16)
>>> from collections import defaultdict
>>> a = defaultdict(lambda: '')
>>> b = dict()
>>> a is b
False{code}
# I found two formatter functions for the `duration` type. Is there a
difference between `Duration` and `duration`?
{code:python}
formatter_for('duration')(format_integer_type)
.
.
.
@formatter_for('Duration')
def format_value_duration(val, colormap, **_):
return format_python_formatted_type(duration_as_str(val.months, val.days,
val.nanoseconds), colormap, 'duration'){code}
The second one is picked up always.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827947#comment-17827947
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:13 PM:
---
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
was (Author: JIRAUSER303038):
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827947#comment-17827947
]
Arun Ganesh edited comment on CASSANDRA-19150 at 3/18/24 12:13 PM:
---
Sorry, I took a while to get back to this. I have a [draft
PR|https://github.com/apache/cassandra/pull/3182] ready. I have two items to
discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
was (Author: JIRAUSER303038):
Sorry, I took a while to get back to this. I have a draft PR ready. I have two
items to discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19150) Align values in rows in CQLSH right for numbers, left for text
[
https://issues.apache.org/jira/browse/CASSANDRA-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827947#comment-17827947
]
Arun Ganesh commented on CASSANDRA-19150:
-
Sorry, I took a while to get back to this. I have a draft PR ready. I have two
items to discuss:
# I'd like some feedback on the design. The formatter for each type will
request whatever alignment it wants
like this, (I'm yet to do this on the PR)
{code:java}
return FormattedValue(val, coloredval, displaywidth,
alignment=Alignment.LEFT){code}
# I'm planning to use the following left/right alignment for the different
types (inspired from psql).
|*Type*|*Alignment*|
|default|right|
|blob/bytearray|left|
|decimal|right|
|uuid/timeuuid|left|
|inet|left|
|bool|left|
|float/double|right|
|text/unicode/ascii|left|
|set/list/map|right|
|user types|right|
When the expand mode is enabled, everything is aligned to the left, just like
in psql.
> Align values in rows in CQLSH right for numbers, left for text
> --
>
> Key: CASSANDRA-19150
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19150
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Interpreter
>Reporter: Stefan Miklosovic
>Assignee: Arun Ganesh
>Priority: Low
> Fix For: 5.x
>
> Attachments: Screenshot 2023-12-04 at 00.38.16.png, Screenshot
> 2023-12-09 at 16.58.25.png, signature.asc
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> *Updated* Jan 17 2024 after dev discussion
> Change CQLSH to left-align text while continue to right-align numbers. This
> will match how Postgres shell and Excel treat alignment of text and number.
> -
> *Original*
> We need to make this
> [https://github.com/apache/cassandra/blob/trunk/pylib/cqlshlib/cqlshmain.py#L1101]
> configurable so values in columns are either all on left or on right side of
> the column (basically change col.rjust to col.ljust).
> By default, it would be like it is now but there would be configuration
> property in cqlsh for that as well as a corresponding CQLSH command
> (optional), something like
> {code:java}
> ALIGNMENT LEFT|RIGHT
> {code}
> cc [~bschoeni]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19478) Add CI for python 3.6 back to 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19478: -- Issue Type: Task (was: Improvement) > Add CI for python 3.6 back to 5.0 > - > > Key: CASSANDRA-19478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.0.x > > > 5.0 doesn't currently run python 3.6 (but branches below it do) however in > CASSANDRA-19467 we have restored python 3.6 support so we should have test > coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19478) Add CI for python 3.6 back to 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827931#comment-17827931 ] Brandon Williams commented on CASSANDRA-19478: -- /cc [~mck] [~jmckenzie] pinging y'all for awareness. I don't have any insight to your CI system Josh but you may need to adjust it too. > Add CI for python 3.6 back to 5.0 > - > > Key: CASSANDRA-19478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.0.x > > > 5.0 doesn't currently run python 3.6 (but branches below it do) however in > CASSANDRA-19467 we have restored python 3.6 support so we should have test > coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19478) Add CI for python 3.6 back to 5.0
[ https://issues.apache.org/jira/browse/CASSANDRA-19478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19478: - Change Category: Operability Complexity: Normal Component/s: CI Fix Version/s: 5.0.x Status: Open (was: Triage Needed) > Add CI for python 3.6 back to 5.0 > - > > Key: CASSANDRA-19478 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Brandon Williams >Priority: Normal > Fix For: 5.0.x > > > 5.0 doesn't currently run python 3.6 (but branches below it do) however in > CASSANDRA-19467 we have restored python 3.6 support so we should have test > coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-19478) Add CI for python 3.6 back to 5.0
Brandon Williams created CASSANDRA-19478: Summary: Add CI for python 3.6 back to 5.0 Key: CASSANDRA-19478 URL: https://issues.apache.org/jira/browse/CASSANDRA-19478 Project: Cassandra Issue Type: Improvement Reporter: Brandon Williams 5.0 doesn't currently run python 3.6 (but branches below it do) however in CASSANDRA-19467 we have restored python 3.6 support so we should have test coverage for it. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19469) python dtest packages should pin versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19469: - Resolution: Fixed Status: Resolved (was: Ready to Commit) Thanks, committed. > python dtest packages should pin versions > - > > Key: CASSANDRA-19469 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19469 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > We have for example in CASSANDRA-19464 seen how allowing modules to > automatically upgrade themselves causes us problems. We should pin all of > these to specific versions so that the environment is entirely reproducible. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19469) python dtest packages should pin versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-19469: - Status: Ready to Commit (was: Review In Progress) > python dtest packages should pin versions > - > > Key: CASSANDRA-19469 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19469 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > We have for example in CASSANDRA-19464 seen how allowing modules to > automatically upgrade themselves causes us problems. We should pin all of > these to specific versions so that the environment is entirely reproducible. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
(cassandra-dtest) branch trunk updated: Pin packages to python3.6 versions
This is an automated email from the ASF dual-hosted git repository. brandonwilliams 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 7a82b375 Pin packages to python3.6 versions 7a82b375 is described below commit 7a82b3757c136f79b52a76fdf3e98891dfff6b41 Author: Brandon Williams AuthorDate: Fri Mar 15 13:18:47 2024 -0500 Pin packages to python3.6 versions Patch by brandonwilliams; reviewed by smiklosovic for CASSANDRA-19469 --- requirements.txt | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git a/requirements.txt b/requirements.txt index dbecfbd2..a2187d5a 100644 --- a/requirements.txt +++ b/requirements.txt @@ -10,28 +10,29 @@ # In case you want to test a patch with your own CCM branch, further to changing below CCM repo and branch name, you need to add -e flag at the beginning # Example: -e git+https://github.com/userb/ccm.git@cassandra-17182#egg=ccm git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm -click==8.1.7 +click==8.0.4 decorator==5.1.1 docopt==0.6.2 enum34==1.1.10 -exceptiongroup==1.2.0 +exceptiongroup==0.0.0a0 flaky==3.8.1 geomet==0.2.1.post1 -iniconfig==2.0.0 +iniconfig==1.1.1 lxml==5.1.0 mock==5.1.0 netifaces==0.11.0 -packaging==24.0 +packaging==21.3 parse==1.20.1 -pluggy==1.4.0 +pluggy==1.0.0 psutil==5.9.8 py==1.11.0 -pycodestyle==2.11.1 -pytest==8.0.2 -pytest-repeat==0.9.3 -pytest-timeout==1.4.2 +pycodestyle==2.10.0 +pyparsing==3.1.2 +pytest==7.0.1 +pytest-repeat==0.9.1 +pytest-timeout==2.1.0 PyYAML==6.0.1 six==1.16.0 -soupsieve==2.5 -thrift==0.10.0 -tomli==2.0.1 +soupsieve==2.3.2.post1 +thrift==0.16.0 +tomli==1.2.3 - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19469) python dtest packages should pin versions
[ https://issues.apache.org/jira/browse/CASSANDRA-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-19469: -- Reviewers: Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Stefan Miklosovic, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Patch Available) +1 lets see :D > python dtest packages should pin versions > - > > Key: CASSANDRA-19469 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19469 > Project: Cassandra > Issue Type: Bug > Components: Test/dtest/python >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0, 5.1 > > Time Spent: 20m > Remaining Estimate: 0h > > We have for example in CASSANDRA-19464 seen how allowing modules to > automatically upgrade themselves causes us problems. We should pin all of > these to specific versions so that the environment is entirely reproducible. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19469) python dtest packages should pin versions
[
https://issues.apache.org/jira/browse/CASSANDRA-19469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827925#comment-17827925
]
Stefan Miklosovic commented on CASSANDRA-19469:
---
[CASSANDRA-19469-4.1|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19469-4.1]
{noformat}
java11_pre-commit_tests
✓ j11_build 2m 6s
✓ j11_cqlsh_dtests_py3 5m 43s
✓ j11_cqlsh_dtests_py311 5m 21s
✓ j11_cqlsh_dtests_py311_vnode 6m 10s
✓ j11_cqlsh_dtests_py385m 56s
✓ j11_cqlsh_dtests_py38_vnode 6m 19s
✓ j11_cqlsh_dtests_py3_vnode8m 8s
✓ j11_cqlshlib_cython_tests7m 40s
✓ j11_cqlshlib_tests 6m 33s
✓ j11_dtests 32m 16s
✓ j11_dtests_vnode37m 49s
✓ j11_jvm_dtests 27m 40s
✓ j11_jvm_dtests_vnode23m 52s
✕ j11_unit_tests 8m 15s
org.apache.cassandra.cql3.MemtableSizeTest testSize[skiplist]
java11_separate_tests
java8_pre-commit_tests
java8_separate_tests
{noformat}
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4035/workflows/aeb042ef-f63c-44df-a3d0-d1ae29a0cb91]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4035/workflows/c386dea4-366f-4bcd-b969-8b2a7f159d9c]
[java8_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4035/workflows/8ec74b87-46ec-4456-ad80-784e4c7a263e]
[java8_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4035/workflows/b7077ed0-b3e1-4fa5-9b55-ee12be02e340]
> python dtest packages should pin versions
> -
>
> Key: CASSANDRA-19469
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19469
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: Brandon Williams
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 3.0.30, 3.11.17, 4.0.13, 4.1.5, 5.0, 5.1
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We have for example in CASSANDRA-19464 seen how allowing modules to
> automatically upgrade themselves causes us problems. We should pin all of
> these to specific versions so that the environment is entirely reproducible.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19467) Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
[
https://issues.apache.org/jira/browse/CASSANDRA-19467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827912#comment-17827912
]
Brandon Williams commented on CASSANDRA-19467:
--
Trunk doesn't need to be 3.6 compatible.
> Deprecate Python 3.7 and earlier, but allow cqlsh to run with Python 3.6+
> -
>
> Key: CASSANDRA-19467
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19467
> Project: Cassandra
> Issue Type: Task
> Components: Tool/cqlsh
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 5.0-rc, 5.1
>
> Attachments: ci_summary.html
>
>
> In 4.0, we introduced Python 3.6 support. In CASSANDRA-19245, for the 5.0
> release, we dropped Python 3.6 and 3.7 support since Python 3.8 was the
> minimum supported version for version 3.29.0 of the Python driver, which we
> needed to support vectors. Unfortunately, that may break existing users of
> RHEL 7, which natively only supports Python 3.6.
> We should deprecate Python 3.6-3.7 (which are all either EOL or will be soon)
> and mention this in NEWS.txt/appropriate warnings at {{cqlsh}} startup, but
> we don't need to have cqlsh refuse to start entirely with 3.6-3.7 until our
> 6.0 release.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19193) Reimplement ClusterMetadata::writePlacementAllSettled
[ https://issues.apache.org/jira/browse/CASSANDRA-19193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-19193: Attachment: ci_summary.html result_details.tar.gz > Reimplement ClusterMetadata::writePlacementAllSettled > - > > Key: CASSANDRA-19193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19193 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 5.1-alpha1 > > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > This should step through InProgressSequences to determine state when > finished, rather than emulating the logic inline. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19193) Reimplement ClusterMetadata::writePlacementAllSettled
[ https://issues.apache.org/jira/browse/CASSANDRA-19193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-19193: Test and Documentation Plan: ci run Status: Patch Available (was: Open) > Reimplement ClusterMetadata::writePlacementAllSettled > - > > Key: CASSANDRA-19193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19193 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 5.1-alpha1 > > Attachments: ci_summary.html, result_details.tar.gz > > Time Spent: 10m > Remaining Estimate: 0h > > This should step through InProgressSequences to determine state when > finished, rather than emulating the logic inline. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-19193) Reimplement ClusterMetadata::writePlacementAllSettled
[ https://issues.apache.org/jira/browse/CASSANDRA-19193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-19193: Change Category: Semantic Complexity: Normal Component/s: Transactional Cluster Metadata Reviewers: Alex Petrov, Sam Tunnicliffe Status: Open (was: Triage Needed) > Reimplement ClusterMetadata::writePlacementAllSettled > - > > Key: CASSANDRA-19193 > URL: https://issues.apache.org/jira/browse/CASSANDRA-19193 > Project: Cassandra > Issue Type: Improvement > Components: Transactional Cluster Metadata >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson >Priority: Normal > Fix For: 5.1-alpha1 > > Time Spent: 10m > Remaining Estimate: 0h > > This should step through InProgressSequences to determine state when > finished, rather than emulating the logic inline. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-19475) system_views.settings incorrectly handle array types
[
https://issues.apache.org/jira/browse/CASSANDRA-19475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17827876#comment-17827876
]
Stefan Miklosovic commented on CASSANDRA-19475:
---
[CASSANDRA-19475-5.0|https://github.com/instaclustr/cassandra/tree/CASSANDRA-19475-5.0]
{noformat}
java17_pre-commit_tests
✓ j17_build4m 11s
✓ j17_cqlsh_dtests_py3116m 2s
✓ j17_cqlsh_dtests_py311_vnode 6m 12s
✓ j17_cqlsh_dtests_py385m 51s
✓ j17_cqlsh_dtests_py38_vnode 6m 35s
✓ j17_cqlshlib_cython_tests7m 20s
✓ j17_cqlshlib_tests 6m 13s
✓ j17_dtests 31m 29s
✓ j17_dtests_latest_repeat 0m 40s
✓ j17_dtests_vnode32m 51s
✓ j17_jvm_dtests 21m 25s
✓ j17_jvm_dtests_latest_vnode 14m 28s
✓ j17_jvm_dtests_latest_vnode_repeat 0m 12s
✓ j17_unit_tests 15m 0s
✓ j17_unit_tests_repeat3m 21s
✓ j17_utests_latest 15m 22s
✓ j17_utests_latest_repeat 3m 27s
✓ j17_utests_oa 15m 37s
✓ j17_utests_oa_repeat 3m 22s
✕ j17_dtests_latest 31m 58s
configuration_test.TestConfiguration test_change_durable_writes
java17_separate_tests
java11_pre-commit_tests
java11_separate_tests
{noformat}
[java17_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ff89694a-7940-4023-a588-d61e0898ed98]
[java17_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/5455310a-c21e-4319-bcea-a06482b79ab8]
[java11_pre-commit_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/ef77db14-9214-40e6-abc6-78a2f0bf1f23]
[java11_separate_tests|https://app.circleci.com/pipelines/github/instaclustr/cassandra/4032/workflows/c558fc05-7e5b-4e2c-81da-15743ea2d28a]
> system_views.settings incorrectly handle array types
>
>
> Key: CASSANDRA-19475
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19475
> Project: Cassandra
> Issue Type: Bug
> Components: Feature/Virtual Tables
>Reporter: Stefan Miklosovic
>Assignee: Stefan Miklosovic
>Priority: Normal
> Fix For: 4.1.x, 5.0-rc, 5.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> 4.1+ gives
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
> --
> [Ljava.lang.String;@21b4c4bb
> {noformat}
>
> should be
>
> {noformat}
> cqlsh> select value from system_views.settings where name =
> 'data_file_directories';
> value
>
> [/home/fermat/dev/cassandra/cassandra-instaclustr/cassandra-4.1/data/data]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
