[jira] [Commented] (CASSANDRA-17542) Test failure: CommitLogSegmentManagerCDCTest.testSwitchingCDCWriteModes
[
https://issues.apache.org/jira/browse/CASSANDRA-17542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17804770#comment-17804770
]
Derek Chen-Becker commented on CASSANDRA-17542:
---
Just for posterity, the error with 4.1 is:
{noformat}
junit.framework.AssertionFailedError: Received unexpected CDCState on current
allocatingFrom segment. Expected: FORBIDDEN. Received: PERMITTED
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.expectCurrentCDCState(CommitLogSegmentManagerCDCTest.java:405)
at
org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testSwitchingCDCWriteModes(CommitLogSegmentManagerCDCTest.java:136)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{noformat}
These are actually three different errors. The SIGBUS error seen in the first
case could be https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8168628.
SIGBUS is kind of an unusual error because it's not an access permissions
issue, but rather a problem with the requested address. It's unlikely to be
something in the Cassandra code that would cause that, and the dump stack trace
would appear to confirm that.
The second case is harder because the thread dump doesn't appear to be the
actual test thread. I'm looking into what JUnit options are available to get
that.
The third case does look like a bug, so we can dig into that one a bit.
> Test failure: CommitLogSegmentManagerCDCTest.testSwitchingCDCWriteModes
> ---
>
> Key: CASSANDRA-17542
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17542
> Project: Cassandra
> Issue Type: Bug
> Components: Test/unit
>Reporter: Michael Semb Wever
>Priority: Normal
> Fix For: 4.1.x
>
>
> JVM crashes in 4.1 builds #1060 and #1067.
> h4. Cassandra-4.1 #1067
> Stage job:
> Cassandra-trunk-test/1193/jdk=jdk_11_latest,label=cassandra,split=3/
> nightlies:
> https://nightlies.apache.org/cassandra/trunk/Cassandra-trunk-test/1193/Cassandra-trunk-test/jdk=jdk_11_latest,label=cassandra,split=3/
> Crash:
> {noformat}
> 18:24:10 [junit-timeout] OpenJDK 64-Bit Server VM warning: Option
> UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed
> in a future release.
> 18:24:11 [junit-timeout] Testsuite:
> org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest
> 18:25:30 [junit-timeout] #
> 18:25:30 [junit-timeout] # A fatal error has been detected by the Java
> Runtime Environment:
> 18:25:30 [junit-timeout] #
> 18:25:30 [junit-timeout] # SIGBUS (0x7) at pc=0x7f86288b60e6, pid=2008,
> tid=2012
> 18:25:30 [junit-timeout] #
> 18:25:30 [junit-timeout] # JRE version: OpenJDK Runtime Environment
> (11.0.11+9) (build 11.0.11+9-Ubuntu-0ubuntu2.20.04)
> 18:25:30 [junit-timeout] # Java VM: OpenJDK 64-Bit Server VM
> (11.0.11+9-Ubuntu-0ubuntu2.20.04, mixed mode, sharing, tiered, compressed
> oops, concurrent mark sweep gc, linux-amd64)
> 18:25:30 [junit-timeout] # Problematic frame:
> 18:25:30 [junit-timeout] # v ~StubRoutines::jshort_disjoint_arraycopy
> 18:25:30 [junit-timeout] #
> 18:25:30 [junit-timeout] # Core dump will be written. Default location: Core
> dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P %E" (or
> dumping to /home/cassandra/cassandra/core.2008)
> 18:25:30 [junit-timeout] #
> 18:25:30 [junit-timeout] # An error report file with more information is
> saved as:
> 18:25:30 [junit-timeout] # /home/cassandra/cassandra/hs_err_pid2008.log
> 18:25:30 [junit-timeout] [thread 2064 also had an error]
> 18:25:30 [junit-timeout] Compiled method (c2) 80120 5828 4
> org.apache.cassandra.io.util.BufferedDataOutputStreamPlus::write (119 bytes)
> 18:25:30 [junit-timeout] total in heap
> [0x7f86305f9b90,0x7f86305fb4a8] = 6424
> 18:25:30 [junit-timeout] relocation
> [0x7f86305f9d08,0x7f86305f9d80] = 120
> 18:25:30 [junit-timeout] main code
> [0x7f86305f9d80,0x7f86305faae0] = 3424
> 18:25:30 [junit-timeout] stub code
> [0x7f86305faae0,0x7f86305fab18] = 56
> 18:25:30 [junit-timeout] oops
> [0x7f86305fab18,0x7f86305fab28] = 16
> 18:25:30 [junit-timeout] metadata
> [0x7f86305fab28,0x7f86305fabf0] = 200
> 18:25:30 [junit-timeout] scopes data
> [0x7f86305fabf0,0x7f86305fb208] = 1560
> 18:25:30 [junit-timeout] scopes pcs
> [0x7f86305fb208,0x7f86305fb438] = 560
> 18:25:30 [junit-timeout] dependencies
> [0x7f86305fb438,0x7f86305fb448] = 1
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759261#comment-17759261
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
CircleCI for 5.0 passed for Java 11:
https://app.circleci.com/pipelines/github/dchenbecker/cassandra/81/workflows/0da5d328-ba5e-4243-b0ad-509fe39340d4/jobs/2401
One test failed for Java 17:
https://app.circleci.com/pipelines/github/dchenbecker/cassandra/81/workflows/a39bd419-e18d-4f5f-8b67-19709a9c407b/jobs/2400/tests
The only option I have is to "Rerun with SSH", but that failed with a timeout
last time so I'm not convinced it'll actually succeed. Are the other Rerun
options not available for free tier?
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
> Attachments: signature.asc
>
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759248#comment-17759248
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
PR Against 5.0:
https://github.com/apache/cassandra/pull/2635
CircleCI is still running
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
> Attachments: signature.asc
>
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17759241#comment-17759241
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
PR against 4.1. Tests pass locally, and on CircleCI Java 8/11
https://github.com/apache/cassandra/pull/2634
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
> Attachments: signature.asc
>
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758614#comment-17758614
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Yup, sorry, I just realized I had my upstream branch set incorrectly so I
wasn't seeing updates to trunk. PR is updated and I'll start working on
backporting.
https://cassandra.apache.org/_/development/patches.html seems out of date.
Which branches should I target with this?
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758590#comment-17758590
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Before (tested against current trunk):
{code}
...
[checkstyle] [ERROR]
/ssdhome/software/projects/cassandra/test/unit/org/apache/cassandra/streaming/StreamSessionTest.java:79:
Please do not hardcode /tmp for test files and directories. Use
Files.createTempDirectory to create a base test directory instead.
[hardcodeTmpDirectoryUsage]
BUILD FAILED
/ssdhome/software/projects/cassandra/build.xml:521: The following error
occurred while executing this line:
/ssdhome/software/projects/cassandra/.build/build-checkstyle.xml:57: Got 30
errors and 0 warnings.
{code}
After the change it still failed, but on a CVE vulnerability in {{bcprov}}.
Total runtime with the new rule was 2:42.
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758581#comment-17758581
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
It takes ripgrep all of 30ms to check the entire codebase, so hopefully
checkstyle can come within an order of magnitude or two :) Let me add the rule
and test.
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758138#comment-17758138
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Here's one link I found describing the time limit:
https://support.circleci.com/hc/en-us/articles/16616033407131-Max-Runtime-in-CircleCI-Server
Here's the job that failed due to the 1 hour limit:
https://app.circleci.com/pipelines/github/dchenbecker/cassandra/74/workflows/3a633508-b2a8-4014-8fc2-bbe79e0850b0/jobs/1678
For my most recent run that passed, it came pretty close to failing (57:50
runtime):
https://app.circleci.com/pipelines/github/dchenbecker/cassandra/76/workflows/21c09abf-70bd-4eab-a541-1c108a5438ef/jobs/1891
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757740#comment-17757740
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Re-run succeeded. It did take 57 minutes and I remember CircleCI cutting off
prior testing at 1 hour, so maybe that was it?
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757677#comment-17757677
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Let me re-run and see if it's still failing
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757022#comment-17757022
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
OK, simple fix. The Files API wasn't creating the tmp dir base automatically,
so I added a {{mkdir}} to the {{build.xml}} as a pre-step. PR is updated
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757011#comment-17757011
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
I checked out into a new repo and now it's failing for me. Let me figure out
what's going on.
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17756953#comment-17756953
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
Thanks, I can run {{AuditLoggerCleanuptest}} locally without issue. The
diagnostics are a little meager in that test, probably because it's creating a
temp directory using JUnit Rules instead of directly creating it like other
tests do. Let me see if I can get more detail on my side to try and triage it.
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18750:
--
Test and Documentation Plan: Tested locally with {{ant test}} and with
{{.build/docker/run-tests.sh test}}. CircleCI tests almost all failed due to
concurrency limit (I'm on the free tier) and I'm trying to re-run each test
individually to see if I can get that green.
Status: Patch Available (was: Open)
Initial PR against trunk is at https://github.com/apache/cassandra/pull/2593.
Once that's reviewed and approved I can provide PRs for release branches.
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18750:
--
Change Category: Code Clarity
Complexity: Low Hanging Fruit
Component/s: Build
Status: Open (was: Triage Needed)
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17754400#comment-17754400
]
Derek Chen-Becker commented on CASSANDRA-18750:
---
I think I'm 98% done with the needed changes (or at least a first pass; I'm
sure I'll get feedback), but I've hit an issue with AuditLoggerTest. While
AuditLogOptions has a String property for "audit_logs_dir", the test calls
StorageService.enableAuditLogs throught the test methods, and that method does
not take a parameter for the log directory. As a result, the AuditLogOptions
instance that is created always uses the default audit log directory, which
just happens to be the "audit" subdirectory of the project root. This is
getting into territory I'm not that familiar with, but it seems like there
might be three ways to fix this:
1. Write a new overload of StorageService.enableAuditLog that takes an
AuditLogOptions and delegate the other overloads to it
2. Add a new overload that also takes a Path or File pointing to the audit log
directory
3. Set the "cassandra.logdir.audit" property in the ant build, similar to
"tmp.dir"/"java.io.tmpdir"
Thoughts?
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18750:
--
Issue Type: Improvement (was: Task)
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
[
https://issues.apache.org/jira/browse/CASSANDRA-18750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18750:
--
Issue Type: Task (was: Improvement)
> Make unit tests compatible with the tmp.dir property
>
>
> Key: CASSANDRA-18750
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
> Project: Cassandra
> Issue Type: Task
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> Several unit tests hard-code file paths under the "/tmp" directory, which
> means they do not honor the {{tmp.dir}} ant build property. These should be
> updated so that when the user specifies {{tmp.dir}}, they can be certain that
> any files or directories created by the unit tests will be in their specified
> location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-18750) Make unit tests compatible with the tmp.dir property
Derek Chen-Becker created CASSANDRA-18750:
-
Summary: Make unit tests compatible with the tmp.dir property
Key: CASSANDRA-18750
URL: https://issues.apache.org/jira/browse/CASSANDRA-18750
Project: Cassandra
Issue Type: Improvement
Reporter: Derek Chen-Becker
Assignee: Derek Chen-Becker
Several unit tests hard-code file paths under the "/tmp" directory, which means
they do not honor the {{tmp.dir}} ant build property. These should be updated
so that when the user specifies {{tmp.dir}}, they can be certain that any files
or directories created by the unit tests will be in their specified location.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729577#comment-17729577 ] Derek Chen-Becker commented on CASSANDRA-17997: --- I've updated the trunk PR with matching changes to `generate_11_and_17.sh` > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729451#comment-17729451 ] Derek Chen-Becker commented on CASSANDRA-17997: --- Sorry I missed that! I'll try to get that change in and update the trunk PR tonight. > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729140#comment-17729140 ] Derek Chen-Becker commented on CASSANDRA-17997: --- I've updated all of the existing PRs for 3.0, 3.11, 4.0, 4.1, and now I've submitted a PR for trunk: https://github.com/apache/cassandra/pull/2385 > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17729077#comment-17729077 ] Derek Chen-Becker commented on CASSANDRA-17997: --- Actually I might have time to finish this this weekend. Let me update the existing PRs and create the PR for trunk > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728379#comment-17728379 ] Derek Chen-Becker commented on CASSANDRA-17997: --- Sorry, I was waiting on changes to trunk before I made the PR because it wouldn't have worked at the time. I just switched jobs and I'm probably swamped for the next couple of weeks, so if you'd like to roll the trunk patch into your work I would greatly appreciate it. If you don't get to it I can try and tackle it once I come up for air. > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 5.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Comment Edited] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722232#comment-17722232
]
Derek Chen-Becker edited comment on CASSANDRA-11471 at 5/12/23 4:26 PM:
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages. Additionally, change #1
would allow clients that don't use the OPTIONS message to still benefit from
being able to transition between AuthN mechanisms.
was (Author: dchenbecker):
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages.
> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence
> would allow us to support multiple authentication schemes and [negotiation of
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2].
> The current {{AUTHENTICATE}} message sent from Client to Server includes the
> java classname of the configured {{IAuthenticator}}. This could be superceded
> by a new message which lists the SASL mechanisms supported by the server. The
> client would then respond with a new message which indicates it's choice of
> mechanism. This would allow the server to support multiple mechanisms, for
> example enabling both {{PLAIN}} for username/password authentication and
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL
> certificates\* (see the example in
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the
> server could tailor the list of supported mechanisms on a per-connection
> basis, e.g. only offering certificate based auth to encrypted clients.
> The client's response should include the selected mechanism and any initial
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists
> of a single round in which the client sends encoded credentials as the
> initial response data and the server response indicates either success or
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange
> would continue as in protocol v4, with one or more rounds of
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or
> an {{ERROR}} on auth failure.
> XMPP performs mechanism negotiation in this way,
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good
> overview.
> \* Note: this would require some a priori agreement between client and server
> over the implementation of the {{E
[jira] [Commented] (CASSANDRA-11471) Add SASL mechanism negotiation to the native protocol
[
https://issues.apache.org/jira/browse/CASSANDRA-11471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17722232#comment-17722232
]
Derek Chen-Becker commented on CASSANDRA-11471:
---
We had some discussion via Slack today and I wanted to summarize an alternative
proposal:
Instead of using a new message with AUTHENTICATE, we can leverage the OPTIONS
message that the client can send. The following changes would be required:
1. Make changes to the server so that it can be configured with more than one
supported mechanism. This will require some changes to the configuration
handling as well as some changes in the AuthN path to select the mechanism
provided by the customer in the AUTHENTICATE message
2. Make changes to the server so that it returns a new property in the
SUPPORTED message indicating a set (or list in order of preference?) of
supported AuthN mechanisms
3. Clients would need to be changed to recognize and utilize the new SUPPORTED
property
The primary benefit of leveraging OPTIONS/SUPPORTED to communicate supported
mechanisms is that it would be backwards compatible with existing clients and
would not require a change to the protocol messages.
> Add SASL mechanism negotiation to the native protocol
> -
>
> Key: CASSANDRA-11471
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11471
> Project: Cassandra
> Issue Type: Sub-task
> Components: Legacy/CQL
>Reporter: Sam Tunnicliffe
>Assignee: Ben Bromhead
>Priority: Normal
> Fix For: 5.x
>
> Attachments: CASSANDRA-11471
>
>
> Introducing an additional message exchange into the authentication sequence
> would allow us to support multiple authentication schemes and [negotiation of
> SASL mechanisms|https://tools.ietf.org/html/rfc4422#section-3.2].
> The current {{AUTHENTICATE}} message sent from Client to Server includes the
> java classname of the configured {{IAuthenticator}}. This could be superceded
> by a new message which lists the SASL mechanisms supported by the server. The
> client would then respond with a new message which indicates it's choice of
> mechanism. This would allow the server to support multiple mechanisms, for
> example enabling both {{PLAIN}} for username/password authentication and
> {{EXTERNAL}} for a mechanism for extracting credentials from SSL
> certificates\* (see the example in
> [RFC-4422|https://tools.ietf.org/html/rfc4422#appendix-A]). Furthermore, the
> server could tailor the list of supported mechanisms on a per-connection
> basis, e.g. only offering certificate based auth to encrypted clients.
> The client's response should include the selected mechanism and any initial
> response data. This is mechanism-specific; the {{PLAIN}} mechanism consists
> of a single round in which the client sends encoded credentials as the
> initial response data and the server response indicates either success or
> failure with no futher challenges required.
> From a protocol perspective, after the mechanism negotiation the exchange
> would continue as in protocol v4, with one or more rounds of
> {{AUTH_CHALLENGE}} and {{AUTH_RESPONSE}} messages, terminated by an
> {{AUTH_SUCCESS}} sent from Server to Client upon successful authentication or
> an {{ERROR}} on auth failure.
> XMPP performs mechanism negotiation in this way,
> [RFC-3920|http://tools.ietf.org/html/rfc3920#section-6] includes a good
> overview.
> \* Note: this would require some a priori agreement between client and server
> over the implementation of the {{EXTERNAL}} mechanism.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18144:
--
Resolution: Fixed
Status: Resolved (was: Open)
Spurious dtest failure misled to this ticket
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-18144) org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload fails when running with TrieMemtables
[
https://issues.apache.org/jira/browse/CASSANDRA-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-18144:
--
Resolution: (was: Fixed)
Status: Open (was: Resolved)
This appears to have broken one of the dtests:
https://ci-cassandra.apache.org/job/Cassandra-trunk/1473/testReport/dtest.replace_address_test/TestReplaceAddress/
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload
> fails when running with TrieMemtables
> ---
>
> Key: CASSANDRA-18144
> URL: https://issues.apache.org/jira/browse/CASSANDRA-18144
> Project: Cassandra
> Issue Type: Bug
> Components: CI
>Reporter: David Capwell
>Assignee: Kamalesh Palanisamy
>Priority: Normal
> Fix For: 4.1.x
>
>
> https://app.circleci.com/pipelines/github/dcapwell/cassandra/1771/workflows/1bd920c8-8568-44b3-9e8b-b152a73cf4fc/jobs/15393
> {code}
> java.lang.RuntimeException: Error setting schema for test (query was: alter
> table cql_test_keyspace.table_01 with compaction = {'class':
> 'SizeTieredCompactionStrategy', 'enabled': false})
> at org.apache.cassandra.cql3.CQLTester.schemaChange(CQLTester.java:1222)
> at org.apache.cassandra.cql3.CQLTester.alterTable(CQLTester.java:1009)
> at
> org.apache.cassandra.db.compaction.CompactionStrategyManagerBoundaryReloadTest.testReload(CompactionStrategyManagerBoundaryReloadTest.java:82)
> Caused by: java.lang.ClassCastException:
> org.apache.cassandra.dht.ByteOrderedPartitioner$BytesToken cannot be cast to
> org.apache.cassandra.dht.Murmur3Partitioner$LongToken
> at
> org.apache.cassandra.dht.Murmur3Partitioner$1.valueForToken(Murmur3Partitioner.java:68)
> at
> org.apache.cassandra.dht.Splitter$WeightedRange.totalTokens(Splitter.java:278)
> at org.apache.cassandra.dht.Splitter.splitOwnedRanges(Splitter.java:129)
> at
> org.apache.cassandra.db.ColumnFamilyStore.localRangeSplits(ColumnFamilyStore.java:1504)
> at
> org.apache.cassandra.db.memtable.AbstractShardedMemtable.(AbstractShardedMemtable.java:65)
> at
> org.apache.cassandra.db.memtable.TrieMemtable.(TrieMemtable.java:142)
> at
> org.apache.cassandra.db.memtable.TrieMemtable$Factory.create(TrieMemtable.java:688)
> at
> org.apache.cassandra.db.ColumnFamilyStore.createMemtable(ColumnFamilyStore.java:1375)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1173)
> at
> org.apache.cassandra.db.ColumnFamilyStore$Flush.(ColumnFamilyStore.java:1137)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtable(ColumnFamilyStore.java:1000)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableIfCurrent(ColumnFamilyStore.java:981)
> at
> org.apache.cassandra.db.ColumnFamilyStore.switchMemtableOrNotify(ColumnFamilyStore.java:966)
> at
> org.apache.cassandra.db.ColumnFamilyStore.reload(ColumnFamilyStore.java:393)
> {code}
> First reported to slack:
> https://the-asf.slack.com/archives/CK23JSY2K/p1673382016638189
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17850) Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without opening internals
[
https://issues.apache.org/jira/browse/CASSANDRA-17850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17695334#comment-17695334
]
Derek Chen-Becker commented on CASSANDRA-17850:
---
I'm assuming that even if we dealt with the first two issues, there are other
places where we're using a raw FD. For the first two stack traces, the TimeUUID
class is just using the NativeLibrary to get the PID. At least with Java 9+ we
should be able to use the new {{ProcessHandle}} API to get the PID instead of
the {{NativeLibrary}} code. The other methods on NativeLibrary look like
locking, syncing and closing; if we're wrapping a native library anyway, should
we just move that code to the native library instead if the JVM doesn't support
these?
> Find a way to get FileDescriptor.fd and sun.nio.ch.FileChannelImpl.fd without
> opening internals
> ---
>
> Key: CASSANDRA-17850
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17850
> Project: Cassandra
> Issue Type: Improvement
> Components: Build
>Reporter: Ekaterina Dimitrova
>Priority: Normal
> Fix For: 4.x
>
>
> With Java 17 if we do not add below to the jvm17 server options:
> {code:java}
> --add-opens java.base/sun.nio.ch=ALL-UNNAMED
> --add-opens java.base/java.io=ALL-UNNAMED{code}
> we get on startup (considering I comment out the scripted UDFs and apply a
> few changes to the startup scripts):
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:29:25,652
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException:
> Unable to make field private int java.io.FileDescriptor.fd accessible: module
> java.base does not "opens java.io" to unnamed module @11d8ae8b
> at
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:801)
> at org.apache.cassandra.utils.NativeLibrary.(NativeLibrary.java:84)
> at org.apache.cassandra.utils.TimeUUID$Generator.hash(TimeUUID.java:496)
> at org.apache.cassandra.utils.TimeUUID$Generator.makeNode(TimeUUID.java:474)
> at
> org.apache.cassandra.utils.TimeUUID$Generator.makeClockSeqAndNode(TimeUUID.java:452)
> at org.apache.cassandra.utils.TimeUUID$Generator.(TimeUUID.java:368)
> at
> org.apache.cassandra.streaming.StreamingState.(StreamingState.java:50)
> at org.apache.cassandra.streaming.StreamManager.(StreamManager.java:257)
> at
> org.apache.cassandra.streaming.StreamManager.(StreamManager.java:58)
> at org.apache.cassandra.service.StorageService.(StorageService.java:376)
> at
> org.apache.cassandra.service.StorageService.(StorageService.java:226)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch.updateScores(DynamicEndpointSnitch.java:274)
> at
> org.apache.cassandra.locator.DynamicEndpointSnitch$1.run(DynamicEndpointSnitch.java:91)
> at
> org.apache.cassandra.concurrent.ExecutionFailure$1.run(ExecutionFailure.java:133)
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
> at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> field private int java.io.FileDescriptor.fd accessible: module java.base does
> not "opens java.io" to unnamed module @11d8ae8b
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.cassandra.utils.FBUtilities.getProtectedField(FBUtilities.java:796)
> ... 20 common frames omitted
> {code}
> and
> {code:java}
> ERROR [ScheduledTasks:1] 2022-08-23 12:31:18,443
> JVMStabilityInspector.java:68 - Exception in thread
> Thread[ScheduledTasks:1,5,ScheduledTasks]
> java.lang.AssertionError: java.lang.reflect.InaccessibleObjectException:
> Unable to make field private final java.io.FileDescriptor
> sun.nio.ch.FileChannelImpl.fd accessible: module java.base does not "opens
> sun.nio.ch" to unnamed module @4c012563
> at
> org.apache.cassandra.utils.FBUtilities.getProt
[jira] [Commented] (CASSANDRA-17125) Remove use of deprecated Futures in tests
[
https://issues.apache.org/jira/browse/CASSANDRA-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17694643#comment-17694643
]
Derek Chen-Becker commented on CASSANDRA-17125:
---
Starting some work to triage scope of work. The Guava futures (e.g.
AbstractFuture, ListenableFuture) seem pervasive in our unit tests. Part of
this will require some work to figure out how to replace these.
> Remove use of deprecated Futures in tests
> -
>
> Key: CASSANDRA-17125
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17125
> Project: Cassandra
> Issue Type: Sub-task
> Components: Test/unit
>Reporter: Brandon Williams
>Priority: Normal
>
> To pass checkstyle:
> {noformat}
> Illegal import - com.google.common.util.concurrent.AbstractFuture.
> [IllegalImport]
> Illegal import - com.google.common.util.concurrent.Futures.
> [IllegalImport]
> Illegal import - com.google.common.util.concurrent.ListenableFuture.
> [IllegalImport]
> Illegal import - com.google.common.util.concurrent.ListenableFutureTask.
> [IllegalImport]
> Illegal import - io.netty.util.concurrent.Future. [IllegalImport]
> Illegal import - io.netty.util.concurrent.Promise. [IllegalImport]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688716#comment-17688716
]
Derek Chen-Becker commented on CASSANDRA-17979:
---
Still pending review. I really think we should go back to the first version of
the patch. Testing for delivery just feels like conflating concerns in a unit
test
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17685993#comment-17685993
]
Derek Chen-Becker commented on CASSANDRA-17979:
---
I've replaced both assertions with a new method to validate delivery and I've
renamed everything to make it clear that they also test delivery. CircleCI is
running unit tests now. I'm going to disagree with the idea that every unit
test should be an integration test (message delivery is tested in other test
classes), but in the interest of fixing a flaky test we can hopefully merge
this soon.
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17685615#comment-17685615
]
Derek Chen-Becker commented on CASSANDRA-17979:
---
For posterity, here's a brief description of the code path and bug-in-test:
* The test calls {{initiateOutbound}} to [enqueue a
message|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/HandshakeTest.java#L365]
and initiate the connection
* After successful connection setup, the {{OutboundConnection}} state [is
updated|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnection.java#L1131]
* {{waitForConnection}} basically [loops until the connection state is
established
{{OutboundConnection::isConnected}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/OutboundConnection.java#L1131]
* The unit test then [verifies that the connection is
established|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/HandshakeTest.java#L383]
because {{waitForConnection}} can also exit due to timeout
* At this point we have verified that the connection has established
successfully and performed whatever fallback handshake needed to occur, but
nothing about the current state indicates whether or not the enqueued message
has been sent, so the subsequent
[{{hasPending}}|https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/HandshakeTest.java#L384]
call is a race against the message delivery thread
Connection establishment, at least in my mind, means sockets connected, TLS
handshake complete (if negotiated), and ready for use, but I don't think we
want to conflate that state with whether or not bytes have been put on the wire
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17979:
--
Test and Documentation Plan:
Tested in CircleCI and locally with multiple runs and I no longer hit the error
encountered.
https://github.com/apache/cassandra/pull/2143
Status: Patch Available (was: Open)
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684047#comment-17684047
]
Derek Chen-Becker commented on CASSANDRA-17979:
---
I think that the problem is
https://github.com/apache/cassandra/blob/trunk/test/unit/org/apache/cassandra/net/HandshakeTest.java#L384.
The previous line calls {{isConnected}}, which only checks the state of the
connection, not whether the connection has pending data. Given that the test
appears to want to just test connection fallback, I think that the check for
pending messages is unnecessary. I'll submit a patch to remove that check.
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker reassigned CASSANDRA-17979:
-
Assignee: Derek Chen-Becker
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Assignee: Derek Chen-Becker
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17979) Fix flaky test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
[
https://issues.apache.org/jira/browse/CASSANDRA-17979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17979:
--
Resolution: (was: Duplicate)
Status: Open (was: Resolved)
I'm reopening this ticket. While digging into the test failure, it appears to
be a bug-in-test, and a different code path than CASSANDRA-17708
> Fix flaky
> test:org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades
> ---
>
> Key: CASSANDRA-17979
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17979
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Internode
>Reporter: Brandon Williams
>Priority: Normal
> Fix For: 4.x
>
>
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1339/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_cdc/
> https://ci-cassandra.apache.org/job/Cassandra-trunk/1336/testReport/org.apache.cassandra.net/HandshakeTest/testOutboundConnectionfFallbackDuringUpgrades_compression/
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/1466/workflows/ffb52616-92d7-4089-a0c9-a9ebf28333c0/jobs/6296/tests
> {noformat}
> junit.framework.AssertionFailedError
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundFallbackOnSSLHandshakeFailure(HandshakeTest.java:384)
> at
> org.apache.cassandra.net.HandshakeTest.testOutboundConnectionfFallbackDuringUpgrades(HandshakeTest.java:243)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17708) Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails
[ https://issues.apache.org/jira/browse/CASSANDRA-17708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17684020#comment-17684020 ] Derek Chen-Becker commented on CASSANDRA-17708: --- This looks like a race condition and a bad assertion in the unit test. I'm looking at testOutboundFallbackOnSSLHandshakeFailure which touches the same code. In that method, we enqueue a message, initiate the connection, and then just wait for the outbound connection to become connected. At the point where the connection state is changed (allowing outboundConnection.isConnected() to return true), there's no guarantee that the message that force the connection would actually be flushed. I think that for the purpose of this unit test, checking for pending messages is not actually needed, or should potentially be in another test. > Fix flaky testOutboundConnectionsAreRejectedWhenAuthFails > - > > Key: CASSANDRA-17708 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17708 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > testOutboundConnectionsAreRejectedWhenAuthFails was introduced in > CASSANDRA-17661 > It seems it was introduced flaky from the very beginning as per this run in a > loop - > [https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra?branch=flaky-testOutboundConnectionsAreRejectedWhenAuthFails&filter=all] > CC [~janaki.manchala] , [~jonmeredith], [~ycai] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-18027) Use G1GC as default
[ https://issues.apache.org/jira/browse/CASSANDRA-18027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17678443#comment-17678443 ] Derek Chen-Becker commented on CASSANDRA-18027: --- I'm +1 to these changes. For what it's worth, MaxGCPauseMillis is purely advisory and I'm not sure that the time vs throughput explanation in the comment is still applicable in JDK17 with the changes that have happened to G1. Not an objection, just something to note as we continue to update JVM version support. > Use G1GC as default > --- > > Key: CASSANDRA-18027 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18027 > Project: Cassandra > Issue Type: Task > Components: Local/Config >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: High > Fix For: 4.1.x, 4.x > > > G1GC is well battle tested now, and the recommended configuration for most > users. CMS can work well on smaller heaps but requires more tuning, initially > and over time. G1GC just works. CMS was deprecated in JDK 9. > Patch at > https://github.com/apache/cassandra/compare/trunk...thelastpickle:cassandra:mck/7486/trunk -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17634332#comment-17634332 ] Derek Chen-Becker commented on CASSANDRA-17997: --- PR for 3.11 is updated with a fix for the nit :) PR for 3.0: [https://github.com/apache/cassandra/pull/2016] PR for 4.0: [https://github.com/apache/cassandra/pull/2017] PR for 4.1: [https://github.com/apache/cassandra/pull/2018] PR for trunk is pending because it looks like your change was not applied to trunk. I can try to make a PR that includes both changes, if that would help, but your change looks a little complex and I might need some assistance > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 4.0.x, 4.1.x, 4.x > > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631350#comment-17631350 ] Derek Chen-Becker commented on CASSANDRA-17950: --- Trunk patch LGTM > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Urgent > Fix For: 3.11.x, 4.0.x, 4.1-rc, 4.1.x, 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17631172#comment-17631172 ] Derek Chen-Becker commented on CASSANDRA-17950: --- +1 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Urgent > Fix For: 3.11.x, 4.0.x, 4.1-rc, 4.1.x, 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630565#comment-17630565 ] Derek Chen-Becker commented on CASSANDRA-17997: --- I think I'll defer the check on existing remotes just because that's more work for less impact > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17630024#comment-17630024 ] Derek Chen-Becker commented on CASSANDRA-17997: --- PR for 3.11 branch in https://github.com/apache/cassandra/pull/1984 > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17629961#comment-17629961 ] Derek Chen-Becker commented on CASSANDRA-17950: --- I took at look at the updated commit ([https://github.com/ekaterinadimitrova2/cassandra/commit/0386995747368d8da71ff963c1fdabc6b96d7236)] and it looks correct to me. Andres' suggestions also look reasonable > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 3.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-18011) Parameterize and generate .circleci/config-2_1.yml rather than manually maintain
[ https://issues.apache.org/jira/browse/CASSANDRA-18011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Chen-Becker reassigned CASSANDRA-18011: - Assignee: Derek Chen-Becker > Parameterize and generate .circleci/config-2_1.yml rather than manually > maintain > > > Key: CASSANDRA-18011 > URL: https://issues.apache.org/jira/browse/CASSANDRA-18011 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Josh McKenzie >Assignee: Derek Chen-Becker >Priority: Normal > > Reference email thread [DISCUSS] Potential circleci config and workflow > changes, specifically David's message > [here|https://lists.apache.org/thread/059c4s6v8q9rl5lmhkj8xhfmwdj2fy2d] > To quote him: > bq. CI is a combinatorial problem, we need to run all jobs for all JDKs, > vnode on/off, cdc on/off, compression on/of, etc…. But this is currently > controlled and fleshed out by humans who want to add new jobs. We should move > away from maintaining .circleci/config-2_1.yml and instead auto-generate it. > Simple example of this problem is jdk11 support… we run a subset of tests on > jdk11 and say its supported… will jdk17 have the same issue? Will it be even > less tests? Why does the burden lie on everyone to “do the right thing” when > all they want is a simple job? > Derek Chen-Becker has also started a more granular email thread with a > potential design alternative along these lines available > [here|https://lists.apache.org/thread/mvql1p5y2j7so18427zcg4zxc9vzl7l3]. > Based on the output of those discussions, we should reflect the conclusion > here and track that work. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625085#comment-17625085 ] Derek Chen-Becker commented on CASSANDRA-17997: --- CASSANDRA-17939 is the original ticket for using git to determine changed tests > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17625083#comment-17625083 ] Derek Chen-Becker commented on CASSANDRA-17997: --- That was actually my suggestion when I discussed this with [~e.dimitrova] yesterday. That should be a pretty simple check, and easy to add the logic. I agree that we should only consider the ASF remote as canonical and bail out if the remotes only contain personal forks. > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624754#comment-17624754 ] Derek Chen-Becker commented on CASSANDRA-17997: --- It's very likely for me, because I always delete local branches when I'm done with them :) In any case, I think there are two parts here: # Add the "-b" flag to allow overriding the branch, or optionally allow someone to specify the BASE_BRANCH env var and use the default if not set # Check to make sure that the base branch exists, and exit with a warning and useful information if it doesn't > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement > Components: CI >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17624751#comment-17624751 ] Derek Chen-Becker commented on CASSANDRA-17950: --- PR for 3.11: https://github.com/apache/cassandra/pull/1953 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950 ] Derek Chen-Becker deleted comment on CASSANDRA-17950: --- was (Author: dchenbecker): PR: https://github.com/apache/cassandra/pull/1904 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task > Components: Test/dtest/python >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.11.x, 4.0.x, 4.1.x, 4.x > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
[ https://issues.apache.org/jira/browse/CASSANDRA-17997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Chen-Becker reassigned CASSANDRA-17997: - Assignee: Derek Chen-Becker > Improve git branch handling for CircleCI generate.sh > > > Key: CASSANDRA-17997 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 > Project: Cassandra > Issue Type: Improvement >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > > The generate.sh script assumes a base git branch that is local and named > after the official repo branch (e.g. `cassandra-3.11`). This may not be a > local branch if the developer has recently cloned the repo and is creating a > work branch, and will lead to the git commands in generate.sh failing: > > ``` > fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path > not in the working tree. > Use '--' to separate paths from revisions, like this: > 'git [...] -- [...]' > ``` > We should be able to make some sanity checks to better guide or warn the > developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17997) Improve git branch handling for CircleCI generate.sh
Derek Chen-Becker created CASSANDRA-17997: - Summary: Improve git branch handling for CircleCI generate.sh Key: CASSANDRA-17997 URL: https://issues.apache.org/jira/browse/CASSANDRA-17997 Project: Cassandra Issue Type: Improvement Reporter: Derek Chen-Becker The generate.sh script assumes a base git branch that is local and named after the official repo branch (e.g. `cassandra-3.11`). This may not be a local branch if the developer has recently cloned the repo and is creating a work branch, and will lead to the git commands in generate.sh failing: ``` fatal: ambiguous argument 'cassandra-3.11...HEAD': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git [...] -- [...]' ``` We should be able to make some sanity checks to better guide or warn the developer if things aren't set up properly to check against git. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Status: Review In Progress (was: Patch Available)
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Test and Documentation Plan: Tested locally using the run.sh instructions.
Screenshots attached to the PR
Status: Patch Available (was: Open)
Patch available at https://github.com/apache/cassandra-website/pull/179
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Derek Chen-Becker updated CASSANDRA-17990:
--
Change Category: Operability
Complexity: Low Hanging Fruit
Component/s: Documentation/Website
Reviewers: Michael Semb Wever, Michael Shuler
Status: Open (was: Triage Needed)
Opening ticket
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
[
https://issues.apache.org/jira/browse/CASSANDRA-17990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17623835#comment-17623835
]
Derek Chen-Becker commented on CASSANDRA-17990:
---
Work being tracked in https://github.com/apache/cassandra-website/pull/179
> WEBSITE - Fix formatting that should be links on the "patches" page
> ---
>
> Key: CASSANDRA-17990
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
> Project: Cassandra
> Issue Type: Task
>Reporter: Derek Chen-Becker
>Assignee: Derek Chen-Becker
>Priority: Normal
>
> The [https://cassandra.apache.org/_/development/patches.html] page has
> several places where references to other pages are not actual links, but are
> formatted as fixed-width text. For example:
> Code must follow the {{code_style}} convention
> instead of
> Code must follow the [code
> style|https://cassandra.apache.org/_/development/code_style.html] convention
> These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17990) WEBSITE - Fix formatting that should be links on the "patches" page
Derek Chen-Becker created CASSANDRA-17990:
-
Summary: WEBSITE - Fix formatting that should be links on the
"patches" page
Key: CASSANDRA-17990
URL: https://issues.apache.org/jira/browse/CASSANDRA-17990
Project: Cassandra
Issue Type: Task
Reporter: Derek Chen-Becker
Assignee: Derek Chen-Becker
The [https://cassandra.apache.org/_/development/patches.html] page has several
places where references to other pages are not actual links, but are formatted
as fixed-width text. For example:
Code must follow the {{code_style}} convention
instead of
Code must follow the [code
style|https://cassandra.apache.org/_/development/code_style.html] convention
These should be fixed to be actual links
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17616599#comment-17616599 ] Derek Chen-Becker commented on CASSANDRA-17950: --- PR: https://github.com/apache/cassandra/pull/1904 > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Assigned] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
[ https://issues.apache.org/jira/browse/CASSANDRA-17950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Derek Chen-Becker reassigned CASSANDRA-17950: - Assignee: Derek Chen-Becker > Enable dtest-offheap in CircleCI > > > Key: CASSANDRA-17950 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 > Project: Cassandra > Issue Type: Sub-task >Reporter: Derek Chen-Becker >Assignee: Derek Chen-Becker >Priority: Normal > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-17950) Enable dtest-offheap in CircleCI
Derek Chen-Becker created CASSANDRA-17950: - Summary: Enable dtest-offheap in CircleCI Key: CASSANDRA-17950 URL: https://issues.apache.org/jira/browse/CASSANDRA-17950 Project: Cassandra Issue Type: Sub-task Reporter: Derek Chen-Becker -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17613600#comment-17613600 ] Derek Chen-Becker commented on CASSANDRA-17930: --- I think there's material evidence (e.g. this ticket) that the current approach has problems. In the short term, I think we need to just manually turn the crank to fix up what we can find. What I mean by a long-term driven by a single config is it would be ideal to have a (simple) way to define a test in one place, and be able to generate the configurations for CircleCI, Jenkins, and whatever other CI system we decide to use from that canonical source. I'm not saying that this ticket is where this happens, I'm just saying a system where you rely on good intentions to ensure parity is statistically unlikely to maintain that parity over time. As for naming, I'm fine taking small incremental steps to fix them, but I do think they need fixed. I don't see any value in having the names not be the same between the two systems. If changing the name of a test doesn't otherwise change or break its behavior, do you have an objection? > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612699#comment-17612699 ] Derek Chen-Becker commented on CASSANDRA-17930: --- OK, I think I'm at least familiar enough with both the Jenkins and Circle build setup scripts to start with some observations: * An ideal outcome (albeit longer-term) would be a single test configuration source that could drive generation of both systems * The Circle and Jenkins configurations are in separate repositories, which adds a little complexity to that task * In the short term, some auditing automation would be helpful * Naming appears to differ for the same set of tests between Circle and Jenkins. However, this may just be me misunderstanding how either DSL works. Some examples: ** j8 (Circle) vs jdk_1.8_latest (Jenkins) ** with-vnode (Circle) vs nothing in Jenkins for vnode tests as far as I can tell ** no-vnodes (Circle) vs novnode (Jenkins) Is the naming tied to the CI somehow, or could we revise the naming to align across both? That would at least help with auditing, and I can do it as part of adding some of the missing tests to either side. Given prior discussion I can focus on getting the tests missing in Circle if that makes sense > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17930) Ensure CircleCI and ASF Jenkins CI are aligned
[ https://issues.apache.org/jira/browse/CASSANDRA-17930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17612299#comment-17612299 ] Derek Chen-Becker commented on CASSANDRA-17930: --- Splitting into 2 tasks seems reasonable. I'm still coming up to speed on the whole CI system and how it's configured, but it seems like getting CircleCI to run all necessary tests would be the higher priority, right? > Ensure CircleCI and ASF Jenkins CI are aligned > -- > > Key: CASSANDRA-17930 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17930 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Derek Chen-Becker >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0.x, 4.1.x, 4.x > > > As discussed in this > [thread|https://lists.apache.org/list.html?d...@cassandra.apache.org] the > Cassandra community wants to see CircleCI and ASF CI being aligned - running > the same tests, configurations, all tests. > A few examples of discrepancies we already noticed: > * utests_system_keyspace_directory run only in CircleCI - CASSANDRA-17145 > * dtest-large run only in Jenkins > * simulator tests run only in CircleCI > * In a quick skim I think I didn't see > [these|https://github.com/apache/cassandra-builds/blob/trunk/build-scripts/cassandra-dtest-pytest.sh#L84-L89] > runs too in CircleCI - dtest-offheap, dtest-large, dtest-large-novnode > * packaging is also only tested in Jenkins as far as I recall > And these are only a few examples on top of my mind. I am sure we will find > more. We also need to verify the way we call those tests is correct and > matches in both CIs. (I was looking to solve similar discrepancy in > CASSANDRA-17912) > Some info on our tests suites here - > [https://cassandra.apache.org/_/development/testing.html,] > [cassandra-builds repo|https://github.com/apache/cassandra-builds] where our > test images reside and the Jenkins build scripts, which I already referred > to. > CircleCI info can be found in the readme which resides in the in-tree folder > dedicated to configuration and scripts for Circle CI - > [https://github.com/apache/cassandra/tree/trunk/.circleci] > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17031) Add support for PEM based key material for SSL
[
https://issues.apache.org/jira/browse/CASSANDRA-17031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17427989#comment-17427989
]
Derek Chen-Becker commented on CASSANDRA-17031:
---
Generally this looks good, but I would call out that I think it would be better
if we followed the example in
https://issues.apache.org/jira/browse/CASSANDRA-16983 and don't put sensitive
material (the private key password) in the config file, but rather in a
separate secured file.
> Add support for PEM based key material for SSL
> --
>
> Key: CASSANDRA-17031
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17031
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Internode
>Reporter: Maulin Vasavada
>Assignee: Maulin Vasavada
>Priority: Normal
>
> h1. Scope
> Currently Cassandra supports standard keystore types for SSL
> keys/certificates. The scope of this enhancement is to add support for PEM
> based key material (keys/certificate) given that PEM is widely used common
> format for the same. We intend to add support for Password Based Encrypted
> (PBE) PEM Private Keys with standard algorithms along with the certificate
> chain for the private key and PEM based certificates. The work here is going
> to be built on top of [CEP-9: Make SSLContext creation
> pluggable|https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-9%3A+Make+SSLContext+creation+pluggable]
> for which the code is merged for Apache Cassandra 4.1 release.
> We intend to support the key material be configured as direct PEM values
> input OR via the file (configured with keystore and truststore configurations
> today). We are not going to model PEM as a valid 'store_type' given that
> 'store_type' has a [specific
> definition|https://docs.oracle.com/en/java/javase/11/security/java-cryptography-architecture-jca-reference-guide.html#GUID-AB51DEFD-5238-4F96-967F-082F6D34FBEA].
>
> h1. Approach
> Create an implementation for
> [ISslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/ISslContextFactory.java]
> extending
> [FileBasedSslContextFactory|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/security/FileBasedSslContextFactory.java]
> implementation to add PEM formatted key/certificates.
> h1. Motivation
> PEM is a widely used format for encoding Private Keys and X.509 Certificates
> and Apache Cassandra's current implementation lacks the support for
> specifying the PEM formatted key material for SSL configurations. This means
> operators have to re-create the key material to comply to the supported
> formats (using key/trust store types - jks, pkcs12 etc) and deal with an
> operational task for managing it. This is an operational overhead we can
> avoid by supporting the PEM format making Apache Cassandra even more customer
> friendly and drive more adoption.
> h1. Proposed Changes
> # A new implementation for ISslContextFactory - PEMBasedSslContextFactory
> with the following supported configuration
> {panel:title=New configurations}
> {panel}
> |{{encryption_options: }}
> {{}}{{ssl_context_factory:}}
> {{}}{{class_name:
> org.apache.cassandra.security.PEMBasedSslContextFactory}}
> {{}}{{parameters:}}
> {{ }}{{private_key: certificate chain>}}
> {{ }}{{private_key_password: {{key }}{{if}} {{it is encrypted>}}
> {{ }}{{trusted_certificates: }}|
> *NOTE:* We could reuse 'keystore_password' instead of the
> 'private_key_password'. However PEM encoded private key is not a 'keystore'
> in itself hence it would be inappropriate to piggyback on that other than
> avoid duplicating similar fields.
> # The PEMBasedSslContextFactory will also support file based key material
> (and the corresponding HOT Reloading based on file timestamp updates) for the
> PEM format via existing 'keystore' and 'truststore' encryption options.
> However in that case the 'truststore_password' configuration won't be used
> since generally PEM formatted certificates for truststore don't get encrypted
> with a password.
> # The PEMBasedSslContextFactory will internally create PKCS12 keystore for
> private key and the trusted certificates. However, this doesn't impact the
> user of the implementation in anyway and it is mentioned for clarity only.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16456) Add Plugin Support for CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-16456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418221#comment-17418221 ] Derek Chen-Becker commented on CASSANDRA-16456: --- Thanks, [~djoshi] , I had looked at https://issues.apache.org/jira/browse/CASSANDRA-11471 before but I think we can improve the proposal to allow for smoother migration. Let me add my comments there. I also agree that TLS client cert authentication can be a good mechanism, but I think this CEP allows for a more flexible CQLSH (and doesn't require PKI). > Add Plugin Support for CQLSH > > > Key: CASSANDRA-16456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16456 > Project: Cassandra > Issue Type: New Feature > Components: Tool/cqlsh >Reporter: Brian Houser >Priority: Normal > Labels: gsoc2021, mentor > > Currently the Cassandra drivers offer a plugin authenticator architecture for > the support of different authentication methods. This has been leveraged to > provide support for LDAP, Kerberos, and Sigv4 authentication. Unfortunately, > cqlsh, the included CLI tool, does not offer such support. Switching to a new > enhanced authentication scheme thus means being cut off from using cqlsh in > normal operation. > We should have a means of using the same plugins and authentication providers > as the Python Cassandra driver. > Here's a link to an initial draft of > [CEP|https://docs.google.com/document/d/1_G-OZCAEmDyuQuAN2wQUYUtZBEJpMkHWnkYELLhqvKc/edit?usp=sharing]. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
