[jira] [Commented] (CASSANDRA-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264665#comment-17264665
]
Michael Semb Wever commented on CASSANDRA-15889:
I missed any notifications from [~mattsplat] too. Apologies for that Matt!
[~e.dimitrova], we should test, confirm, and do the "in the meantime" as Matt
suggests four comments above.
I am curious how {{[arch=amd64]}} doesn't break it for any debian distribution
and architecture, like {{i386}}. But debian package management foo is weak here.
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Matt Davis
>Priority: Normal
> Labels: ARM, debian
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that there is a workaround available: if you specify "amd64" as the arch
> for the source, it downloads and runs on Arm without issue:
> {code:bash}
> echo "deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
> {code}
> The Redhat RPM contains a "noarch" arch type, so it will download on any
> host. (Cassandra does not use separate binaries/releases for different
> architectures, so this seems to be the correct approach, but adding an
> aarch64 variant would also suffice.)
--
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] [Updated] (CASSANDRA-16385) Correctly serialize all request responses - CASSANDRA-15946 followup
[ https://issues.apache.org/jira/browse/CASSANDRA-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-16385: - Test and Documentation Plan: Added test to demonstrated failure with patch that fixes it. Status: Patch Available (was: Open) [~ifesdjeen] [~jlewandowski] would you be able to take a look at this? > Correctly serialize all request responses - CASSANDRA-15946 followup > > > Key: CASSANDRA-16385 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16385 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > When receiving a message, a 4.0 dtest instance reserializes messages to pass > them through the dtest message filtering. > > The 4.0 internode messaging refactor does not expect to have to re-serialize > response > messages, so the workaround in CASSANDRA-15946 was just to register the > ReadResponse serializer for all REQUEST_RESPONSE messages, however request > response is used for other responses too. > I'm attaching a patch that demonstrates the issue by adding a simple Paxos > upgrade test to generate a PrepareResponse message that crashes the > ReadResponse serializer, then reverts CASSANDRA-15946 and re-users the > messaging service serialization method that checks the request callback if a > serializer is not defined. -- 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-16385) Correctly serialize all request responses - CASSANDRA-15946 followup
[ https://issues.apache.org/jira/browse/CASSANDRA-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264583#comment-17264583 ] Jon Meredith commented on CASSANDRA-16385: -- [Branch|http://https://github.com/jonmeredith/cassandra/tree/C16385] [PR|https://github.com/apache/cassandra/pull/868] [CircleCI|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=C16385] > Correctly serialize all request responses - CASSANDRA-15946 followup > > > Key: CASSANDRA-16385 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16385 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0-beta > > Time Spent: 10m > Remaining Estimate: 0h > > When receiving a message, a 4.0 dtest instance reserializes messages to pass > them through the dtest message filtering. > > The 4.0 internode messaging refactor does not expect to have to re-serialize > response > messages, so the workaround in CASSANDRA-15946 was just to register the > ReadResponse serializer for all REQUEST_RESPONSE messages, however request > response is used for other responses too. > I'm attaching a patch that demonstrates the issue by adding a simple Paxos > upgrade test to generate a PrepareResponse message that crashes the > ReadResponse serializer, then reverts CASSANDRA-15946 and re-users the > messaging service serialization method that checks the request callback if a > serializer is not defined. -- 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] [Updated] (CASSANDRA-16385) Correctly serialize all request responses - CASSANDRA-15946 followup
[ https://issues.apache.org/jira/browse/CASSANDRA-16385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jon Meredith updated CASSANDRA-16385: - Change Category: Quality Assurance Complexity: Normal Fix Version/s: 4.0-beta Status: Open (was: Triage Needed) > Correctly serialize all request responses - CASSANDRA-15946 followup > > > Key: CASSANDRA-16385 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16385 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Jon Meredith >Assignee: Jon Meredith >Priority: Normal > Fix For: 4.0-beta > > > When receiving a message, a 4.0 dtest instance reserializes messages to pass > them through the dtest message filtering. > > The 4.0 internode messaging refactor does not expect to have to re-serialize > response > messages, so the workaround in CASSANDRA-15946 was just to register the > ReadResponse serializer for all REQUEST_RESPONSE messages, however request > response is used for other responses too. > I'm attaching a patch that demonstrates the issue by adding a simple Paxos > upgrade test to generate a PrepareResponse message that crashes the > ReadResponse serializer, then reverts CASSANDRA-15946 and re-users the > messaging service serialization method that checks the request callback if a > serializer is not defined. -- 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] [Created] (CASSANDRA-16385) Correctly serialize all request responses - CASSANDRA-15946 followup
Jon Meredith created CASSANDRA-16385: Summary: Correctly serialize all request responses - CASSANDRA-15946 followup Key: CASSANDRA-16385 URL: https://issues.apache.org/jira/browse/CASSANDRA-16385 Project: Cassandra Issue Type: Improvement Components: Test/dtest/java Reporter: Jon Meredith Assignee: Jon Meredith When receiving a message, a 4.0 dtest instance reserializes messages to pass them through the dtest message filtering. The 4.0 internode messaging refactor does not expect to have to re-serialize response messages, so the workaround in CASSANDRA-15946 was just to register the ReadResponse serializer for all REQUEST_RESPONSE messages, however request response is used for other responses too. I'm attaching a patch that demonstrates the issue by adding a simple Paxos upgrade test to generate a PrepareResponse message that crashes the ReadResponse serializer, then reverts CASSANDRA-15946 and re-users the messaging service serialization method that checks the request callback if a serializer is not defined. -- 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] [Created] (CASSANDRA-16384) ant test fail on aarch64 platform
zhaorenhai created CASSANDRA-16384: -- Summary: ant test fail on aarch64 platform Key: CASSANDRA-16384 URL: https://issues.apache.org/jira/browse/CASSANDRA-16384 Project: Cassandra Issue Type: Bug Reporter: zhaorenhai Assignee: zhaorenhai When run ant; ant test on aarch64 platform, the ant test will fail on some tests, the log shows following: Caused by: java.io.FileNotFoundException: META-INF/native/libnetty_tcnative_linux_aarch_64.so at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:175) ... 44 common frames omitted Suppressed: java.lang.UnsatisfiedLinkError: no netty_tcnative_linux_aarch_64 in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:871) at java.lang.System.loadLibrary(System.java:1124) at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38) at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:351) at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:136) ... 44 common frames omitted Suppressed: java.lang.UnsatisfiedLinkError: no netty_tcnative_linux_aarch_64 in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1860) at java.lang.Runtime.loadLibrary0(Runtime.java:871) at java.lang.System.loadLibrary(System.java:1124) at io.netty.util.internal.NativeLibraryUtil.loadLibrary(NativeLibraryUtil.java:38) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at io.netty.util.internal.NativeLibraryLoader$1.run(NativeLibraryLoader.java:385) at java.security.AccessController.doPrivileged(Native Method) at io.netty.util.internal.NativeLibraryLoader.loadLibraryByHelper(NativeLibraryLoader.java:377) at io.netty.util.internal.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:341) I think the root cause is: https://github.com/netty/netty-tcnative/issues/571 [https://github.com/netty/netty-tcnative/issues/576] and the solution of tcnative: [https://github.com/netty/netty-tcnative/pull/572] [https://github.com/netty/netty-tcnative/pull/591] Later, I will submit a patch for this, that is upgrade the libnetty-tcnative's version to 2.0.36. Any suggestion? -- 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-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264562#comment-17264562
]
Matt Davis commented on CASSANDRA-15889:
No patch currently. Would be helpful to update the doc for now.
So far nobody has been familiar with the package build process, so there's been
no real effort to change it.
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Matt Davis
>Priority: Normal
> Labels: ARM, debian
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that there is a workaround available: if you specify "amd64" as the arch
> for the source, it downloads and runs on Arm without issue:
> {code:bash}
> echo "deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
> {code}
> The Redhat RPM contains a "noarch" arch type, so it will download on any
> host. (Cassandra does not use separate binaries/releases for different
> architectures, so this seems to be the correct approach, but adding an
> aarch64 variant would also suffice.)
--
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-15889) Debian package fails to download on Arm-based hosts
[
https://issues.apache.org/jira/browse/CASSANDRA-15889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264522#comment-17264522
]
Ekaterina Dimitrova commented on CASSANDRA-15889:
-
Hi [~mck], [~brandon.williams], [~mattsplat]
I just realized I missed this ticket.
Is anyone able to update me?
Update the doc? Or do we have a patch? Please advise
> Debian package fails to download on Arm-based hosts
> ---
>
> Key: CASSANDRA-15889
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15889
> Project: Cassandra
> Issue Type: Bug
> Components: Build
>Reporter: Matt Davis
>Priority: Normal
> Labels: ARM, debian
>
> Following the first three steps of the [Debian install
> process|https://cassandra.apache.org/download/], after an apt-get update
> you'll see this line:
> {code:bash}
> $ sudo apt-get update
> ...
> N: Skipping acquire of configured file 'main/binary-arm64/Packages' as
> repository 'https://downloads.apache.org/cassandra/debian 311x InRelease'
> doesn't support architecture 'arm64'
> {code}
> Checking the [Debian
> repo|https://dl.bintray.com/apache/cassandra/dists/311x/main/] confirms there
> is no aarch64 variant available.
> Should you then attempt to install Cassandra:
> {code:bash}
> $ sudo apt-get install cassandra
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package cassandra is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> E: Package 'cassandra' has no installation candidate
> {code}
> Note that there is a workaround available: if you specify "amd64" as the arch
> for the source, it downloads and runs on Arm without issue:
> {code:bash}
> echo "deb [arch=amd64] https://downloads.apache.org/cassandra/debian 311x
> main" | sudo tee -a /etc/apt/sources.list.d/cassandra.sources.list
> {code}
> The Redhat RPM contains a "noarch" arch type, so it will download on any
> host. (Cassandra does not use separate binaries/releases for different
> architectures, so this seems to be the correct approach, but adding an
> aarch64 variant would also suffice.)
--
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] [Updated] (CASSANDRA-15586) 4.0 quality testing: Cluster Setup and Maintenance
[ https://issues.apache.org/jira/browse/CASSANDRA-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-15586: Resolution: Resolved Status: Resolved (was: Open) > 4.0 quality testing: Cluster Setup and Maintenance > -- > > Key: CASSANDRA-15586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15586 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-rc > > > We want 4.0 to be easy for users to setup out of the box and just work. This > means having low friction when users download the Cassandra package and start > running it. For example, users should be able to easily configure and start > new 4.0 clusters and have tokens distributed evenly. Another example is > packaging, it should be easy to install Cassandra on all supported platforms > (e.g. packaging) and have Cassandra use standard platform integrations. -- 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-15586) 4.0 quality testing: Cluster Setup and Maintenance
[ https://issues.apache.org/jira/browse/CASSANDRA-15586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264521#comment-17264521 ] Ekaterina Dimitrova commented on CASSANDRA-15586: - * Windows scripts were removed - CASSANDRA-16171 * [https://cassandra.apache.org/download/] - links and names updated for the new version * RPM and Debian packages in place * FreeBSD port for 4.0: https://svnweb.freebsd.org/ports/head/databases/cassandra4/ > 4.0 quality testing: Cluster Setup and Maintenance > -- > > Key: CASSANDRA-15586 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15586 > Project: Cassandra > Issue Type: Task > Components: Test/dtest/python >Reporter: Josh McKenzie >Assignee: Ekaterina Dimitrova >Priority: Normal > Labels: 4.0-QA > Fix For: 4.0-rc > > > We want 4.0 to be easy for users to setup out of the box and just work. This > means having low friction when users download the Cassandra package and start > running it. For example, users should be able to easily configure and start > new 4.0 clusters and have tokens distributed evenly. Another example is > packaging, it should be easy to install Cassandra on all supported platforms > (e.g. packaging) and have Cassandra use standard platform integrations. -- 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-16001) Log name change required
[ https://issues.apache.org/jira/browse/CASSANDRA-16001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264520#comment-17264520 ] Ekaterina Dimitrova commented on CASSANDRA-16001: - False statement > Log name change required > > > Key: CASSANDRA-16001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16001 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Under Installing the RPM Packages, the currently created log Is > cassandra.log, not system.log -- 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] [Updated] (CASSANDRA-16001) Log name change required
[ https://issues.apache.org/jira/browse/CASSANDRA-16001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-16001: Resolution: Invalid Status: Resolved (was: Open) > Log name change required > > > Key: CASSANDRA-16001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16001 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Under Installing the RPM Packages, the currently created log Is > cassandra.log, not system.log -- 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] [Assigned] (CASSANDRA-16001) Log name change required
[ https://issues.apache.org/jira/browse/CASSANDRA-16001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova reassigned CASSANDRA-16001: --- Assignee: Ekaterina Dimitrova > Log name change required > > > Key: CASSANDRA-16001 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16001 > Project: Cassandra > Issue Type: Bug > Components: Packaging >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > > Under Installing the RPM Packages, the currently created log Is > cassandra.log, not system.log -- 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-16261) Prevent unbounded number of flushing tasks
[ https://issues.apache.org/jira/browse/CASSANDRA-16261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264512#comment-17264512 ] Ekaterina Dimitrova commented on CASSANDRA-16261: - Thank you both for your deep reviews and great suggestions. 3.0 is squashed and I propagated the changes to 3.11 and trunk. I just started Jenkins runs too. [3.0 PR |https://github.com/ekaterinadimitrova2/cassandra/pull/81] | [Jenkins run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/286/] [3.11 PR |https://github.com/ekaterinadimitrova2/cassandra/pull/83] | [Jenkins run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/284/] [trunk PR |https://github.com/ekaterinadimitrova2/cassandra/pull/83] | [Jenkins run |https://jenkins-cm4.apache.org/job/Cassandra-devbranch/285/] /CC [~lor...@datastax.com] - this is the ticket we discussed offline. The new metric that needs to be documented is PendingFlushTasks. I believe the Metrics doc needs also other updates so maybe contact me when you start working on it and I can help there with revision, at least. > Prevent unbounded number of flushing tasks > -- > > Key: CASSANDRA-16261 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16261 > Project: Cassandra > Issue Type: Bug > Components: Legacy/Local Write-Read Paths >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.0-beta > > > The cleaner thread is not prevented from queueing an unbounded number of > flushing tasks for memtables that are almost empty. > This patch adds a mechanism to track the number of pending flushing > tasks in the memtable cleaner. Above the maximum number (2x the flushing > threads by default), only memtables using at least MCT memory will be > flushed, where MCT stands for Memory Cleanup Threshold. > This patch also fixes a possible problem tracking the memory marked as > "reclaiming" in the memtable allocators and pool. Writes that complete > only after a memtable has been scheduled for flushing, did not report > their memory as reclaiming. Normally this should be a small value of no > consequence, but if the flushing tasks are blocked for a long period, > and there is a sufficient number of writes, or these writes use > a sufficiently large quantity of memory, this would cause the memtable > cleaning algorithm to schedule repeated flushing tasks because the used > memory is always > reclaiming memory + MCT. -- 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] [Comment Edited] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264448#comment-17264448
]
Michael Semb Wever edited comment on CASSANDRA-16383 at 1/13/21, 10:00 PM:
---
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/12/
[~aholmber], I'm +1 on the ccm merge patch, if the above CI results look ok.
And after you have merged it, I can delete the {{cassandra-test}} branch, and
tag master HEAD with the same name.
was (Author: michaelsembwever):
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/12/
[~aholmber], I'm +1 on the ccm merge patch, if the above CI results look ok.
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises', and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date, AFAIK no merges between the branches have occurred since January
> 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Comment Edited] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264448#comment-17264448
]
Michael Semb Wever edited comment on CASSANDRA-16383 at 1/13/21, 9:58 PM:
--
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/12/
[~aholmber], I'm +1 on the ccm merge patch, if the above CI results look ok.
was (Author: michaelsembwever):
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/12/
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises', and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date, AFAIK no merges between the branches have occurred since January
> 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264448#comment-17264448
]
Michael Semb Wever commented on CASSANDRA-16383:
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/12/
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises', and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date, AFAIK no merges between the branches have occurred since January
> 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Comment Edited] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264448#comment-17264448
]
Michael Semb Wever edited comment on CASSANDRA-16383 at 1/13/21, 9:50 PM:
--
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/job/Cassandra-devbranch-dtest-upgrade/12/
was (Author: michaelsembwever):
ci-cassandra.a.o
- pipeline ::
https://ci-cassandra.apache.org/blue/organizations/jenkins/Cassandra-devbranch/detail/Cassandra-devbranch/283/
- dtest-upgrade ::
https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-dtest-upgrade/12/
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises', and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date, AFAIK no merges between the branches have occurred since January
> 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Updated] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16383:
---
Description:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises', and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date, AFAIK no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push -f origin --tags
{code}
was:
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises, and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push -f origin --tags
{code}
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest
[jira] [Commented] (CASSANDRA-16369) JaCoCo reports on all unit test jobs on ci-cassandra.a.o
[ https://issues.apache.org/jira/browse/CASSANDRA-16369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264442#comment-17264442 ] Michael Semb Wever commented on CASSANDRA-16369: This will add ~100M to each build on the jenkins master. See https://issues.apache.org/jira/secure/attachment/13018718/tree.txt > JaCoCo reports on all unit test jobs on ci-cassandra.a.o > > > Key: CASSANDRA-16369 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16369 > Project: Cassandra > Issue Type: Task > Components: CI >Reporter: Michael Semb Wever >Assignee: Michael Semb Wever >Priority: Normal > Attachments: Screenshot 2020-12-24 at 14.23.13.png, Screenshot > 2020-12-24 at 14.23.57.png > > > Enable the jenkins [jacoco plugin|https://plugins.jenkins.io/jacoco/] and > wrap all test runs with jacoco. > Patch at > https://github.com/apache/cassandra-builds/compare/trunk...thelastpickle:mck/tests_jacoco > Example results are: > - CI build: > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/149/ > - CI JaCoCo report: > https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch-test/149/jdk=jdk_1.8_latest,label=cassandra/jacoco/ -- 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
[cassandra-builds] branch trunk updated: In Jenkins don't archive all the TEST xml files (INFRA-21307)
This is an automated email from the ASF dual-hosted git repository.
mck pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra-builds.git
The following commit(s) were added to refs/heads/trunk by this push:
new 0c4d69f In Jenkins don't archive all the TEST xml files (INFRA-21307)
0c4d69f is described below
commit 0c4d69ff416b1d08c15bfaab20010252c825b4b5
Author: Mick Semb Wever
AuthorDate: Wed Jan 13 22:26:11 2021 +0100
In Jenkins don't archive all the TEST xml files (INFRA-21307)
---
jenkins-dsl/cassandra_job_dsl_seed.groovy | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/jenkins-dsl/cassandra_job_dsl_seed.groovy
b/jenkins-dsl/cassandra_job_dsl_seed.groovy
index 2b5eca6..670adbe 100644
--- a/jenkins-dsl/cassandra_job_dsl_seed.groovy
+++ b/jenkins-dsl/cassandra_job_dsl_seed.groovy
@@ -241,7 +241,7 @@ matrixJob('Cassandra-template-test') {
}
publishers {
archiveArtifacts {
-pattern('build/test/**/TEST-*.xml, **/*.head')
+pattern('**/*.head')
allowEmpty()
fingerprint()
}
@@ -797,7 +797,7 @@ testTargets.each {
failOnError(false)
}
archiveArtifacts {
-pattern('build/test/**/TEST-*.xml, **/*.head')
+pattern('**/*.head')
allowEmpty()
fingerprint()
}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264426#comment-17264426
]
Adam Holmberg commented on CASSANDRA-16383:
---
CI looks good to me. First run had a couple of apparently unrelated failures
that did not repro locally. Second run was clean for all tests relying on ccm.
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Comment Edited] (CASSANDRA-15985) python dtest TestCqlsh added enable_scripted_user_defined_functions which breaks on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264377#comment-17264377
]
Aleksandr Sorokoumov edited comment on CASSANDRA-15985 at 1/13/21, 7:30 PM:
|Branch||Source||
|2.2|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...Ge:15985-2.2]|
|dtests|[branch|https://github.com/apache/cassandra-dtest/compare/trunk...Ge:CASSANDRA-15985]|
These changes fix the Invalid yaml error as well as
TestCqlsh#test_pycodestyle_compliance.
There are still 2 kinds of test failures left in test_cqlsh.py:
*
[TestCqlsh#test_unicode_invalid_request_error|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L533],
[TestCqlsh#test_unicode_syntax_error|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L516],
[TestCqlLogin#test_login_rejects_bad_pass|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L2459],
[TestCqlLogin#test_login_allows_bad_pass_and_continued_use|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L2503].
These tests fail because cassandra 2.2 does not throw ToolError, although the
requests return correct error messages.
*
[TestCqlsh#test_describe_functions|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L869],
[TestCqlsh#test_describe_types|https://github.com/apache/cassandra-dtest/blob/6d9209e21cd13d5ee0317e9647ec851df1de465e/cqlsh_tests/test_cqlsh.py#L962].
They fail because DESCRIBE in 2.2 does not add a semicolon at the end of the
statement.
Both of them require changes in behavior and as 2.2 is marked as for Critical
bug fixes only, I was not sure how we want to approach them. I can either adapt
the tests to verify current behavior or actually fix it. WDYT [~dcapwell]?
was (Author: ge):
|Branch||Source||
|2.2|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...Ge:15985-2.2]|
|dtests|[branch|https://github.com/apache/cassandra-dtest/compare/trunk...Ge:CASSANDRA-15985]|
These changes fix the Invalid yaml error as well as
TestCqlsh#test_pycodestyle_compliance.
There are still 2 kinds of test failures left in test_cqlsh.py:
TestCqlsh#test_unicode_invalid_request_error,
TestCqlsh#test_unicode_syntax_error, TestCqlLogin#test_login_rejects_bad_pass,
TestCqlLogin#test_login_allows_bad_pass_and_continued_use. These tests fail
because cassandra 2.2 does not throw ToolError, although the requests return
correct error messages.
TestCqlsh#test_describe_functions, TestCqlsh#test_describe_types. They fail
because DESCRIBE in 2.2 does not add a semicolon at the end of the statement.
Both of them require changes in behavior and as 2.2 is marked as for Critical
bug fixes only, I was not sure how we want to approach them. I can either adapt
the tests to verify current behavior or actually fix it. WDYT [~dcapwell]?
> python dtest TestCqlsh added enable_scripted_user_defined_functions which
> breaks on 2.2
> ---
>
> Key: CASSANDRA-15985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15985
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 2.2.x
>
>
> {code}
> ERROR [main] 2020-07-26 03:03:14,108 CassandraDaemon.java:744 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please
> remove properties [enable_scripted_user_defined_functions] from your
> cassandra.yaml
> at
> org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:146)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:113)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:151)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:133)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:604)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:731)
> [main/:na]]
> {code}
> This test doesn’t put a version limit, so all tests fail on 2.2 since the
> property was added to
[jira] [Comment Edited] (CASSANDRA-15985) python dtest TestCqlsh added enable_scripted_user_defined_functions which breaks on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264377#comment-17264377
]
Aleksandr Sorokoumov edited comment on CASSANDRA-15985 at 1/13/21, 7:28 PM:
|Branch||Source||
|2.2|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...Ge:15985-2.2]|
|dtests|[branch|https://github.com/apache/cassandra-dtest/compare/trunk...Ge:CASSANDRA-15985]|
These changes fix the Invalid yaml error as well as
TestCqlsh#test_pycodestyle_compliance.
There are still 2 kinds of test failures left in test_cqlsh.py:
TestCqlsh#test_unicode_invalid_request_error,
TestCqlsh#test_unicode_syntax_error, TestCqlLogin#test_login_rejects_bad_pass,
TestCqlLogin#test_login_allows_bad_pass_and_continued_use. These tests fail
because cassandra 2.2 does not throw ToolError, although the requests return
correct error messages.
TestCqlsh#test_describe_functions, TestCqlsh#test_describe_types. They fail
because DESCRIBE in 2.2 does not add a semicolon at the end of the statement.
Both of them require changes in behavior and as 2.2 is marked as for Critical
bug fixes only, I was not sure how we want to approach them. I can either adapt
the tests to verify current behavior or actually fix it. WDYT [~dcapwell]?
was (Author: ge):
|Branch||Source||
|2.2|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...Ge:15985-2.2]|
|dtests|[branch|https://github.com/apache/cassandra-dtest/compare/trunk...Ge:CASSANDRA-15985]|
These changes fix the Invalid yaml error as well as
TestCqlsh#test_pycodestyle_compliance.
There are still 2 kinds of test failures left in test_cqlsh.py:
TestCqlsh#test_unicode_invalid_request_error,
TestCqlsh#test_unicode_syntax_error, TestCqlLogin#test_login_rejects_bad_pass,
TestCqlLogin#test_login_allows_bad_pass_and_continued_use. These tests fail
because cassandra 2.2 does not throw ToolError, although the requests return
correct error messages.
TestCqlsh#test_describe_functions, TestCqlsh#test_describe_types. They fail
because DESCRIBE in 2.2 does not add a semicolon at the end of the statement.
Both of them require changes in behavior and as 2.2 is marked as for Critical
bug fixes only, I was not sure how we want to approach them. I can either adapt
the tests to verify current behavior or actually fix it. WDYT David Capwell?
> python dtest TestCqlsh added enable_scripted_user_defined_functions which
> breaks on 2.2
> ---
>
> Key: CASSANDRA-15985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15985
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 2.2.x
>
>
> {code}
> ERROR [main] 2020-07-26 03:03:14,108 CassandraDaemon.java:744 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please
> remove properties [enable_scripted_user_defined_functions] from your
> cassandra.yaml
> at
> org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:146)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:113)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:151)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:133)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:604)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:731)
> [main/:na]]
> {code}
> This test doesn’t put a version limit, so all tests fail on 2.2 since the
> property was added to all clusters.
--
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] [Updated] (CASSANDRA-15985) python dtest TestCqlsh added enable_scripted_user_defined_functions which breaks on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov updated CASSANDRA-15985:
-
Test and Documentation Plan: .
Status: Patch Available (was: In Progress)
|Branch||Source||
|2.2|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...Ge:15985-2.2]|
|dtests|[branch|https://github.com/apache/cassandra-dtest/compare/trunk...Ge:CASSANDRA-15985]|
These changes fix the Invalid yaml error as well as
TestCqlsh#test_pycodestyle_compliance.
There are still 2 kinds of test failures left in test_cqlsh.py:
TestCqlsh#test_unicode_invalid_request_error,
TestCqlsh#test_unicode_syntax_error, TestCqlLogin#test_login_rejects_bad_pass,
TestCqlLogin#test_login_allows_bad_pass_and_continued_use. These tests fail
because cassandra 2.2 does not throw ToolError, although the requests return
correct error messages.
TestCqlsh#test_describe_functions, TestCqlsh#test_describe_types. They fail
because DESCRIBE in 2.2 does not add a semicolon at the end of the statement.
Both of them require changes in behavior and as 2.2 is marked as for Critical
bug fixes only, I was not sure how we want to approach them. I can either adapt
the tests to verify current behavior or actually fix it. WDYT David Capwell?
> python dtest TestCqlsh added enable_scripted_user_defined_functions which
> breaks on 2.2
> ---
>
> Key: CASSANDRA-15985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15985
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 2.2.x
>
>
> {code}
> ERROR [main] 2020-07-26 03:03:14,108 CassandraDaemon.java:744 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please
> remove properties [enable_scripted_user_defined_functions] from your
> cassandra.yaml
> at
> org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:146)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:113)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:151)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:133)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:604)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:731)
> [main/:na]]
> {code}
> This test doesn’t put a version limit, so all tests fail on 2.2 since the
> property was added to all clusters.
--
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] [Assigned] (CASSANDRA-15985) python dtest TestCqlsh added enable_scripted_user_defined_functions which breaks on 2.2
[
https://issues.apache.org/jira/browse/CASSANDRA-15985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Sorokoumov reassigned CASSANDRA-15985:
Assignee: Aleksandr Sorokoumov
> python dtest TestCqlsh added enable_scripted_user_defined_functions which
> breaks on 2.2
> ---
>
> Key: CASSANDRA-15985
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15985
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/python
>Reporter: David Capwell
>Assignee: Aleksandr Sorokoumov
>Priority: Normal
> Fix For: 2.2.x
>
>
> {code}
> ERROR [main] 2020-07-26 03:03:14,108 CassandraDaemon.java:744 - Exception
> encountered during startup
> org.apache.cassandra.exceptions.ConfigurationException: Invalid yaml. Please
> remove properties [enable_scripted_user_defined_functions] from your
> cassandra.yaml
> at
> org.apache.cassandra.config.YamlConfigurationLoader$MissingPropertiesChecker.check(YamlConfigurationLoader.java:146)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:113)
> ~[main/:na]
> at
> org.apache.cassandra.config.YamlConfigurationLoader.loadConfig(YamlConfigurationLoader.java:85)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.loadConfig(DatabaseDescriptor.java:151)
> ~[main/:na]
> at
> org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:133)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:604)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:731)
> [main/:na]]
> {code}
> This test doesn’t put a version limit, so all tests fail on 2.2 since the
> property was added to all clusters.
--
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-16290) Consistency can be violated when bootstrap or decommission is resumed after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264363#comment-17264363
]
Brandon Williams commented on CASSANDRA-16290:
--
+1 to that, fixvers updated.
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
>
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
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] [Updated] (CASSANDRA-16290) Consistency can be violated when bootstrap or decommission is resumed after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams updated CASSANDRA-16290:
-
Fix Version/s: (was: 4.0-beta)
4.0.x
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
>
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
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-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264359#comment-17264359
]
Michael Semb Wever commented on CASSANDRA-16383:
Any objections to this approach [~spod], [~ptnapoleon] ?
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Updated] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Holmberg updated CASSANDRA-16383:
--
Change Category: Quality Assurance
Complexity: Normal
Status: Open (was: Triage Needed)
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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-16290) Consistency can be violated when bootstrap or decommission is resumed after node restart
[
https://issues.apache.org/jira/browse/CASSANDRA-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264328#comment-17264328
]
Jon Meredith commented on CASSANDRA-16290:
--
Given this is a longstanding issue, I don't think it should be a blocker for
4.0 release. Could we move it out to 4.0.x and not consider it a blocker for
getting to a 4.0 RC?
> Consistency can be violated when bootstrap or decommission is resumed after
> node restart
>
>
> Key: CASSANDRA-16290
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16290
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Bootstrap and Decommission
>Reporter: Paulo Motta
>Assignee: Paulo Motta
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-beta
>
>
> Since CASSANDRA-12008, successfully transferred ranges during decommission
> are saved on the {{system.transferred_ranges}} table. This allow skipping
> ranges already transferred when a failed decommission is retried with
> {{nodetool decommission}}.
> If instead of resuming the decommission, an operator restarts the node, waits
> N minutes and then performs a new decommission, the previously transferred
> ranges will be skipped during streaming, and any writes received by the
> decommissioned node during these N minutes will not be replicated to the new
> range owner, what violates consistency.
> This issue is analogous to the issue mentioned [on this
> comment|https://issues.apache.org/jira/browse/CASSANDRA-8838?focusedCommentId=16900234=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16900234]
> for resumable bootstrap (CASSANDRA-8838).
> In order to prevent consistency violations we should clear the
> {{system.transferred_ranges}} state during node restart, and maybe a system
> property to disable it. While we're at this, we should change the default of
> {{-Dcassandra.reset_bootstrap_progress}} to {{true}} to clear the
> {{system.available_ranges}} state by default when a bootstrapping node is
> restarted.
--
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] [Comment Edited] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264323#comment-17264323
]
Adam Holmberg edited comment on CASSANDRA-16383 at 1/13/21, 6:02 PM:
-
+1 this approach. I've merged {{cassandra-test}} into {{master}} and created a
pull request [here|https://github.com/riptano/ccm/pull/723]. In-tree tests
pass. Running CI with the merged branch
[here|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16383].
was (Author: aholmber):
+1 this approach. I've merged {{cassandra-test}} into {{master}} and created a
pull request [here|https://github.com/riptano/ccm/pull/723]. Running CI with
the merged branch
[here|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16383].
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264323#comment-17264323
]
Adam Holmberg commented on CASSANDRA-16383:
---
+1 this approach. I've merged {{cassandra-test}} into {{master}} and created a
pull request [here|https://github.com/riptano/ccm/pull/723]. Running CI with
the merged branch
[here|https://app.circleci.com/pipelines/github/aholmberg/cassandra?branch=CASSANDRA-16383].
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Updated] (CASSANDRA-16236) Fix flaky testTrackMaxDeletionTime
[ https://issues.apache.org/jira/browse/CASSANDRA-16236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-16236: - Resolution: Cannot Reproduce Status: Resolved (was: Open) Closing this since it has never been seen again and there is nothing actionable. Please reopen if this recurs. > Fix flaky testTrackMaxDeletionTime > -- > > Key: CASSANDRA-16236 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16236 > Project: Cassandra > Issue Type: Bug > Components: Test/unit >Reporter: Brandon Williams >Assignee: Brandon Williams >Priority: Normal > Fix For: 4.0-beta > > > * > testTrackMaxDeletionTime - org.apache.cassandra.io.sstable.SSTableMetadataTest > > junit.framework.AssertionFailedError: expected:<1.6038784E9> but > was:<1.60387827E9> > at > org.apache.cassandra.io.sstable.SSTableMetadataTest.testTrackMaxDeletionTime(SSTableMetadataTest.java:102) > https://app.circleci.com/pipelines/github/bereng/cassandra/160/workflows/6cb80410-b398-477c-b4c9-cc7369785869/jobs/1317 -- 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] [Assigned] (CASSANDRA-16229) Flaky jvm-dtest: org.apache.cassandra.distributed.test.ring.NodeNotInRingTest.nodeNotInRingTest
[
https://issues.apache.org/jira/browse/CASSANDRA-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-16229:
Assignee: Brandon Williams
> Flaky jvm-dtest:
> org.apache.cassandra.distributed.test.ring.NodeNotInRingTest.nodeNotInRingTest
> ---
>
> Key: CASSANDRA-16229
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16229
> Project: Cassandra
> Issue Type: Bug
> Components: Test/dtest/java
>Reporter: Yifan Cai
>Assignee: Brandon Williams
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Test failed during CI build. Stack trace attached below,
> [https://app.circleci.com/pipelines/github/yifan-c/cassandra/135/workflows/371dee8e-36d2-41a1-b27f-f7578496a1fe/jobs/681]
> {code:java}
> Testcase:
> nodeNotInRingTest(org.apache.cassandra.distributed.test.ring.NodeNotInRingTest):
> FAILED
> expected:<86> but was:<100>
> junit.framework.AssertionFailedError: expected:<86> but was:<100>
> at
> org.apache.cassandra.distributed.test.ring.NodeNotInRingTest.nodeNotInRingTest(NodeNotInRingTest.java:60)
> 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){code}
> Besides the flakiness, the expected and the actual values are swapped in the
> assertion statement.
--
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] [Updated] (CASSANDRA-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16286:
Fix Version/s: (was: 4.0-beta)
4.0
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 4.0, 3.0.x, 3.11.x
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
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] [Updated] (CASSANDRA-16286) Make TokenMetadata's ring version increments atomic
[
https://issues.apache.org/jira/browse/CASSANDRA-16286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Caleb Rackliffe updated CASSANDRA-16286:
Fix Version/s: (was: 4.0)
4.0-rc
> Make TokenMetadata's ring version increments atomic
> ---
>
> Key: CASSANDRA-16286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16286
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Gossip
>Reporter: Caleb Rackliffe
>Assignee: Caleb Rackliffe
>Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0-rc
>
>
> The update semantics of the ring version in {{TokenMetadata}} are not clear.
> The instance variable itself is {{volatile}}, but it is still incremented by
> a non-atomic check-and-set, and not all codepaths do that while holding the
> {{TokenMetadata}} write lock. We could make this more intelligible by forcing
> the external callers to use both the write when invalidating the ring and
> read lock when reading the current ring version. Most of the readers of the
> ring version (ex. compaction) don't need it to be fast, but it shouldn't be a
> problem even if they do. If we do this, we should be able to avoid a
> situation where concurrent invalidations don't produce two distinct version
> increments.
--
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] [Updated] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
[
https://issues.apache.org/jira/browse/CASSANDRA-16383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Semb Wever updated CASSANDRA-16383:
---
Fix Version/s: 4.0-beta
> Python dtests to use ccm tag instead of the `cassandra-test` branch
> ---
>
> Key: CASSANDRA-16383
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/python
>Reporter: Michael Semb Wever
>Assignee: Michael Semb Wever
>Priority: Normal
> Fix For: 4.0-beta
>
>
> The python dtests (cassandra-dtest repo) creates its clusters using ccm.
> The version of ccm it uses is the HEAD of the {{cassandra-test}} branch.
> This is referenced in the
> [requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
> The history for why a separate branch of ccm is used by dtests is explained
> in https://github.com/apache/cassandra-dtest/pull/13
> Long story short: the separate branch avoids two headaches
> - the 'latest commit to master' broke all the c* builds surprises, and
> - the 'i have to cut a release of ccm just to get a ccm change into use by
> dtests'
> But the two branches: {{master}} and {{cassandra-test}}; have effectively
> been treated as two separate repositories, with (non-fast-forward) merges
> happening in both directions. This makes the git history of both branches
> messy and difficult to use, and it makes the merge strategy confusing.
> Bi-directional merging between branches is considered a poor practice by many
> (Laura Wingerd's 'The Flow of Change'
> [presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
> and
> [book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
> refers to this as "don't drive through hedges" and encourages the "merge
> down, copy up" approach against the "tofu scale: firm above, soft below").
> To date no merges between the branches have occurred since January 2018.
> A possible improvement to this process is to replace the {{cassandra-test}}
> branch with a floating tag (of the same name).
> That way new commits to {{master}} are not automatically used by the python
> dtests. And changes made to ccm and intended/needed to be used by the dtests
> can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
> The re-tagging approach is
> {code}
> git tag -a -f cassandra-test
> git push origin :refs/tags/cassandra-test
> git push -f origin --tags
> {code}
--
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] [Created] (CASSANDRA-16383) Python dtests to use ccm tag instead of the `cassandra-test` branch
Michael Semb Wever created CASSANDRA-16383:
--
Summary: Python dtests to use ccm tag instead of the
`cassandra-test` branch
Key: CASSANDRA-16383
URL: https://issues.apache.org/jira/browse/CASSANDRA-16383
Project: Cassandra
Issue Type: Task
Components: Test/dtest/python
Reporter: Michael Semb Wever
Assignee: Michael Semb Wever
The python dtests (cassandra-dtest repo) creates its clusters using ccm.
The version of ccm it uses is the HEAD of the {{cassandra-test}} branch. This
is referenced in the
[requirements.txt|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L3].
The history for why a separate branch of ccm is used by dtests is explained in
https://github.com/apache/cassandra-dtest/pull/13
Long story short: the separate branch avoids two headaches
- the 'latest commit to master' broke all the c* builds surprises, and
- the 'i have to cut a release of ccm just to get a ccm change into use by
dtests'
But the two branches: {{master}} and {{cassandra-test}}; have effectively been
treated as two separate repositories, with (non-fast-forward) merges happening
in both directions. This makes the git history of both branches messy and
difficult to use, and it makes the merge strategy confusing. Bi-directional
merging between branches is considered a poor practice by many (Laura Wingerd's
'The Flow of Change'
[presentation|https://www.perforce.com/sites/default/files/flow-change-wingerd.pdf]
and
[book|https://books.google.no/books?id=mlm61wb2v3MC=PT191=PT191=%22don%27t+drive+through+hedges%22=bl=I_rYBRJwTD=ACfU3U1iKLORDQii5uiTveaKPOpa3cFqng=en=X=2ahUKEwju96-DpZnuAhWytYsKHeW6D5EQ6AEwAHoECAEQAg#v=onepage=%22don't%20drive%20through%20hedges%22=false]
refers to this as "don't drive through hedges" and encourages the "merge down,
copy up" approach against the "tofu scale: firm above, soft below").
To date no merges between the branches have occurred since January 2018.
A possible improvement to this process is to replace the {{cassandra-test}}
branch with a floating tag (of the same name).
That way new commits to {{master}} are not automatically used by the python
dtests. And changes made to ccm and intended/needed to be used by the dtests
can be put in use by re-tagging {{cassandra-test}} to master's HEAD.
The re-tagging approach is
{code}
git tag -a -f cassandra-test
git push origin :refs/tags/cassandra-test
git push -f origin --tags
{code}
--
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] [Updated] (CASSANDRA-16287) Make relocate dependencies script less manual
[ https://issues.apache.org/jira/browse/CASSANDRA-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16287: Fix Version/s: 4.0-beta5 Source Control Link: https://github.com/apache/cassandra/commit/2355c3769472eb8d6542d8cb3838e4f5536f0430 Resolution: Fixed Status: Resolved (was: Ready to Commit) > Make relocate dependencies script less manual > - > > Key: CASSANDRA-16287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16287 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > Fix For: 4.0-beta5 > > > Allow relocate-dependencies script to pick up Cassandra and in-JVM dtest > versions from pom and build.xml correspondingly instead of entering them > manually. -- 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] [Updated] (CASSANDRA-16287) Make relocate dependencies script less manual
[ https://issues.apache.org/jira/browse/CASSANDRA-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Petrov updated CASSANDRA-16287: Status: Ready to Commit (was: Review In Progress) > Make relocate dependencies script less manual > - > > Key: CASSANDRA-16287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16287 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Allow relocate-dependencies script to pick up Cassandra and in-JVM dtest > versions from pom and build.xml correspondingly instead of entering them > manually. -- 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-16287) Make relocate dependencies script less manual
[ https://issues.apache.org/jira/browse/CASSANDRA-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264204#comment-17264204 ] Alex Petrov commented on CASSANDRA-16287: - Thank you for the review! Committed to trunk with [2355c3769472eb8d6542d8cb3838e4f5536f0430|https://github.com/apache/cassandra/commit/2355c3769472eb8d6542d8cb3838e4f5536f0430]. > Make relocate dependencies script less manual > - > > Key: CASSANDRA-16287 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16287 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java >Reporter: Alex Petrov >Assignee: Alex Petrov >Priority: Normal > > Allow relocate-dependencies script to pick up Cassandra and in-JVM dtest > versions from pom and build.xml correspondingly instead of entering them > manually. -- 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
[cassandra] branch trunk updated: Make relocate dependencies script less manual
This is an automated email from the ASF dual-hosted git repository.
ifesdjeen pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/cassandra.git
The following commit(s) were added to refs/heads/trunk by this push:
new 2355c37 Make relocate dependencies script less manual
2355c37 is described below
commit 2355c3769472eb8d6542d8cb3838e4f5536f0430
Author: Alex Petrov
AuthorDate: Thu Nov 19 17:09:51 2020 +0100
Make relocate dependencies script less manual
Patch by Alex Petrov; reviewed by Ekaterina Dimitrova and David Capwell for
CASSANDRA-16287
---
build-shaded-dtest-jar.sh | 12 +++-
relocate-dependencies.pom | 3 ++-
2 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/build-shaded-dtest-jar.sh b/build-shaded-dtest-jar.sh
index efedcaa..b35ec47 100755
--- a/build-shaded-dtest-jar.sh
+++ b/build-shaded-dtest-jar.sh
@@ -2,12 +2,14 @@
set -xe
-# Cassandra version that is specified in build.xml
-CASSANDRA_VERSION=$1
-# In-JVM dtest version that is specified in relocate-dependencies.pom
-DTEST_VERSION=$2
ARTIFACT_NAME=cassandra-dtest
REPO_DIR=~/.m2/repository
+CASSANDRA_VERSION=$(cat build.xml | grep 'property name="base.version"' | awk
-F "\"" '{print $4}')
+DTEST_VERSION=$(cat relocate-dependencies.pom | grep "dtest-local.version>" |
awk -F "\>|\<" '{print $3}')
+SHADED_DTEST_VERSION=$(cat relocate-dependencies.pom | grep -m 1 "" |
awk -F "\>|\<" '{print $3}')
+
+echo $CASSANDRA_VERSION
+echo $DTEST_VERSION
ant clean
ant dtest-jar
@@ -27,7 +29,7 @@ mvn -f relocate-dependencies.pom package -DskipTests -nsu
# Deploy shaded artifact
mvn install:install-file \
- -Dfile=./target/${ARTIFACT_NAME}-shaded-${DTEST_VERSION}.jar \
+ -Dfile=./target/${ARTIFACT_NAME}-shaded-${SHADED_DTEST_VERSION}.jar \
-DgroupId=org.apache.cassandra\
-DartifactId=${ARTIFACT_NAME}-shaded \
-Dversion=${DTEST_VERSION}\
diff --git a/relocate-dependencies.pom b/relocate-dependencies.pom
index 0e5eabc..d6b4265 100644
--- a/relocate-dependencies.pom
+++ b/relocate-dependencies.pom
@@ -19,6 +19,7 @@
4.12
${java.version}
${java.version}
+4.0.0-SNAPSHOT
@@ -26,7 +27,7 @@
org.apache.cassandra
cassandra-dtest-local
-4.0.0-SNAPSHOT
+${dtest-local.version}
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-16376) Response headers to OPTION messages always have Stream ID of zero
[ https://issues.apache.org/jira/browse/CASSANDRA-16376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17264136#comment-17264136 ] Paulius Bankauskas commented on CASSANDRA-16376: [~samt] I've tried the patch with a local build and this problem no longer occurs. Thanks! > Response headers to OPTION messages always have Stream ID of zero > -- > > Key: CASSANDRA-16376 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16376 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Paulius Bankauskas >Priority: Normal > Fix For: 4.0-beta > > Attachments: cass-dump.pcap > > > It seems that streaming behavior has changed since version 4.0-beta2. When a > new connection is made, all responses to the OPTIONS messages always return > with stream id 0 even if requests are made with stream id 1. This causes > connection failures on some clients. > Attached wireshark dump with an example. > > Node version: 4.0-beta4 > Native protocol version: tested with v3 and v4 -- 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] [Updated] (CASSANDRA-16376) Response headers to OPTION messages always have Stream ID of zero
[ https://issues.apache.org/jira/browse/CASSANDRA-16376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Tunnicliffe updated CASSANDRA-16376: Authors: Sam Tunnicliffe Test and Documentation Plan: Added unit test covering all supported protocol versions. Status: Patch Available (was: Open) The fix is really trivial, just an oversight in the handler which takes care of initial protocol negotiation. I've added a unit test which checks the stream ids across the negotiation process for all supported versions. [~pauliusb] if you're able to test with a dev build, please give it a try & thanks for the report. ||branch||Circle CI|Apache CI| |[16376-trunk|https://github.com/beobal/cassandra/tree/16376-trunk]|[circle|https://circleci.com/gh/beobal/cassandra?branch=16376-trunk]|[apache|https://ci-cassandra.apache.org/view/patches/job/Cassandra-devbranch/283]| > Response headers to OPTION messages always have Stream ID of zero > -- > > Key: CASSANDRA-16376 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16376 > Project: Cassandra > Issue Type: Bug > Components: Messaging/Client >Reporter: Paulius Bankauskas >Priority: Normal > Fix For: 4.0-beta > > Attachments: cass-dump.pcap > > > It seems that streaming behavior has changed since version 4.0-beta2. When a > new connection is made, all responses to the OPTIONS messages always return > with stream id 0 even if requests are made with stream id 1. This causes > connection failures on some clients. > Attached wireshark dump with an example. > > Node version: 4.0-beta4 > Native protocol version: tested with v3 and v4 -- 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] [Updated] (CASSANDRA-16188) Add more tests to cover Keyspace and Table metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16188: --- Test and Documentation Plan: Add new tests Status: Patch Available (was: In Progress) > Add more tests to cover Keyspace and Table metrics > --- > > Key: CASSANDRA-16188 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16188 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java, Test/unit >Reporter: Benjamin Lerer >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.0-rc > > > Several Keyspace and Table related metrics are currently not tested. -- 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] [Updated] (CASSANDRA-16216) Add tests to cover ClientMetrics metrics
[ https://issues.apache.org/jira/browse/CASSANDRA-16216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Lerer updated CASSANDRA-16216: --- Test and Documentation Plan: New unit tests Status: Patch Available (was: In Progress) > Add tests to cover ClientMetrics metrics > > > Key: CASSANDRA-16216 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16216 > Project: Cassandra > Issue Type: Improvement > Components: Test/dtest/java, Test/unit >Reporter: Sumanth Pasupuleti >Assignee: Sumanth Pasupuleti >Priority: Normal > Fix For: 4.0-rc > > -- 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] [Updated] (CASSANDRA-15587) 4.0 quality testing: Platforms and Runtimes
[
https://issues.apache.org/jira/browse/CASSANDRA-15587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15587:
---
Resolution: Fixed
Status: Resolved (was: Open)
> 4.0 quality testing: Platforms and Runtimes
> ---
>
> Key: CASSANDRA-15587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15587
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: {color:#ff}NONE{color}*
> CASSANDRA-9608 introduces support for Java 11. We'll want to verify that
> Cassandra under Java 11 meets expectations of stability.
--
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] [Updated] (CASSANDRA-15587) 4.0 quality testing: Platforms and Runtimes
[
https://issues.apache.org/jira/browse/CASSANDRA-15587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer updated CASSANDRA-15587:
---
Change Category: Quality Assurance
Status: Open (was: Triage Needed)
> 4.0 quality testing: Platforms and Runtimes
> ---
>
> Key: CASSANDRA-15587
> URL: https://issues.apache.org/jira/browse/CASSANDRA-15587
> Project: Cassandra
> Issue Type: Task
> Components: Test/dtest/java, Test/dtest/python
>Reporter: Josh McKenzie
>Assignee: Gianluca Righetto
>Priority: Normal
> Fix For: 4.0-rc
>
>
> Reference [doc from
> NGCC|https://docs.google.com/document/d/1uhUOp7wpE9ZXNDgxoCZHejHt5SO4Qw1dArZqqsJccyQ/edit#]
> for context.
> *Shepherd: {color:#ff}NONE{color}*
> CASSANDRA-9608 introduces support for Java 11. We'll want to verify that
> Cassandra under Java 11 meets expectations of stability.
--
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] [Assigned] (CASSANDRA-16296) Join new node to cluster failing on C* version 4
[
https://issues.apache.org/jira/browse/CASSANDRA-16296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Berenguer Blasi reassigned CASSANDRA-16296:
---
Assignee: Berenguer Blasi (was: Benjamin Lerer)
> Join new node to cluster failing on C* version 4
>
>
> Key: CASSANDRA-16296
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16296
> Project: Cassandra
> Issue Type: Bug
> Components: Local/Startup and Shutdown
>Reporter: Yakir Gibraltar
>Assignee: Berenguer Blasi
>Priority: Normal
> Fix For: 4.0-beta
>
>
> Hi, i'm using cassandra 4.0-beta3,
> Join new node failing,
> Current status:
> {code}
> [root@rc801 ~]# nodetool status
> Datacenter: V4CH
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
>Rack
> UN 1.1.1.1 356.55 KiB 128 ?
> 92ae4c39-edb3-4e67-8623-b49fd8301b66 RAC1
> UN 2.2.2.2 424.36 KiB 128 ?
> d80647a8-32b2-4a8f-8022-f5ae3ce8fbb2 RAC1
> Datacenter: V4NJ
>
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- Address LoadTokens Owns (effective) Host ID
>Rack
> UN 3.3.3.3 322.97 KiB 128 ?
> 0106ce0b-18be-4321-8247-843076ff42e6 RAC1
> UN 4.4.4.4 297.6 KiB 128 ?
> d81e2b7d-9221-4b1b-86c8-e8956e3eec07 RAC1
> UN 5.5.5.5 324.75 KiB 128 ?
> 5dfbaf14-8310-4d64-b61a-9da0a7a8a620 RAC1
> {code}
> Error on new host (7.7.7.7):
> {code}
> INFO [main] 2020-11-22 09:27:36,592 RangeStreamer.java:323 - Bootstrap:
> range Full(/7.7.7.7:7000,(-7734271291904743823,-7725025391901227341]) exists
> on Full(/1.1.1.1:7000,(-7734271291904743823,-7725025391901227341]) for
> keyspace system_traces
> ERROR [main] 2020-11-22 09:27:36,609 CassandraDaemon.java:817 - Exception
> encountered during startup
> java.lang.IllegalStateException: Multiple strict sources found for
> Full(/7.7.7.7:7000,(9208454697546654053,-9212763148842799409]), sources:
> [Full(/2.2.2.2:7000,(9189373804905478622,-9212763148842799409]),
> Full(/1.1.1.1:7000,(9189373804905478622,-9212763148842799409])]
> at
> org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:517)
> at
> org.apache.cassandra.dht.RangeStreamer.calculateRangesToFetchWithPreferredEndpoints(RangeStreamer.java:383)
> at
> org.apache.cassandra.dht.RangeStreamer.addRanges(RangeStreamer.java:320)
> at
> org.apache.cassandra.dht.BootStrapper.bootstrap(BootStrapper.java:81)
> at
> org.apache.cassandra.service.StorageService.startBootstrap(StorageService.java:1635)
> at
> org.apache.cassandra.service.StorageService.bootstrap(StorageService.java:1612)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:931)
> at
> org.apache.cassandra.service.StorageService.joinTokenRing(StorageService.java:892)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:699)
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:635)
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:407)
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:671)
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:795)
> INFO [StorageServiceShutdownHook] 2020-11-22 09:27:36,616
> HintsService.java:220 - Paused hints dispatch
> WARN [StorageServiceShutdownHook] 2020-11-22 09:27:36,617 Gossiper.java:1849
> - No local state, state is in silent shutdown, or node hasn't joined, not
> announcing shutdown
> INFO [StorageServiceShutdownHook] 2020-11-22 09:27:36,617
> MessagingService.java:441 - Waiting for messaging service to quiesce
> {code}
> Errors on seed node:
> {code}
> INFO [Messaging-EventLoop-3-37] 2020-11-22 09:26:54,121
> InboundConnectionInitiator.java:459 -
> /7.7.7.7:7000(/7.7.7.7:45490)->/1.1.1.1:7000-URGENT_MESSAGES-f412b9ba
> messaging connection established, version = 12, framing = LZ4, encryption =
> disabled
> INFO [Messaging-EventLoop-3-40] 2020-11-22 09:26:54,157
> OutboundConnection.java:1151 -
> /1.1.1.1:7000(/1.1.1.1:38678)->/7.7.7.7:7000-URGENT_MESSAGES-3b23f639
> successfully connected, version = 12, framing = LZ4, encryption = disabled
> INFO [GossipStage:1] 2020-11-22 09:26:56,109 Gossiper.java:1248 - Node
> /7.7.7.7:7000 is now part of the cluster
> INFO [GossipStage:1] 2020-11-22 09:26:56,147 Gossiper.java:1206 -
> InetAddress /7.7.7.7:7000 is now UP
> INFO
