[jira] [Assigned] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez reassigned CASSANDRA-17521: - Assignee: Erick Ramirez > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17521: -- Authors: Chris Thornett (was: Erick Ramirez) > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Assignee: Erick Ramirez >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517823#comment-17517823 ] Berenguer Blasi commented on CASSANDRA-17328: - +1 > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17328: Reviewers: Berenguer Blasi, Berenguer Blasi Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi) Status: Review In Progress (was: Patch Available) > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17328: Status: Ready to Commit (was: Review In Progress) > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17349: Status: Ready to Commit (was: Review In Progress) > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Berenguer Blasi updated CASSANDRA-17349: Reviewers: Berenguer Blasi, Berenguer Blasi Berenguer Blasi, Berenguer Blasi (was: Berenguer Blasi) Status: Review In Progress (was: Patch Available) > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517822#comment-17517822 ] Berenguer Blasi commented on CASSANDRA-17349: - +1 > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517820#comment-17517820
]
Berenguer Blasi commented on CASSANDRA-16916:
-
Also if you read the ML you'll notice a release is under discussion, so you'll
be live soon I hope :-)
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17520) repair vtables should expose a completed field due to lack of filtering options in CQL
[
https://issues.apache.org/jira/browse/CASSANDRA-17520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517806#comment-17517806
]
Zhao Yang commented on CASSANDRA-17520:
---
The patch LGTM
> repair vtables should expose a completed field due to lack of filtering
> options in CQL
> --
>
> Key: CASSANDRA-17520
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17520
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Repair, CQL/Syntax
>Reporter: David Capwell
>Assignee: David Capwell
>Priority: Normal
> Fix For: 4.x
>
>
> To find repairs actively running, we need to run the following command
> {code}
> SELECT *
> FROM system_views.repairs
> WHERE status IN ('setup', 'start', 'prepare_start', 'prepare_complete',
> 'repair_start', 'repair_complete')
> ALLOW FILTERING;
> {code}
> This is annoying, and a problem if more states are added in the future….
> Ideally we would do one of the following
> NOT IN:
> {code}
> status NOT IN (’success’, ’skip’, ‘failure’)
> {code}
> But this is not currently supported
> {code}
> cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND
> status NOT IN ('success', 'failure') ALLOW FILTERING;
> SyntaxException: line 1:73 no viable alternative at input 'NOT' (...WHERE
> duration_millis > 10 AND [status] NOT...)
> {code}
> Not Equals
> {code}
> cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND
> status != 'success' AND status !='failure' ALLOW FILTERING;
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Unsupported "!=" relation: status != 'success'"
> {code}
> This also fails
> {code}
> cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND
> status != 'success' AND status !='failure' ALLOW FILTERING;
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Unsupported "!=" relation: status != 'success'"
> {code}
> NULL Checking
> {code}
> state_success_timestamp IS NULL AND state_failure_timestamp IS NULL
> — OR
> state_success_timestamp=null AND state_failure_timestamp=null
> {code}
> This also fails
> {code}
> cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND
> state_success_timestamp IS NULL ALLOW FILTERING;
> SyntaxException: line 1:93 mismatched input 'NULL' expecting K_NOT (...> 10
> AND state_success_timestamp IS [NULL]…)
> cqlsh> select * from system_views.repairs WHERE duration_millis > 10 AND
> state_success_timestamp=null ALLOW FILTERING;
> InvalidRequest: Error from server: code=2200 [Invalid query]
> message="Unsupported null value for column state_success_timestamp"
> {code}
> Given that our filtering logic is restrictive, we need a column to expose if
> completed or not, so filtering works
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17521: - Status: Open (was: Triage Needed) > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17521: - Status: Patch Available (was: Open) https://github.com/apache/cassandra-website/pull/122 > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated CASSANDRA-17521: --- Labels: pull-request-available (was: ) > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Labels: pull-request-available > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517643#comment-17517643 ] Brad Schoening edited comment on CASSANDRA-17450 at 4/6/22 12:10 AM: - [~Bowen Song] that would seem just a risky loophole around the Python Foundation's planned EOL. Brandon's link shows CentOS 7 using the final bug fix release of 3.6.x on 7/2020 with no updates since. I'd suggest this be considered for 4.2. was (Author: bschoeni): [~Bowen Song] that would seem just a risky loophole around the Python Foundation's planned EOL. Brandon's link shows the final bug fix release of 3.6.x on 7/2020 with no updates since. I'd suggest this be considered for 4.2. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra-website] branch trunk updated: move and prepare files for content folder
This is an automated email from the ASF dual-hosted git repository.
anthony pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-website.git
The following commit(s) were added to refs/heads/trunk by this push:
new 1de171b9 move and prepare files for content folder
1de171b9 is described below
commit 1de171b910983628e1b7e19dbeac0a3bb09dbab0
Author: Anthony Grasso
AuthorDate: Sat Apr 2 15:41:01 2022 +1100
move and prepare files for content folder
* Added logic to move generated website and in-tree docs to content folder
* Added logic to remove hardcoded and missing domains from links
* Added logging functionality
patch by Anthony Grasso; reviewed by Michael Semb Wever for CASSANDRA-17374
---
site-content/Dockerfile | 2 +
site-content/docker-entrypoint.sh | 128 ++
2 files changed, 119 insertions(+), 11 deletions(-)
diff --git a/site-content/Dockerfile b/site-content/Dockerfile
index c38a2d1c..2993c5be 100644
--- a/site-content/Dockerfile
+++ b/site-content/Dockerfile
@@ -103,6 +103,8 @@ ENV
ANTORA_UI_BUNDLE_URL="https://github.com/apache/cassandra-website/raw/trunk/
ENV CASSANDRA_DOWNLOADS_URL="https://downloads.apache.org/cassandra/;
+ENV LOG_LEVEL="INFO"
+
EXPOSE 5151/tcp
# Run as build user from here
diff --git a/site-content/docker-entrypoint.sh
b/site-content/docker-entrypoint.sh
index e2f60f43..584fe0f0 100755
--- a/site-content/docker-entrypoint.sh
+++ b/site-content/docker-entrypoint.sh
@@ -26,10 +26,10 @@ generate_cassandra_versioned_docs() {
# a local copy as some of the pages need to be generated from the source
code.
if [ "$(find "${CASSANDRA_SOURCE_DIR}" -mindepth 1 -type f | wc -l)" -eq 0 ]
then
-echo "Cloning ${ANTORA_CONTENT_SOURCES_CASSANDRA_URL} to working directory"
+log_message "INFO" "Cloning ${ANTORA_CONTENT_SOURCES_CASSANDRA_URL} to
working directory"
git clone "${ANTORA_CONTENT_SOURCES_CASSANDRA_URL}"
"${CASSANDRA_WORKING_DIR}"
else
-echo "Copying ${CASSANDRA_SOURCE_DIR} to working directory"
+log_message "INFO" "Copying ${CASSANDRA_SOURCE_DIR} to working directory"
cp -a "${CASSANDRA_SOURCE_DIR}/." "${CASSANDRA_WORKING_DIR}/"
fi
@@ -51,12 +51,12 @@ generate_cassandra_versioned_docs() {
for version in ${GENERATE_CASSANDRA_VERSIONS}
do
-echo "Checking out '${version}'"
+log_message "INFO" "Checking out '${version}'"
pushd "${CASSANDRA_WORKING_DIR}" > /dev/null
git clean -xdff
git checkout "${version}"
-echo "Building JAR files"
+log_message "INFO" "Building JAR files"
# Nodetool docs are autogenerated, and that needs nodetool to be built.
However, before we can build nodetool we
# need to select the correct Java version
local doc_version=""
@@ -80,7 +80,7 @@ generate_cassandra_versioned_docs() {
sudo update-alternatives --set java ${java_version}
sudo update-alternatives --set javac ${javac_version}
-echo "Using Java compiler version $(javac -version) to compile Cassandra
JARs"
+log_message "INFO" "Using Java compiler version $(javac -version) to
compile Cassandra JARs"
ant realclean
ant "${ant_cmd_options}" gen-asciidoc
popd > /dev/null
@@ -93,7 +93,7 @@ generate_cassandra_versioned_docs() {
# generating the HTML.
sed -i '/^doc/d' .gitignore
git add .
- git commit -m "Automated commit: Generated nodetool and configuration
documentation for version ${doc_version}." || echo "No new changes to commit."
+ git commit -m "Automated commit: Generated nodetool and configuration
documentation for version ${doc_version}." || log_message "INFO" "No new
changes to commit."
fi
popd > /dev/null
done
@@ -180,7 +180,7 @@ generate_site_yaml() {
fi
done
- echo "Building site.yaml"
+ log_message "INFO" "Building site.yaml"
rm -f site.yaml
python3 ./bin/site_yaml_generator.py \
-s "$(generate_json \
@@ -196,14 +196,87 @@ generate_site_yaml() {
render_site_content_to_html() {
pushd "${CASSANDRA_WEBSITE_DIR}/site-content" > /dev/null
- echo "Building the site HTML content."
+ log_message "INFO" "Building the site HTML content."
antora --generator antora-site-generator-lunr site.yaml
- echo "Rendering complete!"
+ log_message "INFO" "Rendering complete!"
popd > /dev/null
}
+
+prepare_site_html_for_publication() {
+ pushd "${CASSANDRA_WEBSITE_DIR}" > /dev/null
+
+ # copy everything to content/ directory
+ log_message "INFO" "Moving site HTML to content/"
+ mkdir -p content/doc
+ cp -r site-content/build/html/* content/
+
+ # remove hardcoded domain name, and empty domain names first before we
duplicate and documentation
+ content_files_to_change=($(grep -rl 'https://cassandra.apache.org/'
content/))
+ log_message "INFO" "Removing hardcoded domain names in
${#content_files_to_change[*]} files"
+ for content_file in
[jira] [Updated] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17490: - Status: Needs Committer (was: Review In Progress) > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517753#comment-17517753 ] Brandon Williams commented on CASSANDRA-17490: -- +1 > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17473) sstables changing in snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-17473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517742#comment-17517742
]
Elliott Sims commented on CASSANDRA-17473:
--
Commented on the thread, but also adding it here in case it's useful:
I've found that GNU tar interprets ctime changes as file changes. That
includes inode metadata changes like the hardlink count, which would be
expected to change in Cassandra if the original sstable is compacted away or if
additional overlapping snapshots are created. There's some more info in a very
old discussion here:
[https://lists.gnu.org/archive/html/bug-tar/2007-08/msg00013.html] . I ended
up working around it by using bsdtar instead, which does not interpret ctime
changes as file changes.
My guess is that it's what's happening here. Turning off compaction and not
taking any other further snapshots while the tar is running would probably also
work around it.
> sstables changing in snapshots
> --
>
> Key: CASSANDRA-17473
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17473
> Project: Cassandra
> Issue Type: Bug
>Reporter: James Brown
>Priority: Normal
>
> We use cassandra snapshots and tar to make full backups of our cassandra
> clusters. Sometimes, tar fails with a message like
> {{tar:
> data/addresses/addresses-eb0196100b7d11ec852b1541747d640a/snapshots/backup20220318183708/nb-167-big-Data.db:
> file changed as we read it}}
> This is kind of strange, since we're reading from a snapshot.
> The (very simplified) relevant snippet looks roughly like
> {code:java}
> nice nodetool "${JMX_ARGS[@]}" snapshot -t "$TAG" "${KEYSPACES[@]}"
> tar --hard-dereference -czpf data///snapshots/"$TAG"/{code}
> This happens maybe 1% of the time when taking backups.
> There are no concurrent snapshots going on, but there are concurrent
> compactions and repairs, of course. If it matters, this cluster _is_ running
> incremental repairs.
> This is on Cassandra 4.0.3.
> It seems wrong to me that an sstable could ever be written to while it's in a
> snapshot.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517740#comment-17517740 ] Jon Meredith commented on CASSANDRA-17495: -- PR looks good with a minor issue of missing the getAlterTableEnabled JMX endpoint. Will approve the change once added. > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17527) Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-17527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17527: -- Test and Documentation Plan: new unit test to detect this and trigger failure Status: Patch Available (was: In Progress) > Clients using JMX are unable to handle non-standard java types but we leak > this into our interfaces > --- > > Key: CASSANDRA-17527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17527 > Project: Cassandra > Issue Type: Bug > Components: Observability/JMX >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > > JMX clients only work if-and-only-if they have the same types defined by the > interface, so non-standard java (or javax) types should never be used; we > currently rely on humans to block this in review, which has lead to a few > interfaces exposing Cassandra types -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17495) Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns
[ https://issues.apache.org/jira/browse/CASSANDRA-17495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17495: - Reviewers: Jon Meredith Status: Review In Progress (was: Patch Available) > Add Guardrail for ALTER TABLE ADD / DROP / RENAME columns > - > > Key: CASSANDRA-17495 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17495 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > Fix For: 4.x > > > Operators should have the ability to freeze the schema of tables in place so > users can't mutate columns during various cluster operations. For an example > of some of the risks see CASSANDRA-13004. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17527) Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces
[ https://issues.apache.org/jira/browse/CASSANDRA-17527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Capwell updated CASSANDRA-17527: -- Bug Category: Parent values: Correctness(12982)Level 1 values: API / Semantic Definition(13162) Complexity: Low Hanging Fruit Discovered By: Workload Replay Fix Version/s: 4.1 Severity: Normal Status: Open (was: Triage Needed) Marking as fix of 4.1 to note that this has block the release, as several APIs were added to trunk only > Clients using JMX are unable to handle non-standard java types but we leak > this into our interfaces > --- > > Key: CASSANDRA-17527 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17527 > Project: Cassandra > Issue Type: Bug > Components: Observability/JMX >Reporter: David Capwell >Assignee: David Capwell >Priority: Normal > Fix For: 4.1 > > > JMX clients only work if-and-only-if they have the same types defined by the > interface, so non-standard java (or javax) types should never be used; we > currently rely on humans to block this in review, which has lead to a few > interfaces exposing Cassandra types -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17527) Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces
David Capwell created CASSANDRA-17527: - Summary: Clients using JMX are unable to handle non-standard java types but we leak this into our interfaces Key: CASSANDRA-17527 URL: https://issues.apache.org/jira/browse/CASSANDRA-17527 Project: Cassandra Issue Type: Bug Components: Observability/JMX Reporter: David Capwell Assignee: David Capwell JMX clients only work if-and-only-if they have the same types defined by the interface, so non-standard java (or javax) types should never be used; we currently rely on humans to block this in review, which has lead to a few interfaces exposing Cassandra types -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17526) BLOG - ApacheCon NA 2022 Call For Papers
[ https://issues.apache.org/jira/browse/CASSANDRA-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17526: -- Change Category: Semantic Complexity: Normal Component/s: Documentation/Blog Reviewers: Erick Ramirez Status: Open (was: Triage Needed) > BLOG - ApacheCon NA 2022 Call For Papers > > > Key: CASSANDRA-17526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17526 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > > Publish blog post – [CFP Open for ApacheCon NA > 2022|https://docs.google.com/document/d/1Mrdk4q70dzC0KBpG4th9DT3j0tP5L3zQPjFCLVOgzRc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17526) BLOG - ApacheCon NA 2022 Call For Papers
[ https://issues.apache.org/jira/browse/CASSANDRA-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Ramirez updated CASSANDRA-17526: -- Authors: Patrick McFadin (was: Erick Ramirez) > BLOG - ApacheCon NA 2022 Call For Papers > > > Key: CASSANDRA-17526 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17526 > Project: Cassandra > Issue Type: Task >Reporter: Erick Ramirez >Assignee: Erick Ramirez >Priority: Normal > > Publish blog post – [CFP Open for ApacheCon NA > 2022|https://docs.google.com/document/d/1Mrdk4q70dzC0KBpG4th9DT3j0tP5L3zQPjFCLVOgzRc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17526) BLOG - ApacheCon NA 2022 Call For Papers
Erick Ramirez created CASSANDRA-17526: - Summary: BLOG - ApacheCon NA 2022 Call For Papers Key: CASSANDRA-17526 URL: https://issues.apache.org/jira/browse/CASSANDRA-17526 Project: Cassandra Issue Type: Task Reporter: Erick Ramirez Assignee: Erick Ramirez Publish blog post – [CFP Open for ApacheCon NA 2022|https://docs.google.com/document/d/1Mrdk4q70dzC0KBpG4th9DT3j0tP5L3zQPjFCLVOgzRc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17365:
--
Status: Patch Available (was: In Progress)
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17365:
--
Reviewers: Stefan Miklosovic
Status: Review In Progress (was: Patch Available)
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Miklosovic updated CASSANDRA-17365:
--
Status: In Progress (was: Patch Available)
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517700#comment-17517700
]
Stefan Miklosovic commented on CASSANDRA-17365:
---
I am running the build here (1) and here (2) for this (3)
(1)
https://app.circleci.com/pipelines/github/instaclustr/cassandra/901/workflows/71c44e48-c4a3-42fb-8ee4-fe5348c12eab
(2) https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/1571/
(3) https://github.com/instaclustr/cassandra/tree/CASSANDRA-17365
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517696#comment-17517696
]
Jon Meredith commented on CASSANDRA-17366:
--
I've been hitting this today while working on a different issue with the in-jvm
BootstrapTest failing on cluster close (CASSANDRA-17524). I can hit it on my
MacBook after many runs and have instrumented the MigrationCoordinator with a
bit more debug output. Will report back what I find.
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17525) Local host-id may not be set when replaying commit log
[ https://issues.apache.org/jira/browse/CASSANDRA-17525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-17525: - Bug Category: Parent values: Correctness(12982)Level 1 values: Recoverable Corruption / Loss(12986) Complexity: Normal Discovered By: DTest Fix Version/s: 4.1 4.0.x Severity: Low Status: Open (was: Triage Needed) > Local host-id may not be set when replaying commit log > -- > > Key: CASSANDRA-17525 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17525 > Project: Cassandra > Issue Type: Bug > Components: Local/Commit Log >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.1, 4.0.x > > > The local host id is now used when replaying commit logs to prevent data loss > when moving SSTables between nodes (CASSANDRA-16619). > The local host-id is assigned once on initial startup and persisted to the > local.local table for use on subsequent startups - however it remains in the > memtable/commitlog until the local table is eventually flushed. > If the node dies for any reason before the flush takes place, on the next > restart a new host id will be allocated before the commit log is replayed and > any sstables appearing in the commit log will be skipped incorrectly. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17525) Local host-id may not be set when replaying commit log
Jon Meredith created CASSANDRA-17525: Summary: Local host-id may not be set when replaying commit log Key: CASSANDRA-17525 URL: https://issues.apache.org/jira/browse/CASSANDRA-17525 Project: Cassandra Issue Type: Bug Components: Local/Commit Log Reporter: Jon Meredith Assignee: Jon Meredith The local host id is now used when replaying commit logs to prevent data loss when moving SSTables between nodes (CASSANDRA-16619). The local host-id is assigned once on initial startup and persisted to the local.local table for use on subsequent startups - however it remains in the memtable/commitlog until the local table is eventually flushed. If the node dies for any reason before the flush takes place, on the next restart a new host id will be allocated before the commit log is replayed and any sstables appearing in the commit log will be skipped incorrectly. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17524) Schema mutations may not be completed on drain
[
https://issues.apache.org/jira/browse/CASSANDRA-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17524:
-
Bug Category: Parent values: Degradation(12984)Level 1 values: Other
Exception(12998)
Complexity: Normal
Discovered By: DTest
Fix Version/s: 4.1
3.0.x
3.11.x
4.0.x
Severity: Low
Status: Open (was: Triage Needed)
> Schema mutations may not be completed on drain
> --
>
> Key: CASSANDRA-17524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17524
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1, 3.0.x, 3.11.x, 4.0.x
>
>
> The drain logic (invoked explicitly with nodetool or from the JVM
> shutdown hook) closes down executor stages that can create mutations (counter,
> view, mutation) before closing down the commitlog. The gossip
> stage also commits schema mutations, and should be treated the same way.
> The messaging service is shut down as part of drain, so there should be
> no new Gossip messages received, however any messages still queued
> in the executor could still run after the commitlog allocator is shut down as
> part of drain, causing the gossip stage thread to hang indefinitely waiting
> for a new segment that never arrives.
> Here is an example from an in-JVM dtest, showing an update to the peers table
> as it shuts down.
> {code:java}
> park:-1, Unsafe (jdk.internal.misc)
> park:323, LockSupport (java.util.concurrent.locks)
> await:289, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> await:282, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:186, Awaitable$Defaults
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:259, Awaitable$AbstractAwaitable
> (org.apache.cassandra.utils.concurrent)
> awaitAvailableSegment:283, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> advanceAllocatingFrom:257, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> allocate:55, CommitLogSegmentManagerStandard
> (org.apache.cassandra.db.commitlog)
> add:282, CommitLog (org.apache.cassandra.db.commitlog)
> beginWrite:50, CassandraKeyspaceWriteHandler (org.apache.cassandra.db)
> applyInternal:622, Keyspace (org.apache.cassandra.db)
> apply:506, Keyspace (org.apache.cassandra.db)
> apply:215, Mutation (org.apache.cassandra.db)
> apply:220, Mutation (org.apache.cassandra.db)
> apply:229, Mutation (org.apache.cassandra.db)
> executeInternalWithoutCondition:644, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeLocally:635, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeInternal:431, QueryProcessor (org.apache.cassandra.cql3)
> updateTokens:804, SystemKeyspace (org.apache.cassandra.db)
> updateTokenMetadata:2941, StorageService (org.apache.cassandra.service)
> handleStateNormal:3057, StorageService (org.apache.cassandra.service)
> onChange:2498, StorageService (org.apache.cassandra.service)
> markAsShutdown:607, Gossiper (org.apache.cassandra.gms)
> doVerb:39, GossipShutdownVerbHandler (org.apache.cassandra.gms)
> lambda$new$0:78, InboundSink (org.apache.cassandra.net)
> accept:-1, 581110313 (org.apache.cassandra.net.InboundSink$$Lambda$2638)
> accept:64, InboundSink$Filtered (org.apache.cassandra.net)
> accept:50, InboundSink$Filtered (org.apache.cassandra.net)
> accept:97, InboundSink (org.apache.cassandra.net)
> accept:45, InboundSink (org.apache.cassandra.net)
> run:433, InboundMessageHandler$ProcessMessage (org.apache.cassandra.net)
> run:124, ExecutionFailure$1 (org.apache.cassandra.concurrent)
> runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
> run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
> run:829, Thread (java.lang)
> {code}
> This causes an exception during shutdown for the in-JVM dtest as it is
> unable to shutdown {{{}Stage.GOSSIP{}}}, but does not prevent regular
> shutdown for Cassandra as the executors are not stopped. The schema update
> would be lost, despite requesting a graceful shutdown.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17524) Schema mutations may not be completed on drain
[
https://issues.apache.org/jira/browse/CASSANDRA-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17524:
-
Bug Category: Parent values: Degradation(12984) (was: Parent values:
Degradation(12984)Level 1 values: Other Exception(12998))
> Schema mutations may not be completed on drain
> --
>
> Key: CASSANDRA-17524
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17524
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Jon Meredith
>Assignee: Jon Meredith
>Priority: Normal
> Fix For: 4.1, 3.0.x, 3.11.x, 4.0.x
>
>
> The drain logic (invoked explicitly with nodetool or from the JVM
> shutdown hook) closes down executor stages that can create mutations (counter,
> view, mutation) before closing down the commitlog. The gossip
> stage also commits schema mutations, and should be treated the same way.
> The messaging service is shut down as part of drain, so there should be
> no new Gossip messages received, however any messages still queued
> in the executor could still run after the commitlog allocator is shut down as
> part of drain, causing the gossip stage thread to hang indefinitely waiting
> for a new segment that never arrives.
> Here is an example from an in-JVM dtest, showing an update to the peers table
> as it shuts down.
> {code:java}
> park:-1, Unsafe (jdk.internal.misc)
> park:323, LockSupport (java.util.concurrent.locks)
> await:289, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> await:282, WaitQueue$Standard$AbstractSignal
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:186, Awaitable$Defaults
> (org.apache.cassandra.utils.concurrent)
> awaitUninterruptibly:259, Awaitable$AbstractAwaitable
> (org.apache.cassandra.utils.concurrent)
> awaitAvailableSegment:283, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> advanceAllocatingFrom:257, AbstractCommitLogSegmentManager
> (org.apache.cassandra.db.commitlog)
> allocate:55, CommitLogSegmentManagerStandard
> (org.apache.cassandra.db.commitlog)
> add:282, CommitLog (org.apache.cassandra.db.commitlog)
> beginWrite:50, CassandraKeyspaceWriteHandler (org.apache.cassandra.db)
> applyInternal:622, Keyspace (org.apache.cassandra.db)
> apply:506, Keyspace (org.apache.cassandra.db)
> apply:215, Mutation (org.apache.cassandra.db)
> apply:220, Mutation (org.apache.cassandra.db)
> apply:229, Mutation (org.apache.cassandra.db)
> executeInternalWithoutCondition:644, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeLocally:635, ModificationStatement
> (org.apache.cassandra.cql3.statements)
> executeInternal:431, QueryProcessor (org.apache.cassandra.cql3)
> updateTokens:804, SystemKeyspace (org.apache.cassandra.db)
> updateTokenMetadata:2941, StorageService (org.apache.cassandra.service)
> handleStateNormal:3057, StorageService (org.apache.cassandra.service)
> onChange:2498, StorageService (org.apache.cassandra.service)
> markAsShutdown:607, Gossiper (org.apache.cassandra.gms)
> doVerb:39, GossipShutdownVerbHandler (org.apache.cassandra.gms)
> lambda$new$0:78, InboundSink (org.apache.cassandra.net)
> accept:-1, 581110313 (org.apache.cassandra.net.InboundSink$$Lambda$2638)
> accept:64, InboundSink$Filtered (org.apache.cassandra.net)
> accept:50, InboundSink$Filtered (org.apache.cassandra.net)
> accept:97, InboundSink (org.apache.cassandra.net)
> accept:45, InboundSink (org.apache.cassandra.net)
> run:433, InboundMessageHandler$ProcessMessage (org.apache.cassandra.net)
> run:124, ExecutionFailure$1 (org.apache.cassandra.concurrent)
> runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
> run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
> run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
> run:829, Thread (java.lang)
> {code}
> This causes an exception during shutdown for the in-JVM dtest as it is
> unable to shutdown {{{}Stage.GOSSIP{}}}, but does not prevent regular
> shutdown for Cassandra as the executors are not stopped. The schema update
> would be lost, despite requesting a graceful shutdown.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17524) Schema mutations may not be completed on drain
Jon Meredith created CASSANDRA-17524:
Summary: Schema mutations may not be completed on drain
Key: CASSANDRA-17524
URL: https://issues.apache.org/jira/browse/CASSANDRA-17524
Project: Cassandra
Issue Type: Bug
Components: Local/Startup and Shutdown
Reporter: Jon Meredith
Assignee: Jon Meredith
The drain logic (invoked explicitly with nodetool or from the JVM
shutdown hook) closes down executor stages that can create mutations (counter,
view, mutation) before closing down the commitlog. The gossip
stage also commits schema mutations, and should be treated the same way.
The messaging service is shut down as part of drain, so there should be
no new Gossip messages received, however any messages still queued
in the executor could still run after the commitlog allocator is shut down as
part of drain, causing the gossip stage thread to hang indefinitely waiting
for a new segment that never arrives.
Here is an example from an in-JVM dtest, showing an update to the peers table
as it shuts down.
{code:java}
park:-1, Unsafe (jdk.internal.misc)
park:323, LockSupport (java.util.concurrent.locks)
await:289, WaitQueue$Standard$AbstractSignal
(org.apache.cassandra.utils.concurrent)
await:282, WaitQueue$Standard$AbstractSignal
(org.apache.cassandra.utils.concurrent)
awaitUninterruptibly:186, Awaitable$Defaults
(org.apache.cassandra.utils.concurrent)
awaitUninterruptibly:259, Awaitable$AbstractAwaitable
(org.apache.cassandra.utils.concurrent)
awaitAvailableSegment:283, AbstractCommitLogSegmentManager
(org.apache.cassandra.db.commitlog)
advanceAllocatingFrom:257, AbstractCommitLogSegmentManager
(org.apache.cassandra.db.commitlog)
allocate:55, CommitLogSegmentManagerStandard (org.apache.cassandra.db.commitlog)
add:282, CommitLog (org.apache.cassandra.db.commitlog)
beginWrite:50, CassandraKeyspaceWriteHandler (org.apache.cassandra.db)
applyInternal:622, Keyspace (org.apache.cassandra.db)
apply:506, Keyspace (org.apache.cassandra.db)
apply:215, Mutation (org.apache.cassandra.db)
apply:220, Mutation (org.apache.cassandra.db)
apply:229, Mutation (org.apache.cassandra.db)
executeInternalWithoutCondition:644, ModificationStatement
(org.apache.cassandra.cql3.statements)
executeLocally:635, ModificationStatement (org.apache.cassandra.cql3.statements)
executeInternal:431, QueryProcessor (org.apache.cassandra.cql3)
updateTokens:804, SystemKeyspace (org.apache.cassandra.db)
updateTokenMetadata:2941, StorageService (org.apache.cassandra.service)
handleStateNormal:3057, StorageService (org.apache.cassandra.service)
onChange:2498, StorageService (org.apache.cassandra.service)
markAsShutdown:607, Gossiper (org.apache.cassandra.gms)
doVerb:39, GossipShutdownVerbHandler (org.apache.cassandra.gms)
lambda$new$0:78, InboundSink (org.apache.cassandra.net)
accept:-1, 581110313 (org.apache.cassandra.net.InboundSink$$Lambda$2638)
accept:64, InboundSink$Filtered (org.apache.cassandra.net)
accept:50, InboundSink$Filtered (org.apache.cassandra.net)
accept:97, InboundSink (org.apache.cassandra.net)
accept:45, InboundSink (org.apache.cassandra.net)
run:433, InboundMessageHandler$ProcessMessage (org.apache.cassandra.net)
run:124, ExecutionFailure$1 (org.apache.cassandra.concurrent)
runWorker:1128, ThreadPoolExecutor (java.util.concurrent)
run:628, ThreadPoolExecutor$Worker (java.util.concurrent)
run:30, FastThreadLocalRunnable (io.netty.util.concurrent)
run:829, Thread (java.lang)
{code}
This causes an exception during shutdown for the in-JVM dtest as it is
unable to shutdown {{{}Stage.GOSSIP{}}}, but does not prevent regular
shutdown for Cassandra as the executors are not stopped. The schema update
would be lost, despite requesting a graceful shutdown.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17433: --- Description: PEP 615 – Support for the IANA Time Zone Database in the Standard Library PEP 615 (Python 3.9) has obsoleted the 3rd party library pytz with support for the Olsen tz library which previously was needed for the Olsen tz database. The code which imports this in cqlsh.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): try: import pytz ... was: PEP 615 – Support for the IANA Time Zone Database in the Standard Library PEP 615 has obsoleted the 3rd party library pytz with support for the Olsen tz library which previously was needed for the Olsen tz database. The code which imports this in cqlsh.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): try: import pytz ... > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task >Reporter: Brad Schoening >Priority: Normal > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > PEP 615 (Python 3.9) has obsoleted the 3rd party library pytz with support > for the Olsen tz library which previously was needed for the Olsen tz > database. The code which imports this in cqlsh.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with: > if sys.version_info < (3,9): > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17523) Reduce histogram snapshot long[] allocation overhead during speculative read and write threshold updates
[
https://issues.apache.org/jira/browse/CASSANDRA-17523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17523:
Test and Documentation Plan: added to existing
{{DecayingEstimatedHistogramReservoirTest}} suite to cover new snapshot type
Status: Patch Available (was: Open)
Pushed a patch that addressed the two points in the description. I didn't
attempt to avoid array copying altogether, but those allocations should now be
cut in half for threshold updates without degrading the accuracy of the
snapshot (and cut to zero when we aren't even using the percentile or hybrid
policies).
|trunk|
|[patch|https://github.com/apache/cassandra/pull/1551]|
|[CircleCI|https://app.circleci.com/pipelines/github/maedhroz/cassandra?branch=CASSANDRA-17523-trunk=all]|
> Reduce histogram snapshot long[] allocation overhead during speculative read
> and write threshold updates
>
>
> Key: CASSANDRA-17523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17523
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> Every 5 seconds with the default {{read_request_timeout}} (or in the old
> naming scheme {{{}read_request_timeout_in_ms{}}}), a scheduled task updates
> the speculation thresholds (for reads and writes) for all active tables.
> However, there are a few issues with the way we do this:
>
> 1.) Whether or not the {{SpeculativeRetryPolicy}} implementations in use
> actually looks at them, we create latency histogram snapshots to pass to
> {{{}calculateThreshold(){}}}. We could trivially avoid this by having the
> method take an argument of type {{Sampling}} and build the snapshot only when
> necessary.
>
> 2.) The only reason we build the histogram snapshot is to find the new
> threshold value for the percentile based policies.
> {{EstimatedHistogramReservoirSnapshot}} creates copies of both the decaying
> and non-decaying buckets, but we don’t use the non-decaying values at all for
> percentile calculation. Just avoiding the non-decaying values array creation
> would cut allocations in half.
>
> Given even our snapshots aren’t perfectly consistent, it might also be
> possible to calculate a percentile value directly from the reservoir’s
> decaying buckets, although that might be less accurate, as new values could
> be added to the buckets after a count is calculated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17490: - Reviewers: Brandon Williams Status: Review In Progress (was: Patch Available) > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517688#comment-17517688 ] Brandon Williams commented on CASSANDRA-17490: -- [Branch|https://github.com/driftx/cassandra/tree/CASSANDRA-17490], circle: [j8|https://app.circleci.com/pipelines/github/driftx/cassandra/431/workflows/4b62781b-0994-4f18-b37f-600d7e2d938a], [j11|https://app.circleci.com/pipelines/github/driftx/cassandra/431/workflows/5f89f5a5-1c2d-4011-992f-a57aa925243c]. > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17490: --- Test and Documentation Plan: grep showed the functions were not used pytest runs successfully Status: Patch Available (was: Open) > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17490: --- Change Category: Code Clarity Complexity: Low Hanging Fruit Component/s: CQL/Interpreter Fix Version/s: 4.1 Status: Open (was: Triage Needed) > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17433) Revise use of pytz in Python >= 3.9
[ https://issues.apache.org/jira/browse/CASSANDRA-17433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening updated CASSANDRA-17433: --- Description: PEP 615 – Support for the IANA Time Zone Database in the Standard Library PEP 615 has obsoleted the 3rd party library pytz with support for the Olsen tz library which previously was needed for the Olsen tz database. The code which imports this in cqlsh.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): try: import pytz ... was: PEP 615 – Support for the IANA Time Zone Database in the Standard Library PEP 615 has obsoleted the 3rd party library pytz with support for the Olsen tz library which previously was needed for the Olsen tz database. The code which imports this in cqlsh.py and tests in [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] should be updated accordingly. This can be done with: if sys.version_info < (3,9): import pytz > Revise use of pytz in Python >= 3.9 > > > Key: CASSANDRA-17433 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17433 > Project: Cassandra > Issue Type: Task >Reporter: Brad Schoening >Priority: Normal > > PEP 615 – Support for the IANA Time Zone Database in the Standard Library > PEP 615 has obsoleted the 3rd party library pytz with support for the Olsen > tz library which previously was needed for the Olsen tz database. The code > which imports this in cqlsh.py and tests in > [test_cqlsh_output.py|https://github.com/apache/cassandra/pull/1493/files/9c658a20c669d11a54ecc6b42ba083da13de0103#diff-f5a3955faadf50a1292df481044b83cefc44b2dac46676022c80bad076491a50] > should be updated accordingly. > This can be done with: > if sys.version_info < (3,9): > try: > import pytz > ... -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17498) Add Guardrail to disallow creation of secondary indexes
[ https://issues.apache.org/jira/browse/CASSANDRA-17498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517649#comment-17517649 ] Chris Lohfink commented on CASSANDRA-17498: --- I like the experience of disabling it like that as well, and it is very little overhead as you say. Im +1 to having as an additional option for clarity > Add Guardrail to disallow creation of secondary indexes > --- > > Key: CASSANDRA-17498 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17498 > Project: Cassandra > Issue Type: New Feature > Components: Feature/Guardrails >Reporter: Josh McKenzie >Assignee: Josh McKenzie >Priority: Normal > > Rather than just a min/max on secondary indexes, we should also have the > ability to completely enable or disable creation of secondary indexes via > guardrails. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517643#comment-17517643 ] Brad Schoening edited comment on CASSANDRA-17450 at 4/5/22 6:44 PM: [~Bowen Song] that would seem just a risky loophole around the Python Foundation's planned EOL. Brandon's link shows the final bug fix release of 3.6.x on 7/2020 with no updates since. I'd suggest this be considered for 4.2. was (Author: bschoeni): [~Bowen Song] that would seem just a risky loophole around the Python Foundation's planned EOL. Brandon's link shows the final bug fix release of 3.6.x on 7/2020 with no updates since. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517643#comment-17517643 ] Brad Schoening commented on CASSANDRA-17450: [~Bowen Song] that would seem just a risky loophole around the Python Foundation's planned EOL. Brandon's link shows the final bug fix release of 3.6.x on 7/2020 with no updates since. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17349: - Test and Documentation Plan: Run CI Status: Patch Available (was: Open) > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17328: - Test and Documentation Plan: Run CI Status: Patch Available (was: Open) > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517630#comment-17517630
]
Stefan Miklosovic commented on CASSANDRA-17365:
---
I think it should be documented somewhere here (1) already but it is not there
yet and we are removing it but still, I would put there the version saying it
will be autonegotiated.
There is also doc/modules/cassandra/pages/tools/cqlsh.adoc but there is only
the reference to that cqlshrc sample hence I think covering it in cqlshrc
template would be enough.
You know what, just be sure the patch is working and done as agreed and I ll
take care of the rest, no worries. Just let me know. Thank you.
(1) https://github.com/apache/cassandra/blob/trunk/conf/cqlshrc.sample#L103-L113
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16916) Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
[
https://issues.apache.org/jira/browse/CASSANDRA-16916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517615#comment-17517615
]
Jogesh Anand commented on CASSANDRA-16916:
--
Hurrah! thanks a lot [~bereng] . Glad we landed this in trunk. #elated
> Add support for IF EXISTS and IF NOT EXISTS in ALTER statements
> ---
>
> Key: CASSANDRA-16916
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16916
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Jogesh Anand
>Priority: Normal
> Fix For: 4.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> It would make sense to add support for {{IF EXISTS}} and {{IF NOT EXISTS}} in
> the different {{ALTER}} statements.
> For example:
> * {{ALTER TABLE IF EXISTS myTable ...}}
> * {{ALTER TABLE myTable ADD IF NOT EXISTS ...}}
> * {{ALTER TABLE myTable DROP IF EXISTS ...}}
> * {{ALTER TYPE IF EXISTS myType ...}}
> * {{ALTER TYPE myType ADD IF NOT EXISTS ...}}
> +Additional info for newcomers:+
> In order to implement this change you will need to change the {{Parser.g}}
> ANTLR file located in the src/antlr directory and the java classes
> corresponding to the different alter statements located in the
> {{org.apache.cassandra.cql3.statements.schema}} package. You can look at the
> CreateTableStatement class to see how it was done there.
> The unit test for the CQL logic are located under
> {{org.apache.cassandra.cql3.validation}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brad Schoening reassigned CASSANDRA-17450: -- Assignee: (was: Brad Schoening) > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17310:
Fix Version/s: 4.x
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
>
>
> Key: CASSANDRA-17310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
> Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
> Error Message
> Unexpected error while reading in case write-read consistency ONE-ALL with
> upgraded coordinator and 2 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517582#comment-17517582
]
Ekaterina Dimitrova commented on CASSANDRA-17310:
-
Seen three times these days according to butler on trunk so I guess it deserved
not to be in triage :)
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
>
>
> Key: CASSANDRA-17310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
> Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
> Error Message
> Unexpected error while reading in case write-read consistency ONE-ALL with
> upgraded coordinator and 2 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17310) Test Failure: org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
[
https://issues.apache.org/jira/browse/CASSANDRA-17310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17310:
Bug Category: Parent values: Correctness(12982)Level 1 values: Test
Failure(12990)
Complexity: Normal
Discovered By: User Report
Severity: Normal
Status: Open (was: Triage Needed)
> Test Failure:
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability
>
>
> Key: CASSANDRA-17310
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17310
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Josh McKenzie
>Priority: Normal
>
> https://ci-cassandra.apache.org/job/Cassandra-4.0/312/testReport/org.apache.cassandra.distributed.upgrade/MixedModeAvailabilityV3XTest/testAvailability/
> Failed 1 times in the last 5 runs. Flakiness: 25%, Stability: 80%
> Error Message
> Unexpected error while reading in case write-read consistency ONE-ALL with
> upgraded coordinator and 2 nodes down
> {code}
> Stacktrace
> junit.framework.AssertionFailedError: Unexpected error while reading in case
> write-read consistency ONE-ALL with upgraded coordinator and 2 nodes down
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:142)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.lambda$testAvailability$2(MixedModeAvailabilityTestBase.java:91)
> at
> org.apache.cassandra.distributed.upgrade.UpgradeTestBase$TestCase.run(UpgradeTestBase.java:231)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:93)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:61)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase.testAvailability(MixedModeAvailabilityTestBase.java:56)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityV3XTest.testAvailability(MixedModeAvailabilityV3XTest.java:33)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.maybeFail(MixedModeAvailabilityTestBase.java:166)
> at
> org.apache.cassandra.distributed.upgrade.MixedModeAvailabilityTestBase$Tester.test(MixedModeAvailabilityTestBase.java:134)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17431) Move the rest of the Config parameters to the new Config framework
[ https://issues.apache.org/jira/browse/CASSANDRA-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517580#comment-17517580 ] Ekaterina Dimitrova commented on CASSANDRA-17431: - Thanks, if there are no concerns on the mailing list, I will continue with the plan we agreed on there. I will also run last CI with ccm retagged in my branch, to ensure there is no new funny surprise to deal with later :) > Move the rest of the Config parameters to the new Config framework > -- > > Key: CASSANDRA-17431 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17431 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > Migrate also all Config parameters that are in Config, but not presented in > cassandra.yaml to the new config framework. Not presented in the yaml as they > are considered advanced only for advanced users. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17221) Add Math functions
[
https://issues.apache.org/jira/browse/CASSANDRA-17221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517577#comment-17517577
]
Ekaterina Dimitrova commented on CASSANDRA-17221:
-
Hey [~xvade], thank you for all your work! I will get back to this today or
tomorrow.
Just wanted quickly to respond to your question around docs. I think you meant
operators.adoc? rst is the old format, we migrated to adoc already.
I don't think there is specific rule, it is more about - adding clear docs in
line with the rest, easy to find and comprehend for our users.
I guess either the page you pointed to can be updated or a new one to be
created. I am personally neutral I think.
> Add Math functions
> ---
>
> Key: CASSANDRA-17221
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17221
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Syntax
>Reporter: Benjamin Lerer
>Assignee: Simon Chess
>Priority: Normal
> Labels: AdventCalendar2021, lhf
> Fix For: 4.x
>
>
> We should add native Maths functions for the most common operations:
> * {{abs\(x)}} returns the absolute value of the x
> * {{exp\(x)}} returns the value of e (the base of natural logarithms) raised
> to the power of x
> * {{log\(x)}} returns the natural logarithm (base e) of x
> * {{log10\(x)}} returns the base-10 logarithm of x
> * {{round\(x)}} returns the closest integer to x
> +Additional information for newcomers:+
> The new functions should be put in a new class {{MathFcts}} similar to
> {{TimeFcts}}.
> The {{MathsFcts.all()}} method should be called in
> {{SystemKeyspace.functions}}
> The unit tests for the functions should be put in a {{MathFctsTest}} similar
> to {{TimeFctsTest}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517559#comment-17517559
]
Ekaterina Dimitrova commented on CASSANDRA-17366:
-
Thanks for checking back for when it was committed. Our jobs to run in a loop
the tests were added after that time, this bisect just shows me one more time
how useful and important is for us to be running new tests in a loop before
commit. I am glad they were added.
So on commit and now it was failing with the same frequency, right? But I saw
you ran it only with 4.0 to confirm that.
I just ran it with the same circle config with trunk
[here|https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/1499/workflows/2b7e411a-78a2-44f8-9d2c-c6b645df953c/jobs/9754/parallel-runs/2?filterBy=ALL]
It hasn't finished yet, there are 3 failures... if there are more maybe we need
to investigate what made it fail more often? WDYT?
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
[jira] [Updated] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
[ https://issues.apache.org/jira/browse/CASSANDRA-17521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diogenese Topper updated CASSANDRA-17521: - Authors: Chris Thornett Change Category: Semantic Complexity: Normal Fix Version/s: NA Impacts: Docs (was: None) Test and Documentation Plan: * Add blog post titled "Apache Cassandra Changelog #14" * Modify blog index page * Add image for blog: "changelog-14-bloomberg-opensource.png" > WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" > -- > > Key: CASSANDRA-17521 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 > Project: Cassandra > Issue Type: Task > Components: Documentation/Blog >Reporter: Diogenese Topper >Priority: Normal > Fix For: NA > > > This ticket is to capture the work associated with publishing the April 2022 > blog "Apache Cassandra Changelog #14" > If this blog cannot be published by the *April 7, 2022 publish date*, please > contact me, suggest changes, or correct the date when possible in the pull > request for the appropriate time that the blog will go live (on both the > blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517530#comment-17517530 ] Brandon Williams edited comment on CASSANDRA-17328 at 4/5/22 4:26 PM: -- [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/430/workflows/63ecee4e-93ab-4dd1-9455-8cd2d983a6bd/jobs/5015] is a repeated run of this test against the same branch as CASSANDRA-17349 since it should fix this issue as well. was (Author: brandon.williams): [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/429/workflows/d39dfacd-67c5-4d62-9f9b-7b16e6cf3609/jobs/5011] is a repeated run of this test against the same branch as CASSANDRA-17349 since it should fix this issue as well. > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17523) Reduce histogram snapshot long[] allocation overhead during speculative read and write threshold updates
[
https://issues.apache.org/jira/browse/CASSANDRA-17523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17523:
Change Category: Performance
Complexity: Normal
Component/s: Consistency/Coordination
Observability/Metrics
Status: Open (was: Triage Needed)
> Reduce histogram snapshot long[] allocation overhead during speculative read
> and write threshold updates
>
>
> Key: CASSANDRA-17523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17523
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
>
> Every 5 seconds with the default {{read_request_timeout}} (or in the old
> naming scheme {{{}read_request_timeout_in_ms{}}}), a scheduled task updates
> the speculation thresholds (for reads and writes) for all active tables.
> However, there are a few issues with the way we do this:
>
> 1.) Whether or not the {{SpeculativeRetryPolicy}} implementations in use
> actually looks at them, we create latency histogram snapshots to pass to
> {{{}calculateThreshold(){}}}. We could trivially avoid this by having the
> method take an argument of type {{Sampling}} and build the snapshot only when
> necessary.
>
> 2.) The only reason we build the histogram snapshot is to find the new
> threshold value for the percentile based policies.
> {{EstimatedHistogramReservoirSnapshot}} creates copies of both the decaying
> and non-decaying buckets, but we don’t use the non-decaying values at all for
> percentile calculation. Just avoiding the non-decaying values array creation
> would cut allocations in half.
>
> Given even our snapshots aren’t perfectly consistent, it might also be
> possible to calculate a percentile value directly from the reservoir’s
> decaying buckets, although that might be less accurate, as new values could
> be added to the buckets after a count is calculated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17523) Reduce histogram snapshot long[] allocation overhead during speculative read and write threshold updates
[
https://issues.apache.org/jira/browse/CASSANDRA-17523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-17523:
Fix Version/s: 4.x
> Reduce histogram snapshot long[] allocation overhead during speculative read
> and write threshold updates
>
>
> Key: CASSANDRA-17523
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17523
> Project: Cassandra
> Issue Type: Improvement
> Components: Consistency/Coordination, Observability/Metrics
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.x
>
>
> Every 5 seconds with the default {{read_request_timeout}} (or in the old
> naming scheme {{{}read_request_timeout_in_ms{}}}), a scheduled task updates
> the speculation thresholds (for reads and writes) for all active tables.
> However, there are a few issues with the way we do this:
>
> 1.) Whether or not the {{SpeculativeRetryPolicy}} implementations in use
> actually looks at them, we create latency histogram snapshots to pass to
> {{{}calculateThreshold(){}}}. We could trivially avoid this by having the
> method take an argument of type {{Sampling}} and build the snapshot only when
> necessary.
>
> 2.) The only reason we build the histogram snapshot is to find the new
> threshold value for the percentile based policies.
> {{EstimatedHistogramReservoirSnapshot}} creates copies of both the decaying
> and non-decaying buckets, but we don’t use the non-decaying values at all for
> percentile calculation. Just avoiding the non-decaying values array creation
> would cut allocations in half.
>
> Given even our snapshots aren’t perfectly consistent, it might also be
> possible to calculate a percentile value directly from the reservoir’s
> decaying buckets, although that might be less accurate, as new values could
> be added to the buckets after a count is calculated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17523) Reduce histogram snapshot long[] allocation overhead during speculative read and write threshold updates
Caleb Rackliffe created CASSANDRA-17523:
---
Summary: Reduce histogram snapshot long[] allocation overhead
during speculative read and write threshold updates
Key: CASSANDRA-17523
URL: https://issues.apache.org/jira/browse/CASSANDRA-17523
Project: Cassandra
Issue Type: Improvement
Reporter: Caleb Rackliffe
Assignee: Caleb Rackliffe
Every 5 seconds with the default {{read_request_timeout}} (or in the old naming
scheme {{{}read_request_timeout_in_ms{}}}), a scheduled task updates the
speculation thresholds (for reads and writes) for all active tables. However,
there are a few issues with the way we do this:
1.) Whether or not the {{SpeculativeRetryPolicy}} implementations in use
actually looks at them, we create latency histogram snapshots to pass to
{{{}calculateThreshold(){}}}. We could trivially avoid this by having the
method take an argument of type {{Sampling}} and build the snapshot only when
necessary.
2.) The only reason we build the histogram snapshot is to find the new
threshold value for the percentile based policies.
{{EstimatedHistogramReservoirSnapshot}} creates copies of both the decaying and
non-decaying buckets, but we don’t use the non-decaying values at all for
percentile calculation. Just avoiding the non-decaying values array creation
would cut allocations in half.
Given even our snapshots aren’t perfectly consistent, it might also be possible
to calculate a percentile value directly from the reservoir’s decaying buckets,
although that might be less accurate, as new values could be added to the
buckets after a count is calculated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17522) Add guardrail to disallow creation of new COMPACT STORAGE tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17522:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Add guardrail to disallow creation of new COMPACT STORAGE tables
>
>
> Key: CASSANDRA-17522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17522
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While we have the ability to toggle whether we allow the {{DROP COMPACT
> STORAGE}} operation, we don't have a way system-wide to disable _creation_ of
> new COMPACT STORAGE tables.
> A guardrail for this would be nice.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17522) Add guardrail to disallow creation of new COMPACT STORAGE tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17522:
--
Test and Documentation Plan: New unit testing of guardrail
Status: Patch Available (was: Open)
> Add guardrail to disallow creation of new COMPACT STORAGE tables
>
>
> Key: CASSANDRA-17522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17522
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While we have the ability to toggle whether we allow the {{DROP COMPACT
> STORAGE}} operation, we don't have a way system-wide to disable _creation_ of
> new COMPACT STORAGE tables.
> A guardrail for this would be nice.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17522) Add guardrail to disallow creation of new COMPACT STORAGE tables
[
https://issues.apache.org/jira/browse/CASSANDRA-17522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517533#comment-17517533
]
Josh McKenzie commented on CASSANDRA-17522:
---
[branch|https://github.com/apache/cassandra/compare/trunk...josh-mckenzie:cassandra-17522?expand=1]
[JDK8
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/201/workflows/58d11071-2730-47cb-a43d-d9db7ac0ac4d]
[JDK11
CI|https://app.circleci.com/pipelines/github/josh-mckenzie/cassandra/201/workflows/501aa85a-b69a-4cb8-8b22-a6e4a5830f0c]
> Add guardrail to disallow creation of new COMPACT STORAGE tables
>
>
> Key: CASSANDRA-17522
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17522
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Josh McKenzie
>Assignee: Josh McKenzie
>Priority: Normal
>
> While we have the ability to toggle whether we allow the {{DROP COMPACT
> STORAGE}} operation, we don't have a way system-wide to disable _creation_ of
> new COMPACT STORAGE tables.
> A guardrail for this would be nice.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17328) Fix flaky test - dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517530#comment-17517530 ] Brandon Williams commented on CASSANDRA-17328: -- [Here|https://app.circleci.com/pipelines/github/driftx/cassandra/429/workflows/d39dfacd-67c5-4d62-9f9b-7b16e6cf3609/jobs/5011] is a repeated run of this test against the same branch as CASSANDRA-17349 since it should fix this issue as well. > Fix flaky test - > dtest.repair_tests.repair_test.TestRepair.test_dc_parallel_repair > -- > > Key: CASSANDRA-17328 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17328 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 4 times in the last 26 runs. Flakiness: 28%, Stability: 84% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17522) Add guardrail to disallow creation of new COMPACT STORAGE tables
Josh McKenzie created CASSANDRA-17522:
-
Summary: Add guardrail to disallow creation of new COMPACT STORAGE
tables
Key: CASSANDRA-17522
URL: https://issues.apache.org/jira/browse/CASSANDRA-17522
Project: Cassandra
Issue Type: New Feature
Components: Feature/Guardrails
Reporter: Josh McKenzie
Assignee: Josh McKenzie
While we have the ability to toggle whether we allow the {{DROP COMPACT
STORAGE}} operation, we don't have a way system-wide to disable _creation_ of
new COMPACT STORAGE tables.
A guardrail for this would be nice.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517520#comment-17517520 ] Bowen Song commented on CASSANDRA-17450: [~bschoeni] For CentOS 7 lifecycle information, please see [https://wiki.centos.org/About/Product] CentOS (in fact, RedHat) will continuously provide critical and important security updates, even after upstream has ended their support for a particular old version. See https://access.redhat.com/support/policy/updates/errata/ > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17349) Fix flaky test - dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair
[ https://issues.apache.org/jira/browse/CASSANDRA-17349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517518#comment-17517518 ] Brandon Williams commented on CASSANDRA-17349: -- Looks like this fell off butler, but we know from CASSANDRA-17140 that this is caused by the USE statement, so I removed it [here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17349], and [here's a repeated run|https://app.circleci.com/pipelines/github/driftx/cassandra/428/workflows/e0369658-6263-4321-ba8b-bc432c5b9460/jobs/5009]. > Fix flaky test - > dtest-novnode.repair_tests.repair_test.TestRepair.test_simple_sequential_repair > > > Key: CASSANDRA-17349 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17349 > Project: Cassandra > Issue Type: Bug > Components: Consistency/Repair >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x > > > Failed 2 times in the last 9 runs. Flakiness: 37%, Stability: 77% > Error Message > cassandra.DriverException: ID mismatch while trying to reprepare (expected > b'ba2c66a4f13080265ea718e037637d4a', got > b'52faf62235132756a26828817a81168d'). This prepared statement won't work > anymore. This usually happens when you run a 'USE...' query after the > statement was prepared. > Stacktrace > self = > def test_simple_sequential_repair(self): > """ > Calls simple repair test with a sequential repair > """ > > self._simple_repair(sequential=True) > repair_tests/repair_test.py:363: -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
miklosovic updated CASSANDRA-17365:
---
Attachment: signature.asc
Let me see, I will be on it in couple hours.
Sent from ProtonMail mobile
\
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
> Attachments: signature.asc
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17521) WEBSITE - April 2022 blog "Apache Cassandra Changelog #14"
Diogenese Topper created CASSANDRA-17521: Summary: WEBSITE - April 2022 blog "Apache Cassandra Changelog #14" Key: CASSANDRA-17521 URL: https://issues.apache.org/jira/browse/CASSANDRA-17521 Project: Cassandra Issue Type: Task Components: Documentation/Blog Reporter: Diogenese Topper This ticket is to capture the work associated with publishing the April 2022 blog "Apache Cassandra Changelog #14" If this blog cannot be published by the *April 7, 2022 publish date*, please contact me, suggest changes, or correct the date when possible in the pull request for the appropriate time that the blog will go live (on both the blog.adoc and the blog post's file). -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ekaterina Dimitrova updated CASSANDRA-17366:
Reviewers: Ekaterina Dimitrova, Ekaterina Dimitrova
Ekaterina Dimitrova, Ekaterina Dimitrova (was: Ekaterina
Dimitrova)
Status: Review In Progress (was: Patch Available)
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517498#comment-17517498
]
Brad Schoening commented on CASSANDRA-17365:
[~smiklosovic] what documentation needs updating? I wasn't able to find it
either of the README.asc files.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516771#comment-17516771
]
Brandon Williams edited comment on CASSANDRA-17366 at 4/5/22 3:05 PM:
--
-What I know so far is that these were not flaky on commit, as they pass fine
there but later on begin failing. Locating that exact point is an ongoing
bisect.-
That is not true, this is actually just more difficult to bisect than I
originally gauged.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/424/workflows/3ce471bc-244d-486e-aa62-cca36e85517b/jobs/4996/tests#failed-test-0]
is a circle run near the time these tests were committed illustrating the
failure.
was (Author: brandon.williams):
-What I know so far is that these were not flaky on commit, as they pass fine
there but later on begin failing. Locating that exact point is an ongoing
bisect.-
That is not true, this is actually just more difficult to bisect that I
originally gauged.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/424/workflows/3ce471bc-244d-486e-aa62-cca36e85517b/jobs/4996/tests#failed-test-0]
is a circle run near the time these tests were committed illustrating the
failure.
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
>
[jira] [Updated] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-17366:
-
Test and Documentation Plan: Run test repeatedly in circle
Status: Patch Available (was: Open)
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517494#comment-17517494
]
Brandon Williams commented on CASSANDRA-17366:
--
Confirming that is
[this|https://app.circleci.com/pipelines/github/driftx/cassandra/425/workflows/d4949949-441a-47b4-b97d-12fba3574c98/jobs/5003/tests#failed-test-0]
failure on 4.0 also.
I've added a longer wait for nodes to come up
[here|https://github.com/driftx/cassandra-dtest/tree/CASSANDRA-17366] and also
raise an error when we exhaust the time without all the nodes returning.
Repeated runs against it:
[4.0|https://app.circleci.com/pipelines/github/driftx/cassandra/427/workflows/d994077f-ec7e-424e-b7f4-cb8ef2649a0c/jobs/5006]
,
[trunk|https://app.circleci.com/pipelines/github/driftx/cassandra/426/workflows/937969fa-605c-4970-b3d9-4913e935d075/jobs/5007]
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517484#comment-17517484 ] Stefan Miklosovic commented on CASSANDRA-17450: --- I think it is not "too hot". I mean, sure, it is a problem. But this is a problem of a user who is using Python 3.6 instead of something more recent? I am not too strong in Python but as I get it, if a user runs whatever else but 3.6 (like 3.7, 3.8 and so on), he is "fine", is not he? It is more about us not closing the gap so he can run with 3.6 but it does not mean he _has to_. Or I am missing something completely? > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517485#comment-17517485 ] Brandon Williams commented on CASSANDRA-17450: -- https://centos.pkgs.org/7/centos-updates-x86_64/python3-3.6.8-18.el7.x86_64.rpm.html looks like the latest python3 available. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517464#comment-17517464
]
Alex Petrov commented on CASSANDRA-17140:
-
Glad this helped. Thank you very much for looking into it and sorry we didn't
catch this during the review/test run.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17140) Broken test_rolling_upgrade - upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
[
https://issues.apache.org/jira/browse/CASSANDRA-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516741#comment-17516741
]
Alex Petrov edited comment on CASSANDRA-17140 at 4/5/22 2:11 PM:
-
We did mixed-mode testing, but could not commit the mixed mode test because the
version of driver we have in-tree does not support binding to a specific node
via setting host in statement. This testing has shown no persistent errors.
What you're showing is a transient exception. When the driver get updated, we
can run test again. For now, I'm fairly confident in this patch. If you want to
dig deeper - please feel free.
I personally think python upgrade dtests should go away and it's best to spend
time migrating them than fixing them.
UPDATE: inserted missing [s] letters
was (Author: ifesdjeen):
We did mixed-mode testing, but could not commit the mixed mode test because the
version of driver we have in-tree does not support binding to a specific node
via setting host in statement. This testing has shown no persistent errors.
What you're howing is a tranient exception. When the driver get updated, we can
run test again. For now, I'm fairly confident in this patch. If you want to dig
deeper - please feel free.
I personally think python upgrade dtests should go away and it's best to spend
time migrating them than fixing them.
> Broken test_rolling_upgrade -
> upgrade_tests.upgrade_through_versions_test.TestUpgrade_indev_3_0_x_To_indev_4_0_x
>
>
> Key: CASSANDRA-17140
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17140
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: Yifan Cai
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0.x
>
>
> The tests "test_rolling_upgrade" fail with the below error.
>
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/279/workflows/6340cd42-0b27-42c2-8418-9f8b56c57bea/jobs/1990]
>
> I am able to alway produce it by running the test locally too.
> {{$ pytest --execute-upgrade-tests-only --upgrade-target-version-only
> --upgrade-version-selection all --cassandra-version=4.0
> upgrade_tests/upgrade_through_versions_test.py::TestUpgrade_indev_3_11_x_To_indev_4_0_x::test_rolling_upgrade}}
>
> {code:java}
> self =
> object at 0x7ffba4242fd0>
> subprocs = [,
> ]
> def _check_on_subprocs(self, subprocs):
> """
> Check on given subprocesses.
>
> If any are not alive, we'll go ahead and terminate any remaining
> alive subprocesses since this test is going to fail.
> """
> subproc_statuses = [s.is_alive() for s in subprocs]
> if not all(subproc_statuses):
> message = "A subprocess has terminated early. Subprocess
> statuses: "
> for s in subprocs:
> message += "{name} (is_alive: {aliveness}),
> ".format(name=s.name, aliveness=s.is_alive())
> message += "attempting to terminate remaining subprocesses now."
> self._terminate_subprocs()
> > raise RuntimeError(message)
> E RuntimeError: A subprocess has terminated early. Subprocess
> statuses: Process-1 (is_alive: True), Process-2 (is_alive: False), attempting
> to terminate remaining subprocesses now.{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517450#comment-17517450 ] Brad Schoening commented on CASSANDRA-17490: Yes, was just waiting for the PRs for CASSANDRA-17465 and -CASSANDRA-17480- to be resolved so I didn't have too many open issues. > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517442#comment-17517442 ] Brad Schoening edited comment on CASSANDRA-17450 at 4/5/22 1:41 PM: [~brandon.williams] [~Bowen Song] do you have a reference to that CentOS policy? That sounds super insecure if python 3.6 is no longer receiving even minimal security updates. was (Author: bschoeni): [~brandon.williams] [~Bowen Song] do you have a reference to that? That sounds super insecure if python 3.6 is no longer receiving even minimal security updates. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517442#comment-17517442 ] Brad Schoening commented on CASSANDRA-17450: [~brandon.williams] [~Bowen Song] do you have a reference to that? That sounds super insecure if python 3.6 is no longer receiving even minimal security updates. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517441#comment-17517441
]
Brad Schoening commented on CASSANDRA-17365:
[~smiklosovic] sure, I can update the docs and add a warning. I'll update the
PR.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517407#comment-17517407
]
Stefan Miklosovic edited comment on CASSANDRA-17365 at 4/5/22 12:48 PM:
[~bschoeni] would you mind to update the documentation? that version field in
[ssl] section will not exist anymore and docs need to reflect that. Tell me if
this is "too much" for you and I ll get it done.
We should also emit some warning when people are still using these properties
telling them that what they are trying to set is not relevant and it is
autonegotiated and that it will be removed in the next release completely.
(the warning).
Implementation-wise, I would leave everything as is, just that
'get_best_tls_protocol' would always return ssl.PROTOCOL_TLS and it would emit
warning that it is not supported and it will be autonegotiated when user set
something specific either as env property or field in cqlshrc.
was (Author: smiklosovic):
[~bschoeni] would you mind to update the documentation? that version field in
[ssl] section will not exist anymore and docs need to reflect that. Tell me if
this is "too much" for you and I ll get it done.
We should also emit some warning when people are still using these properties
telling them that what they are trying to set is not relevant and it is
autonegotiated and that it will be removed in the next release completely.
(the warning).
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517407#comment-17517407
]
Stefan Miklosovic edited comment on CASSANDRA-17365 at 4/5/22 12:28 PM:
[~bschoeni] would you mind to update the documentation? that version field in
[ssl] section will not exist anymore and docs need to reflect that. Tell me if
this is "too much" for you and I ll get it done.
We should also emit some warning when people are still using these properties
telling them that what they are trying to set is not relevant and it is
autonegotiated and that it will be removed in the next release completely.
(the warning).
was (Author: smiklosovic):
[~bschoeni] would you mind to update the documentation? that version field in
[ssl] section will not exist anymore and docs need to reflect that. Tell me if
this is "too much" for you and I ll get it done.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517407#comment-17517407
]
Stefan Miklosovic commented on CASSANDRA-17365:
---
[~bschoeni] would you mind to update the documentation? that version field in
[ssl] section will not exist anymore and docs need to reflect that. Tell me if
this is "too much" for you and I ll get it done.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17480) Resolve several pylint issues in cqlsh.py and pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Miklosovic updated CASSANDRA-17480: -- Fix Version/s: 4.1 (was: 4.x) Source Control Link: https://github.com/apache/cassandra/commit/f28dd90feb215db85ac2e510c5657a49edd46e12 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Resolve several pylint issues in cqlsh.py and pylib > --- > > Key: CASSANDRA-17480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17480 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.1 > > Time Spent: 6h 10m > Remaining Estimate: 0h > > Cleanup outdated code: > * resolve some pylint issues: > ** variable 'ver' used at top-level and in function arg > ** cmdloop doesn't match signature > ** change set() function call in initializer to static > ** a few other miscellaneous pylint issues -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[cassandra] branch trunk updated: resolve several pylint issues in cqlsh.py and pylib
This is an automated email from the ASF dual-hosted git repository.
smiklosovic pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new f28dd90feb resolve several pylint issues in cqlsh.py and pylib
f28dd90feb is described below
commit f28dd90feb215db85ac2e510c5657a49edd46e12
Author: Brad Schoening <5796692+bschoen...@users.noreply.github.com>
AuthorDate: Sat Mar 26 14:47:23 2022 -0400
resolve several pylint issues in cqlsh.py and pylib
patch by Brad Schoening; reviewed by Stefan Miklosovic and Brandon Williams
for CASSANDRA-17480
---
CHANGES.txt| 1 +
bin/cqlsh.py | 21 ++---
pylib/cqlshlib/copyutil.py | 4 ++--
pylib/cqlshlib/cql3handling.py | 7 ---
pylib/cqlshlib/cqlhandling.py | 19 +--
5 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/CHANGES.txt b/CHANGES.txt
index 01626ee270..a1535bc7f1 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
4.1
+ * resolve several pylint issues in cqlsh.py and pylib (CASSANDRA-17480)
* Streaming sessions longer than 3 minutes fail with timeout (CASSANDRA-17510)
* Add ability to track state in repair (CASSANDRA-15399)
* Remove unused 'parse' module (CASSANDRA-17484)
diff --git a/bin/cqlsh.py b/bin/cqlsh.py
index 481bb0bf22..5476456bb1 100755
--- a/bin/cqlsh.py
+++ b/bin/cqlsh.py
@@ -18,6 +18,7 @@
import cmd
import codecs
+import configparser
import csv
import errno
import getpass
@@ -33,6 +34,7 @@ import warnings
import webbrowser
from contextlib import contextmanager
from glob import glob
+from io import StringIO
from uuid import UUID
if sys.version_info < (3, 6):
@@ -118,9 +120,6 @@ for lib in third_parties:
if lib_zip:
sys.path.insert(0, lib_zip)
-import configparser
-from io import StringIO
-
warnings.filterwarnings("ignore", r".*blist.*")
try:
import cassandra
@@ -225,8 +224,8 @@ parser.add_option('-v', action="version", help='Print the
current version of cql
parser.add_option("--insecure-password-without-warning", action='store_true',
dest='insecure_password_without_warning',
help=optparse.SUPPRESS_HELP)
-optvalues = optparse.Values()
-(options, arguments) = parser.parse_args(sys.argv[1:], values=optvalues)
+opt_values = optparse.Values()
+(options, arguments) = parser.parse_args(sys.argv[1:], values=opt_values)
# BEGIN history/config definition
@@ -878,7 +877,7 @@ class Shell(cmd.Cmd):
return
yield newline
-def cmdloop(self):
+def cmdloop(self, intro=None):
"""
Adapted from cmd.Cmd's version, because there is literally no way with
cmd.Cmd.cmdloop() to tell the difference between "EOF" showing up in
@@ -1115,11 +1114,11 @@ class Shell(cmd.Cmd):
def print_all(result, table_meta, tty):
# Return the number of rows in total
num_rows = 0
-isFirst = True
+is_first = True
while True:
# Always print for the first page even it is empty
-if result.current_rows or isFirst:
-with_header = isFirst or tty
+if result.current_rows or is_first:
+with_header = is_first or tty
self.print_static_result(result, table_meta, with_header,
tty, num_rows)
num_rows += len(result.current_rows)
if result.has_more_pages:
@@ -1131,7 +1130,7 @@ class Shell(cmd.Cmd):
if not tty:
self.writeresult("")
break
-isFirst = False
+is_first = False
return num_rows
num_rows = print_all(result, table_meta, self.tty)
@@ -2067,7 +2066,7 @@ class SwitchCommandWithValue(SwitchCommand):
binary_switch_value = True
except (ValueError, TypeError):
value = None
-return (binary_switch_value, value)
+return binary_switch_value, value
def option_with_default(cparser_getter, section, option, default=None):
diff --git a/pylib/cqlshlib/copyutil.py b/pylib/cqlshlib/copyutil.py
index 92af3a3897..0f91b7ca53 100644
--- a/pylib/cqlshlib/copyutil.py
+++ b/pylib/cqlshlib/copyutil.py
@@ -88,7 +88,7 @@ def printmsg(msg, eol='\n', encoding='utf8'):
# Keep arguments in sync with printmsg
def swallowmsg(msg, eol='', encoding=''):
-None
+pass
class OneWayPipe(object):
@@ -288,7 +288,7 @@ class CopyTask(object):
return opts
configs = configparser.RawConfigParser()
-configs.readfp(open(config_file))
+configs.read_file(open(config_file))
ret = dict()
config_sections = list(['copy', 'copy-%s' % (direction,),
diff --git a/pylib/cqlshlib/cql3handling.py b/pylib/cqlshlib/cql3handling.py
index
[jira] [Comment Edited] (CASSANDRA-17366) Fix flaky test - gossip_test.TestGossip
[
https://issues.apache.org/jira/browse/CASSANDRA-17366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17516771#comment-17516771
]
Brandon Williams edited comment on CASSANDRA-17366 at 4/5/22 11:39 AM:
---
-What I know so far is that these were not flaky on commit, as they pass fine
there but later on begin failing. Locating that exact point is an ongoing
bisect.-
That is not true, this is actually just more difficult to bisect that I
originally gauged.
[Here|https://app.circleci.com/pipelines/github/driftx/cassandra/424/workflows/3ce471bc-244d-486e-aa62-cca36e85517b/jobs/4996/tests#failed-test-0]
is a circle run near the time these tests were committed illustrating the
failure.
was (Author: brandon.williams):
What I know so far is that these were not flaky on commit, as they pass fine
there but later on begin failing. Locating that exact point is an ongoing
bisect.
> Fix flaky test - gossip_test.TestGossip
> ---
>
> Key: CASSANDRA-17366
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17366
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Aleksei Zotov
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
>
> We can see many failures for 4.x branch:
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip,])
> test_2dc_parallel_startup
> ([929|https://ci-cassandra.apache.org/job/Cassandra-trunk/929/testReport/dtest-novnode.gossip_test/TestGossip],
>
> [931|https://ci-cassandra.apache.org/job/Cassandra-trunk/931/testReport/dtest.gossip_test/TestGossip],
>
> [936|https://ci-cassandra.apache.org/job/Cassandra-trunk/936/testReport/dtest-novnode.gossip_test/TestGossip])
> test_2dc_parallel_startup_one_seed
> ([916|https://ci-cassandra.apache.org/job/Cassandra-trunk/916/testReport/dtest-offheap.gossip_test/TestGossip],
>
> [920|https://ci-cassandra.apache.org/job/Cassandra-trunk/920/testReport/dtest.gossip_test/TestGossip/])
> The error is always the same:
> {code:java}
> Unexpected error found in node logs (see stdout for full details). Errors:
> [ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878),
> ERROR [main] 2022-01-26 10:53:12,866 CassandraDaemon.java:900 - Exception
> encountered during startup
> java.lang.RuntimeException: Didn't receive schemas for all known versions
> within the timeout. Use -Dcassandra.skip_schema_check=true to skip this check.
> at
> org.apache.cassandra.service.StorageService.waitForSchema(StorageService.java:1037)
> at
> org.apache.cassandra.dht.BootStrapper.allocateTokens(BootStrapper.java:232)
> at
> org.apache.cassandra.dht.BootStrapper.getBootstrapTokens(BootStrapper.java:180)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1089)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:1043)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:821)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:751)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:417)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:754)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:878)]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517360#comment-17517360 ] Brandon Williams edited comment on CASSANDRA-17450 at 4/5/22 11:25 AM: --- -Yes, I think it makes sense.- As [~Bowen Song] pointed out, CentOS 7 only has 3.6 until mid-2024, so keeping 3.6 support is prudent. was (Author: brandon.williams): Yes, I think it makes sense. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17516) Official Cassandra packages are missing runtime dependency procps-ng
[ https://issues.apache.org/jira/browse/CASSANDRA-17516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17516: - Test and Documentation Plan: run CI, test packages Status: Patch Available (was: Open) > Official Cassandra packages are missing runtime dependency procps-ng > > > Key: CASSANDRA-17516 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17516 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Dylan Richardson >Assignee: Brandon Williams >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x > > Attachments: patch > > > Nodetool depends on the free command-line utility, but the official Cassandra > RPM does not explicitly install it. free comes from procps-ng, so this > package should be made an explicit dependency in the RPM's spec file. > Here's what you get when invoking nodetool without free installed: > bash-5.1# nodetool status > /etc/cassandra/conf/cassandra-env.sh: line 21: free: command not found > expr: syntax error: unexpected argument '2' > expr: syntax error: unexpected argument '2' > /etc/cassandra/conf/cassandra-env.sh: line 59: [: : integer expression > expected > /etc/cassandra/conf/cassandra-env.sh: line 63: [: : integer expression > expected > /etc/cassandra/conf/cassandra-env.sh: line 67: [: : integer expression > expected > expr: syntax error: unexpected argument '4' > /etc/cassandra/conf/cassandra-env.sh: line 81: [: : integer expression > expected > I have attached a patch that should fix this issue. -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17480) Resolve several pylint issues in cqlsh.py and pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17480: - Status: Ready to Commit (was: Review In Progress) > Resolve several pylint issues in cqlsh.py and pylib > --- > > Key: CASSANDRA-17480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17480 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > Cleanup outdated code: > * resolve some pylint issues: > ** variable 'ver' used at top-level and in function arg > ** cmdloop doesn't match signature > ** change set() function call in initializer to static > ** a few other miscellaneous pylint issues -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17480) Resolve several pylint issues in cqlsh.py and pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517383#comment-17517383 ] Brandon Williams commented on CASSANDRA-17480: -- +1 > Resolve several pylint issues in cqlsh.py and pylib > --- > > Key: CASSANDRA-17480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17480 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > Cleanup outdated code: > * resolve some pylint issues: > ** variable 'ver' used at top-level and in function arg > ** cmdloop doesn't match signature > ** change set() function call in initializer to static > ** a few other miscellaneous pylint issues -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517362#comment-17517362
]
Brandon Williams commented on CASSANDRA-17365:
--
I agree this makes sense. I think upgrading is orthogonal to this and won't
really matter either way.
bq. do not we want to somehow force the tls version used?
If a user wants to do that they already can.
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517360#comment-17517360 ] Brandon Williams commented on CASSANDRA-17450: -- Yes, I think it makes sense. > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17480) Resolve several pylint issues in cqlsh.py and pylib
[ https://issues.apache.org/jira/browse/CASSANDRA-17480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17480: - Reviewers: Brandon Williams, Stefan Miklosovic (was: Stefan Miklosovic) Status: Review In Progress (was: Needs Committer) > Resolve several pylint issues in cqlsh.py and pylib > --- > > Key: CASSANDRA-17480 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17480 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > Time Spent: 6h > Remaining Estimate: 0h > > Cleanup outdated code: > * resolve some pylint issues: > ** variable 'ver' used at top-level and in function arg > ** cmdloop doesn't match signature > ** change set() function call in initializer to static > ** a few other miscellaneous pylint issues -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17365) Remove deprecated version specific TLS in CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517358#comment-17517358
]
Stefan Miklosovic commented on CASSANDRA-17365:
---
[~brandon.williams] this makes sense to me to do, do you agree? I am not sure
if we should upgrade Python first and the remove it or vice versa but it seems
like we can already do it as of now in 3.6 and current version driver.
I am just thinking do not we want to somehow force the tls version used?
Even for debugging purposes? Do we want to autonegotiate?
> Remove deprecated version specific TLS in CQLSH
> ---
>
> Key: CASSANDRA-17365
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17365
> Project: Cassandra
> Issue Type: Task
> Components: CQL/Interpreter
>Reporter: Brad Schoening
>Assignee: Brad Schoening
>Priority: Normal
> Fix For: 4.x
>
>
> According to [https://docs.python.org/3/library/ssl.html] use of explicit TLS
> versions v1, v1_1 and v1_2 has been deprecated in Python 3.6+ in favor of
> auto-negotiation of the highest protocol version that both the client and
> server support.
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_1{}}}
> * {{{}ssl.{}}}{{{}PROTOCOL_TLSv1_2{}}}
> The above are deprecated since version 3.6: OpenSSL has deprecated all
> version specific protocols.
> This affects cqlshlib/sslhandling.py and cqlshlib/test/test_sslhandling.py.
> And also config files test/config/
> {sslhandling.config, sslhandling_invalid.config}
>
> "NSA recommends that only TLS 1.2 or TLS 1.3 be used; and that SSL 2.0, SSL
> 3.0, TLS 1.0, and TLS 1.1 not be used"
> [https://media.defense.gov/2021/Jan/05/2002560140/-1/-1/0/ELIMINATING_OBSOLETE_TLS_UOO197443-20.PDF]
> The DataStax driver has addressed this in 3.25 with this update:
> Update security documentation and examples to use PROTOCOL_TLS (PYTHON-1264)
> [https://datastax-oss.atlassian.net/browse/PYTHON-1264]
> [https://github.com/datastax/python-driver/commit/8331eca6cc96d8bd3af2e37bc64693747515c2b6]
> This change will also remove the unit test class test_sslhandling.py which
> only tested version lookups and nothing else with ssl.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17490) Remove outdated code in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517353#comment-17517353 ] Stefan Miklosovic commented on CASSANDRA-17490: --- [~bschoeni] I would love to see a PR for this. I think you still have the code around, dont you? > Remove outdated code in cqlsh.py > > > Key: CASSANDRA-17490 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17490 > Project: Cassandra > Issue Type: Task >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > > OLD_HISTORY and OLD_CQLSH was migration code for C* 1.1 -> 1.2 and is obsolete > is_using_utf8 is not used > get_usertypes_meta references missing types (cql3handling.UserTypesMeta) & > table (select * from system.schema_usertypes) and isn't used -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17450) Drop python 3.6 support
[ https://issues.apache.org/jira/browse/CASSANDRA-17450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17517352#comment-17517352 ] Stefan Miklosovic commented on CASSANDRA-17450: --- [~brandon.williams] Do you think it makes sense to try to move to Python 3.8 in 4.1? I think this means we would need to update Python in images and so on. Seems like a mere version bump as I am running 3.8.10 locally but still ... > Drop python 3.6 support > --- > > Key: CASSANDRA-17450 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17450 > Project: Cassandra > Issue Type: Task > Components: CQL/Interpreter >Reporter: Brad Schoening >Assignee: Brad Schoening >Priority: Normal > Fix For: 4.x > > > Python 3.6 became EOL as of 12/23/21. There will be no further releases or > security fixes for Python 3.6. > https://github.com/httpie/httpie/issues/1177 > https://devguide.python.org/#status-of-python-branches -- This message was sent by Atlassian Jira (v8.20.1#820001) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
