Re: [VOTE] Release Apache Cassandra 4.0.13

[Marcus Eriksson]

+1

On Thu, May 02, 2024 at 10:16:38AM -0500, Brandon Williams wrote:
> Proposing the test build of Cassandra 4.0.13 for release.
> 
> sha1: a6fb3b76feb8467d314b116f937322e1989b42e1
> Git: https://github.com/apache/cassandra/tree/4.0.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1328/org/apache/cassandra/cassandra-all/4.0.13/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.13/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.13-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/4.0.13-tentative/NEWS.txt
> 
> Kind Regards,
> Brandon

Re: CEP-21 - testing changing IP addresses

[Marcus Eriksson]

Hi,

On Thu, Dec 21, 2023 at 09:45:23AM +, Paul Chandler via dev wrote:
> Hi all,
> 
> We run some large clusters using Kubernetes and recently ran into an issue on 
> 4.0.x, so I decided to look at 5.1 and see if TCM fixes the issue.
> 
> However what we found was there are a number of new issues with TCM when a 
> node is stopped then restarts with a new ip address, something that happens 
> quite often with Kubernetes, and normally works fine in 4.0
> 
> So, I have a couple of questions, firstly, I am testing against trunk, is 
> there a better branch to test TCM?

yes, trunk is the correct branch to test TCM

> Secondly, is this stable enough that I should be raising Jira tickets for the 
> issues, if so, should I attach them to the Epic CASSANDRA-19055 or create 
> them standalone?

yeah, please create jiras and attach to 19055

Thanks in advance!

/Marcus

Re: [VOTE] Release Harry 0.0.2

[Marcus Eriksson]

+1

On Wed, Nov 29, 2023 at 12:14:29PM +0100, Alex Petrov wrote:
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking. 
> 
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> 
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Prominent changes:
> 
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
> 
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
> 
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.

Re: [DISCUSS] Harry in-tree

[Marcus Eriksson]

+1!

/Marcus

On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote:
> Hi everyone,
> 
> With TCM landed, there will be way more Harry tests in-tree: we are using it 
> for many coordination tests, and there's now a simulator test that uses 
> Harry. During development, Harry has allowed us to uncover and resolve 
> numerous elusive edge cases.
> 
> I had conversations with several folks, and wanted to propose to move 
> harry-core to Cassandra test tree. This will substantially 
> simplify/streamline co-development of Cassandra and Harry. With a new 
> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
> will also be much more approachable.
> 
> Besides making it easier for everyone to develop new fuzz tests, it will also 
> substantially lower the barrier to entry. Currently, debugging an issue found 
> by Harry involves a cumbersome process of rebuilding and transferring jars 
> between Cassandra and Harry, depending on which side you modify. This not 
> only hampers efficiency but also deters broader adoption. By merging 
> harry-core into the Cassandra test tree, we eliminate this barrier.
> 
> Thank you,
> --Alex
> 
> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

CEP-21 - Transactional cluster metadata merged to trunk

[Marcus Eriksson]

Hi all

We just wanted to give a heads up that we merged CEP-21, Transactional Cluster 
Metadata to trunk[1] today. 

There are about 15-20 flaky or failing tests in total, spread over several test 
jobs[2] (i.e. single digit failures in a few of these). We have filed JIRAs for 
the failures and are working on getting those fixed as a top priority. 
CASSANDRA-19055[3] is the umbrella ticket for this follow up work.

There are also a number of improvements we will work on in the coming weeks, we 
will file JIRAs for those early next week and add them as subtasks to 
CASSANDRA-19055.

This is a huge patch and so constant rebasing onto even small changesets is 
challenging, hence we took the decision to merge now despite CI not being 100% 
stable. Landing in trunk also mitigates this somewhat, as resolving these 
issues isn’t blocking any imminent release.  

Given the scope and ambition of the changes some teething problems will be 
inevitable, so please reach out in #cassandra-tcm on ASF Slack if you have any 
questions or problems. We do not expect this to add a substantial amount of 
work for other contributors, but if this happens to affect your patch we’ll 
gladly help out.

Thanks
Sam, Alex & Marcus


[1] 
https://github.com/apache/cassandra/commit/ae0842372ff6dd1437d026f82968a3749f555ff4
[2] 
https://app.circleci.com/pipelines/github/michaelsembwever/cassandra/256/workflows/c4fda8f1-a8d6-4523-be83-5e30b9de39fe
 
[3] https://issues.apache.org/jira/browse/CASSANDRA-19055

Re: Writes after the column is dropped, broken reads, and TCM

[Marcus Eriksson]

Hi, reply inline below

On Mon, Jun 26, 2023 at 06:39:09PM +0200, Jakub Zytka wrote:
> Hello,
> 
> I want to discuss the possibilities of fixing CASSANDRA-18591 and
> CASSANDRA-18589 (~exceptions during reads), considering that TCM will
> become a reality soon.
> While both issues can be hit even on a single-node cluster, I think it's
> important for the solution to be at least TCM-friendly and easily
> extendable in the future.
>
...

> 
> Finally, let's consider the role of Transactional Cluster Metadata (TCM).
> With TCM, distinguishing and handling some of the aforementioned scenarios
> may become easier or even feasible. However, my familiarity with TCM
> internals and future plans is limited. Therefore, I would greatly
> appreciate any insights into the relationship between TCM and scenarios
> such as the ones I've described above.

With TCM a schema change bumps an epoch, this epoch is then serialized with
every read command/partition update and the replica can check if it is behind
or ahead of the coordinator. This allows the replica to either catch up with
the coordinator before executing the read/write or fail the request if the
coordinator is behind.

There are still a few races though, for example, the new schema is set on
the node before the new epoch is committed, so we might send a read/write
to a replica using the new schema but with the old epoch. Fixing this would
require us to rewrite the way we manage schemas and is currently out of
scope, but TCM would allow us to do so in the future.

/Marcus

CVE-2023-30601: Apache Cassandra: Privilege escalation when enabling FQL/Audit logs

[Marcus Eriksson]

Severity: important

Affected versions:

- Apache Cassandra 4.0.0 through 4.0.9
- Apache Cassandra 4.1.0 through 4.1.1

Description:

Privilege escalation when enabling FQL/Audit logs allows user with JMX access 
to run arbitrary commands as the user running Apache Cassandra
This issue affects Apache Cassandra: from 4.0.0 through 4.0.9, from 4.1.0 
through 4.1.1.

WORKAROUND
The vulnerability requires nodetool/JMX access to be exploitable, disable 
access for any non-trusted users.

MITIGATION
Upgrade to 4.0.10 or 4.1.2 and leave the new FQL/Auditlog configuration 
property allow_nodetool_archive_command as false.

This issue is being tracked as CASSANDRA-18550 

Credit:

Gal Elbaz at Oligo (finder)

References:

https://cassandra.apache.org/
https://www.cve.org/CVERecord?id=CVE-2023-30601
https://issues.apache.org/jira/browse/CASSANDRA-18550

Re: [VOTE] Release Apache Cassandra 4.1.2

[Marcus Eriksson]

+1

On Thu, May 25, 2023 at 05:12:45PM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.1.2 for release.
> 
> sha1: c5c075f0080f3f499d2b01ffb155f89723076285
> Git: https://github.com/apache/cassandra/tree/4.1.2-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1302/org/apache/cassandra/cassandra-all/4.1.2/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.2/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.1.2-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.1.2-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 4.0.10

[Marcus Eriksson]

+1

On Thu, May 25, 2023 at 05:12:43PM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.10 for release.
> 
> sha1: da77d3f729160e84fbab37666de99550be794265
> Git: https://github.com/apache/cassandra/tree/4.0.10-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1299/org/apache/cassandra/cassandra-all/4.0.10/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.10/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/4.0.10-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/4.0.10-tentative/NEWS.txt

Re: [VOTE] CEP-21 Transactional Cluster Metadata

[Marcus Eriksson]

+1

On Mon, Feb 06, 2023 at 04:15:19PM +, Sam Tunnicliffe wrote:
> Hi everyone,
> 
> I would like to start a vote on this CEP.
> 
> Proposal:
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata
> 
> Discussion:
> https://lists.apache.org/thread/h25skwkbdztz9hj2pxtgh39rnjfzckk7
> 
> The vote will be open for 72 hours.
> A vote passes if there are at least three binding +1s and no binding vetoes.
> 
> Thanks,
> Sam

Re: [VOTE] Release Apache Cassandra 4.1.0 (take2)

[Marcus Eriksson]

+1

On Wed, Dec 07, 2022 at 10:40:21PM +0100, Mick Semb Wever wrote:
> Proposing the (second) test build of Cassandra 4.1.0 for release.
> 
> sha1: f9e033f519c14596da4dc954875756a69aea4e78
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1282/org/apache/cassandra/cassandra-all/4.1.0/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.1.0/
> 
> The vote will be open for 96 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.1.0-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.1.0-tentative

Re: [VOTE] Release Apache Cassandra 3.11.13

[Marcus Eriksson]

+1

On Sat, May 07, 2022 at 08:38:04AM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.11.13 for release.
> 
> sha1: 836ab2802521a685efe84382cb48db56caf4478d
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.13-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1268/org/apache/cassandra/cassandra-all/3.11.13/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.13/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.13-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.13-tentative

Re: [VOTE] Release Apache Cassandra 3.0.27

[Marcus Eriksson]

+1

On Sat, May 07, 2022 at 08:37:38AM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.0.27 for release.
> 
> sha1: 205366131484967a3a8a749f1d1d841c952127e8
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.27-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1267/org/apache/cassandra/cassandra-all/3.0.27/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.27/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.27-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.27-tentative

Re: [VOTE] Release Apache Cassandra 4.0.4 (take2)

[Marcus Eriksson]

+1

On Sat, May 07, 2022 at 08:39:10AM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.4 for release.
> This is from the (take4) test artifact.
> 
> sha1: 052125f2c6ed308f1473355dfe43470f0da44364
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.4-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1270/org/apache/cassandra/cassandra-all/4.0.4/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.4/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.4-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.4-tentative

Re: Updating our Code Contribution/Style Guide

[Marcus Eriksson]

Looks good

One thing that might be missing is direction on if we should avoid making 
method parameters and local variables `final` - this is inconsistent over the 
code base, but I'd prefer not having them. If the method is large enough that 
we might mistakenly reuse parameters/variables, we should probably refactor the 
method.

/Marcus

On Mon, Mar 14, 2022 at 09:41:35AM +, bened...@apache.org wrote:
> Our style guide hasn’t been updated in about a decade, and I think it is 
> overdue some improvements that address some shortcomings as well as modern 
> facilities such as streams and lambdas.
> 
> Most of this was put together for an effort Dinesh started a few years ago, 
> but has languished since, in part because the project has always seemed to 
> have other priorities. I figure there’s never a good time to raise a 
> contended topic, so here is my suggested update to contributor guidelines:
> 
> https://docs.google.com/document/d/1sjw0crb0clQin2tMgZLt_ob4hYfLJYaU4lRX722htTo
> 
> Many of these suggestions codify norms already widely employed, sometimes in 
> spite of the style guide, but some likely remain contentious. Some 
> potentially contentious things to draw your attention to:
> 
> 
>   *   Deemphasis of getX() nomenclature, in favour of richer set of prefixes 
> and more succinct simple x() to retrieve where clear
>   *   Avoid implementing methods, incl. equals(), hashCode() and toString(), 
> unless actually used
>   *   Modified new-line rules for multi-line function calls
>   *   External dependency rules (require DISCUSS thread before introducing)
> 
> 
> 

Re: [DISCUSS] Hotfix release procedure

[Marcus Eriksson]

+1 (hotfix with only security fix, private vote, private branch & private ci)

On Tue, Feb 15, 2022 at 02:18:42PM +, bened...@apache.org wrote:
> One issue with this approach is that we are advertising that we are preparing 
> a security release by preparing such a release candidate.
> 
> I wonder if we need to find a way to produce binaries without leaving an 
> obvious public mark (i.e. private CI, private branch)
> 
> 
> From: Josh McKenzie 
> Date: Tuesday, 15 February 2022 at 14:09
> To: dev@cassandra.apache.org 
> Subject: [DISCUSS] Hotfix release procedure
> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix 
> releases and CI:
> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr
> 
> If we are making this release for a security incident/data loss/hot fix 
> reason, then I would expect to see the related change set only containing 
> those patches. But the change set in the tag here the latest 4.0-dev commits.
> 
> I'd like to propose that in the future, regardless of the state of CI, if we 
> need to cut a hotfix release we do so from the previous released SHA + only 
> the changes required to address the hotfix to minimally impact our end users 
> and provide them with as minimally disruptive a fix as possible.

Re: [VOTE] Release Apache Cassandra 4.0.3

[Marcus Eriksson]

+1

On Sun, Feb 13, 2022 at 11:03:01PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.3 for release.
> 
> 
> sha1: a87055d56a33a9b17606f14535f48eb461965b82
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.3-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1259/org/apache/cassandra/cassandra-all/4.0.3/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.3/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.3-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.3-tentative

CVE-2021-44521: Apache Cassandra: Remote code execution for scripted UDFs

[Marcus Eriksson]

Severity: high

Description:

When running Apache Cassandra with the following configuration:

enable_user_defined_functions: true
enable_scripted_user_defined_functions: true
enable_user_defined_functions_threads: false 

it is possible for an attacker to execute arbitrary code on the host. The 
attacker would need to have enough permissions to create user defined functions 
in the cluster to be able to exploit this. Note that this configuration is 
documented as unsafe, and will continue to be considered unsafe after this CVE.

This issue is being tracked as CASSANDRA-17352

Mitigation:

Set `enable_user_defined_functions_threads: true` (this is default)
or
3.0 users should upgrade to 3.0.26
3.11 users should upgrade to 3.11.12
4.0 users should upgrade to 4.0.2

Credit:

This issue was discovered by Omer Kaspi of the JFrog Security vulnerability 
research team.

Re: [VOTE] Release Apache Cassandra 3.11.12

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:25PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.11.12 for release.
> 
> sha1: b44ff92eb2921e8d66fe2e994cb27289d3786faa
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.12-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1254/org/apache/cassandra/cassandra-all/3.11.12/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.12/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.12-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.12-tentative

Re: [VOTE] Release Apache Cassandra 4.0.2

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:36PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0.2 for release.
> 
> sha1: 25012d2fec1984cc9c1a352f214eb912ca4f10f5
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.2-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1255/org/apache/cassandra/cassandra-all/4.0.2/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.2/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.2-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.2-tentative

Re: [VOTE] Release Apache Cassandra 3.0.26

[Marcus Eriksson]

+1

On Mon, Feb 07, 2022 at 03:14:15PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 3.0.26 for release.
> 
> sha1: b18adcba1a808cf77576905dc2ceccd7783bdb18
> 
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.26-tentative
> 
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1253/org/apache/cassandra/cassandra-all/3.0.26/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.26/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.26-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.26-tentative

Re: UDF future

[Marcus Eriksson]

+1

On Tue, Jan 18, 2022 at 11:30:01AM -0500, Ekaterina Dimitrova wrote:
> Hi everyone,
> 
> With the work to add Java 17 support for Cassandra, a new question around
> the future of UDF was raised. The scripted UDF was using Nashorn which is
> no longer packaged with the JDK. There are options to add new dependencies
> to Graal JS for example but it seems people are not sure that it is worth
> it. Please check the discussion on CASSANDRA-16895.
> 
> The following suggestion was made by Marcus and supported by other PMC
> members - "I think we should deprecate scripted UDFs now and drop them from
> the next major, but possibly provide hooks for people to write their own
> UDF "engines" and break out the current javascript implementation in to its
> own repository (but not ship it with Cassandra)."
> 
> As a result we decided to engage with our users and created a Twitter
> survey. Results below:
> 
> *We would love to understand how you use ApacheCassandra UDFs and UDAs.*
> 
> *32 people responded as follows:*
> 
>- *We do not use them - 75%*
>- *We only use Java UDFs - 22%*
>- *We only use JS UDFs - 0%*
>- *We use Java and JS UDFs - 3%*
> 
> We also received feedback on LinkedIN on the topic -
> https://www.linkedin.com/feed/update/urn:li:activity:6886728406742970369?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6886793921020608512%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A6886728406742970369%2C6887421509485248512%29
> 
> Thoughts?
> 
> Best regards,
> Ekaterina

Re: [VOTE] CEP-15: General Purpose Transactions

[Marcus Eriksson]

1. +1
2. +1
3. +1

On Thu, Oct 14, 2021 at 04:31:29PM +, bened...@apache.org wrote:
> Hi everyone,
> 
> I would like to start a vote on this CEP, split into three sub-decisions, as 
> discussion has been circular for some time.
> 
> 1. Do you support adopting this CEP?
> 2. Do you support the transaction semantics proposed by the CEP for Cassandra?
> 3. Do you support an incremental approach to developing transactions in 
> Cassandra, leaving scope for future development?
> 
> The first vote is a consensus vote of all committers, the second and third 
> however are about project direction and therefore are simple majority votes 
> of the PMC.
> 
> Recall that all -1 votes must be accompanied by an explanation. If you reject 
> the CEP only on grounds (2) or (3) you should not veto the proposal. If a 
> majority reject grounds (2) or (3) then transaction developments will halt 
> for the time being.
> 
> This vote will be open for 72 hours.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.10

[Marcus Eriksson]

+1

On Tue, Oct 05, 2021 at 06:47:10PM +0200, Oleksandr Petrov wrote:
> Proposing the test build of in-jvm dtest API 0.0.10 for release.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.10
> 
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/2139b4c85e319b17afbdea2f653152d1e1895fc6
> tagged with 0.0.10
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1249/org/apache/cassandra/dtest-api/0.0.10/
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Changes since last release:
>   * CASSANDRA-17013: CEP-10 Simulator Improvements
> 
> 
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0.1

[Marcus Eriksson]

+1

On Wed, Sep 01, 2021 at 12:54:36PM +0100, Sam Tunnicliffe wrote:
> Proposing the test build of Cassandra 4.0.1 for release.
> 
> sha1: 6709111ed007a54b3e42884853f89cabd38e4316
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1247/org/apache/cassandra/cassandra-all/4.0.1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and 
> repositories, are available here: 
> https://dist.apache.org/repos/dist/dev/cassandra/4.0.1/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has 
> tested the build is invited to vote. Votes by PMC members are considered 
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0.1-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.1-tentative
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1 (take2)

[Marcus Eriksson]

+1

On Wed, Apr 21, 2021 at 08:51:23PM +0200, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0-rc1 for release.
> 
> sha1: 3282f5ecf187ecbb56b8d73ab9a9110c010898b0
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-rc1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1235/org/apache/cassandra/cassandra-all/4.0-rc1/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-rc1/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-rc1-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-rc1-tentative
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-rc1

[Marcus Eriksson]

-1

we should get CASSANDRA-16552 fixed first

Den tors 1 apr. 2021 kl 13:37 skrev Mick Semb Wever :

> >
> > Is it possible to extend the vote by 24 hours for us to triage the
> >> issue and confirm if it is user error or a legitimate bug?
> >
> >
> >
> > Of course. That pushes the vote deadline to Fri, 29 Mar, 3pm CEST.
> >
>
>
>  Fri, 2nd April, 3pm CEST.
> :-)
>

Re: [VOTE] Release Apache Cassandra 3.11.10

[Marcus Eriksson]

+1

On Fri, Jan 29, 2021 at 01:50:29PM +0100, Oleksandr Petrov wrote:
> Proposing the test build of Cassandra 3.11.10 for release.
> 
> sha1: 181a4969290f1c756089b2993a638fe403bc1314
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.10-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1231/org/apache/cassandra/cassandra-all/3.11.10/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.10/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.10-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.10-tentative

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 3.0.24

[Marcus Eriksson]

+1

On Fri, Jan 29, 2021 at 01:48:22PM +0100, Oleksandr Petrov wrote:
> Proposing the test build of Cassandra 4.0-beta4 for release.
> 
> sha1: 6748ecd63cae047b5b0e8c3165088252954e9d5f
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.24-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1229/org/apache/cassandra/cassandra-all/3.0.24/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.24/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.24-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.24-tentative

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Upgrade chronicle-queue version from 4 to 5

[Marcus Eriksson]

+1, lets upgrade now

On Wed, Jan 20, 2021 at 01:26:59PM -0800, Jeff Jirsa wrote:
> No objection and strong agreement that it should happen with 4.0 for arm64
> 
> 
> On Wed, Jan 20, 2021 at 12:44 PM Mick Semb Wever  wrote:
> 
> > To get Cassandra 4.0 working on arm64 we have a number of dependencies
> > we need to upgrade. See CASSANDRA-16384, CASSANDRA-16392 and
> > CASSANDRA-15889.
> >
> > CASSANDRA-16384 requires the major version upgrade from
> > chronicle-queue 4 to 5. A consequence[1] of this is any external
> > trailers (consumers) must also be upgraded to version 5. This is a
> > breakage of our Beta Release Lifecycle rules[2]. Chronicle-queue is
> > used by Auditing, FQL, and Diagnostic Events.
> >
> > I would like to request an exception to the Beta release to get the
> > upgrade in place and to support arm64. Does anyone have any objection
> > or concern to the upgrade? An entry in NEWS.txt will be added.
> >
> >
> > [1]
> > https://issues.apache.org/jira/browse/CASSANDRA-16384?focusedCommentId=17268671&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17268671
> >
> > [2]
> > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-beta4

[Marcus Eriksson]

+1

On Fri, Dec 18, 2020 at 08:16:16PM +0100, Mick Semb Wever wrote:
> Proposing the test build of Cassandra 4.0-beta4 for release.
> 
> sha1: b0c50c10dbc443a05662b111a971a65cafa258d5
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta4-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1226/org/apache/cassandra/cassandra-all/4.0-beta4/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta4/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta4-tentative
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta4-tentative

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.7

[Marcus Eriksson]

+1

On Thu, Dec 03, 2020 at 02:02:12PM +0100, Oleksandr Petrov wrote:
> Proposing the test build of in-jvm dtest API 0.0.7 for release.
> 
> Repository:https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.7
> 
> Candidate 
> SHA:https://github.com/apache/cassandra-in-jvm-dtest-api/commit/d5174b1f44b7d9cb919d4975b4d437041273c09c
> tagged with 0.0.7
> Artifact:https://repository.apache.org/content/repositories/orgapachecassandra-1225/org/apache/cassandra/dtest-api/0.0.7/
> 
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> 
> Changes since last release:
> 
>   * CASSANDRA-16136: Add Metrics to instance API
>   * CASSANDRA-16272: Nodetool assert apis do not include the new
> stdout and stderr in the failure message
> 
> The vote will be open for 24 hours. Everyone who has tested the build
> is invited to vote. Votes by PMC members are considered binding. A
> vote passes if there are at least three binding +1s.
> 
> -- Alex

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 2.2.19

[Marcus Eriksson]

+1


On 29 October 2020 at 13:29:29, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 2.2.19 for release.
> 
> sha1: 0d9462efc2cbf2a61a67ae4f6786086bb30272ef
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.19-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1221/org/apache/cassandra/cassandra-all/2.2.19/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/2.2.19/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.19-tentative
>  
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.19-tentative
>  
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 3.11.9

[Marcus Eriksson]

+1


On 29 October 2020 at 13:30:16, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 3.11.9 for release.
> 
> sha1: 5ef75dd96cb693e4041e9ecb61a6852276f0eca4
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.9-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1223/org/apache/cassandra/cassandra-all/3.11.9/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.9/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.9-tentative
>  
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.9-tentative
>  
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 3.0.23

[Marcus Eriksson]

+1


On 29 October 2020 at 13:29:37, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 3.0.23 for release.
> 
> sha1: 31530ff5ac6bd3bacd4b378573a2d191bdab8cd7
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.23-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1222/org/apache/cassandra/cassandra-all/3.0.23/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.23/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.23-tentative
>  
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.23-tentative
>  
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-beta3

[Marcus Eriksson]

+1


On 29 October 2020 at 13:29:55, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 4.0-beta3 for release.
> 
> sha1: be716b46f2cb3b2d1f01dc225396c6284d5a35de
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta3-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1224/org/apache/cassandra/cassandra-all/4.0-beta3/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta3/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who
> has tested the build is invited to vote. Votes by PMC members are
> considered binding. A vote passes if there are at least three binding
> +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta3-tentative
>  
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta3-tentative
>  
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supported upgrade path for 4.0

[Marcus Eriksson]

My suggestion for "supported" upgrade paths would be;

2.1 (2.2) -> 3.0 -> 4.0
2.1 (2.2) -> 3.11 -> 4.0

and drop support for 3.0 -> 3.11 when we release 4.0

/Marcus



On 9 October 2020 at 16:12:12, Joshua McKenzie (jmcken...@apache.org) wrote:
> Some data that I believe is relevant here.
>  
> Numerically it's safe to assume there's over 10,000 ASF C* clusters out in
> the world (5,500 in China alone). In surveys (both informal polling and
> primary research), at least 1/3rd of folks are running the 3.X latest if I
> recall correctly.
>  
> Basic conclusions we can draw from these data points:
> 1) There are thousands of clusters running some form of post 3.0, so we can
> expect it to be *stable enough to upgrade through*
> 2) We have to support at least 3.11 → 4.0
>  
> If 1/3rd of our users are running 2.1, 1/3rd 3.0, and 1/3rd 3.11
> (hand-waving, probably more in the 25 vs. 40 etc but splitting hairs),
> there's clearly a significant value-add in usability of skipping majors
> (3.0->4.0). Depending on how we define "done" and "supported" for upgrade
> testing, this will represent a significant development burden.
>  
> From a *functional MVP* perspective on what upgrade paths we need to
> support, the absolute minimum would be 2.1 → 3.0 → 3.11 → 4.0
>  
> If anyone wants to step in and officially support the 3.0 → 4.0 line,
> that's fantastic both for the project community and for users. But as far
> as basic table stakes, I can't think of a logical reason 3.0 → 4.0 as an
> upgraded path should be considered a blocker for releasing 4.0 GA.
>  
>  
>  
> On Fri, Oct 09, 2020 at 9:53 AM, Mick Semb Wever wrote:
>  
> > At The Last Pickle we have always recommended avoiding 3.0, including
> > upgrading from 2.2 directly to 3.11.
> > We (now DataStax) will continue to recommend that folk upgrade to the
> > latest 3.11 before upgrading to 4.0.
> >
> > To clarify that^, if it wasn't obvious, I wasn't making a statement about
> > DataStax at at large, but about those of us at TLP and now the team
> > providing the consulting for Apache Cassandra from DataStax.
> >
>  


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Supported upgrade path for 4.0

[Marcus Eriksson]

On 9 October 2020 at 10:23:02, Benedict Elliott Smith (bened...@apache.org) 
wrote:
> I would personally prefer the community to officially recommend skipping 3.11 
> to users  
> that have not yet upgraded, as 3.0 and 4.0 have each had much more attention 
> given to them  
> over the past several years. This would naturally lead to fewer issues filed 
> for 3.0->3.11  
> and 3.11->4.0, as fewer users take this upgrade path.

+1 

Upgrades are painful even without hitting any issues so avoiding one upgrade 
should help users.

/Marcus



-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.6

[Marcus Eriksson]

+1


On 8 October 2020 at 10:20:22, Oleksandr Petrov (oleksandr.pet...@gmail.com) 
wrote:
> Proposing the test build of in-jvm dtest API 0.0.6 for release.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.6
>  
> 
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/9efeb731b6ff4036fa822b0282b27d273975cd6fTT
>  
> tagged with 0.0.6
> Artifact:
> https://repository.apache.org/content/repositories/orgapachecassandra-1220/org/apache/cassandra/dtest-api/0.0.6/
>  
> 
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> 
> Changes since last release:
> 
> * CASSANDRA-16148: Add IInstance#getReleaseVersionString
> 
> The vote will be open for 24 hours. Everyone who has tested the build is
> invited to vote. Votes by PMC members are considered binding. A vote passes
> if there are at least three binding +1s.
> 
> -- Alex
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.5

[Marcus Eriksson]

+1

On 25 September 2020 at 17:13:36, Chris Lohfink (clohfin...@gmail.com) wrote:
> +1
> 
> On Fri, Sep 25, 2020 at 10:11 AM Caleb Rackliffe 
> wrote:
> 
> > +1
> >
> > On Fri, Sep 25, 2020 at 10:08 AM Brandon Williams 
> > wrote:
> >
> > > +1
> > >
> > > On Fri, Sep 25, 2020, 9:45 AM Oleksandr Petrov <
> > oleksandr.pet...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Proposing the test build of in-jvm dtest API 0.0.5 for release.
> > > >
> > > > Repository:
> > > >
> > > >
> > >
> > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.5
> >  
> > > > Candidate SHA:
> > > >
> > > >
> > >
> > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/f900334d2f61f0b10640ba7ae15958f26df72d92
> >  
> > > > tagged with 0.0.5
> > > > Artifact:
> > > >
> > > >
> > >
> > https://repository.apache.org/content/repositories/orgapachecassandra-1219/org/apache/cassandra/dtest-api/0.0.5/
> >  
> > > >
> > > > Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> > > >
> > > > Changes since last release:
> > > >
> > > > * CASSANDRA-16109: If user has not set nodeCount, use the node id
> > > > topology size
> > > > * CASSANDRA-16057: Update in-jvm dtest to expose stdout and stderr
> > for
> > > > nodetool
> > > > * CASSANDRA-16120: Add ability for jvm-dtest to grep instance logs
> > > > * CASSANDRA-16101: Add method to ignore uncaught throwables
> > > > * CASSANDRA-16109: Collect dc/rack information and validate when
> > > building
> > > > * CASSANDRA-15386: Default to 3 datadirs in in-jvm dtests
> > > > * CASSANDRA-16101: Add method to fetch uncaught exceptions
> > > >
> > > > The vote will be open for 24 hours. Everyone who has tested the build
> > is
> > > > invited to vote. Votes by PMC members are considered binding. A vote
> > > passes
> > > > if there are at least three binding +1s.
> > > >
> > > > -- Alex
> > > >
> > >
> >
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Accept the Harry donation

[Marcus Eriksson]

+1


On 16 September 2020 at 12:29:54, Sam Tunnicliffe (s...@beobal.com) wrote:
> +1
> 
> > On 16 Sep 2020, at 11:07, Benjamin Lerer wrote:
> >
> > +1
> >
> > On Wed, Sep 16, 2020 at 12:00 PM Mick Semb Wever wrote:
> >
> >>> Please cast your votes:
> >>> [ ] +1 Accept the contribution into Cassandra
> >>> [ ] -1 Do not
> >>>
> >>
> >>
> >> +1
> >>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 2.1.22

[Marcus Eriksson]

+1

On 28 August 2020 at 17:42:47, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 2.1.22 for release.
> 
> sha1: 94e9149c22f6a7772c0015e1b1ef2e2961155c0a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.22-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1214 
> /org/apache/cassandra/cassandra-all/2.1.22/
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/2.1.22/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.22-tentative
>  
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.1.22-tentative
>  
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 3.11.8

[Marcus Eriksson]

+1


On 28 August 2020 at 15:37:43, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 3.11.8 for release.
> 
> sha1: 8b29b698630960a0ebb2c695cc5b21dee4686d09
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.8-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1217/org/apache/cassandra/cassandra-all/3.11.8/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.11.8/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.8-tentative
>  
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.8-tentative
>  
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 3.0.22

[Marcus Eriksson]

+1


On 28 August 2020 at 15:09:53, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 3.0.22 for release.
> 
> sha1: 45331bb612dc7847efece7e26cdd0b376bd11249
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.22-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1216/org/apache/cassandra/cassandra-all/3.0.22/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/3.0.22/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.22-tentative
>  
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.22-tentative
>  
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 2.2.18

[Marcus Eriksson]

+1


On 28 August 2020 at 14:45:08, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 2.2.18 for release.
> 
> sha1: d4938cf4e488a9ef3ac48164a3e946f16255d721
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.18-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1215/org/apache/cassandra/cassandra-all/2.2.18/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/2.2.18/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.18-tentative
>  
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.18-tentative
>  
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 4.0-beta2

[Marcus Eriksson]

+1


On 28 August 2020 at 16:19:36, Mick Semb Wever (m...@apache.org) wrote:
> Proposing the test build of Cassandra 4.0-beta2 for release.
> 
> sha1: 56eadf2004399a80f0733041cacf03839832249a
> Git:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-beta2-tentative
>  
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1218/org/apache/cassandra/cassandra-all/4.0-beta2/
>  
> 
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/4.0-beta2/
> 
> The vote will be open for 72 hours (longer if needed). Everyone who has
> tested the build is invited to vote. Votes by PMC members are considered
> binding. A vote passes if there are at least three binding +1s and no -1's.
> 
> [1]: CHANGES.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/4.0-beta2-tentative
>  
> [2]: NEWS.txt:
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-beta2-tentative
>  
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.4

[Marcus Eriksson]

+1


On 10 July 2020 at 16:43:51, Caleb Rackliffe (calebrackli...@gmail.com) wrote:

+1 

On Fri, Jul 10, 2020 at 9:22 AM Oleksandr Petrov  
wrote: 

> Proposing the test build of in-jvm dtest API 0.0.4 for release. 
> 
> Repository: 
> 
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.4
>  
> Candidate SHA: 
> 
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/b481c85f9ce49e17b47765800ca5c2b396b1fa73
>  
> tagged 
> with 0.0.4 
> Artifact: 
> 
> https://repository.apache.org/content/repositories/orgapachecassandra-1206/org/apache/cassandra/dtest-api/0.0.4/
>  
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C 
> 
> Changes since last release: 
> 
> * CASSANDRA-15920: Make SimpleQueryResult a container for client 
> warnings, and expose those warnings via QueryResult 
> 
> The vote will be open for 24 hours. Everyone who has tested the build is 
> invited to vote. Votes by PMC members are considered binding. A vote passes 
> if there are at least three binding +1s. 
> 
> -- Alex 
> 

Re: [VOTE] Release dtest-api 0.0.3

[Marcus Eriksson]

+1

On 3 July 2020 at 12:02:30, Benedict Elliott Smith (bened...@apache.org) wrote:

+1  

On 03/07/2020, 10:57, "Oleksandr Petrov"  wrote:  

Proposing the test build of in-jvm dtest API 0.0.3 for release.  

Repository:  
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.3
  
Candidate SHA:  
https://github.com/apache/cassandra-in-jvm-dtest-api/commit/3f01a1743a0dcc9d0b054e12bd53f808dd1adc49
  
tagged with 0.0.3  
Artifact:  
https://repository.apache.org/content/repositories/orgapachecassandra-1205/org/apache/cassandra/dtest-api/0.0.3/
  
Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C  

Changes since last release:  

* CASSANDRA-15851: Add instance initializer  

The vote will be open for 24 hours. Everyone who has tested the build is  
invited to vote. Votes by PMC members are considered binding. A vote passes  
if there are at least three binding +1s.  

-- Alex  



-  
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
For additional commands, e-mail: dev-h...@cassandra.apache.org  

Re: [VOTE] Project governance wiki doc (take 2)

[Marcus Eriksson]

+1


On 22 June 2020 at 08:37:39, Mick Semb Wever (m...@apache.org) wrote:

> - Vote will run through 6/24/20 
> - pmc votes considered binding 
> - simple majority of binding participants passes the vote 
> - committer and community votes considered advisory 



+1 (binding) 

- 
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org 
For additional commands, e-mail: dev-h...@cassandra.apache.org 

Re: [VOTE] Project governance wiki doc

[Marcus Eriksson]

+1


On 17 June 2020 at 12:40:38, Sam Tunnicliffe (s...@beobal.com) wrote:
> +1 (binding)
> 
> > On 17 Jun 2020, at 09:11, Jorge Bay Gondra wrote:
> >
> > +1 nb
> >
> > On Wed, Jun 17, 2020 at 7:41 AM Mick Semb Wever wrote:
> >
> >> +1 (binding)
> >>
> >> On Tue, 16 Jun 2020 at 18:19, Joshua McKenzie 
> >> wrote:
> >>
> >>> Added unratified draft to the wiki here:
> >>>
> >>>
> >> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
> >>  
> >>>
> >>> I propose the following:
> >>>
> >>> 1. We leave the vote open for 1 week (close at end of day 6/23/20)
> >>> unless there's a lot of feedback on the wiki we didn't get on gdoc
> >>> 2. pmc votes are considered binding
> >>> 3. committer and community votes are considered advisory / non-binding
> >>>
> >>> Any objections / revisions to the above?
> >>>
> >>> Thanks!
> >>>
> >>> ~Josh
> >>>
> >>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.2

[Marcus Eriksson]

+1


On 29 April 2020 at 17:08:57, David Capwell (dcapw...@apple.com.invalid) wrote:
> +1.
> Checked integration with Cassandra and upgrade
>  
> Sent from my iPhone
>  
> > On Apr 29, 2020, at 4:01 AM, Mick Semb Wever wrote:
> >
> > 
> >>
> >> Proposing the test build of in-jvm dtest API 0.0.2 for release.
> >
> >
> > +1
> >
> > Checked:
> > - copyright and license
> > - changelog
> > - build, tests, rat
> > - dependencies
> > - gpg signatures (to fingerprint)
> > - checksums
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>  
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>  
>  


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release dtest-api 0.0.1

[Marcus Eriksson]

+1


On 23 March 2020 at 11:27:50, Mick Semb Wever (m...@apache.org) wrote:
> >
> > The vote will be open for 72 hours (longer if needed). Everyone who has
> > tested the build is invited to vote. Votes by PMC members are considered
> > binding. A vote passes if there are at least three binding +1s.
> >
> 
> 
> +1 (non-binding) PENDING the KEYS file update.
> 
> Checked:
> - asc signatures
> - md5 and sha1 checksums
> - git sha and tag
> - builds from git sha
> - `mvn apache-rat:check` (is now part of `mvn verify`
> - NOTICE, LICENSE, copyright
> 
> 
> cheers,
> Mick
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Can we kick off a release?

[Marcus Eriksson]

Yes, I’ll run the tests for 3.11 and get it committed

/Marcus

On 23 October 2019 at 16:28:39, Sumanth Pasupuleti 
(sumanth.pasupuleti...@gmail.com) wrote:
> Looks like https://issues.apache.org/jira/browse/CASSANDRA-15363 is in
> "Ready to Commit" state. Can we have this committed, before cutting the
> next set of releases?
>  
> Thanks,
> Sumanth
>  
> On Wed, Oct 23, 2019 at 8:13 AM Blake Eggleston
> wrote:
>  
> > Looks like 15193 has been committed. Are we waiting on anything else
> > before cutting the next set of releases?
> >
> > > On Oct 8, 2019, at 1:11 PM, Jon Haddad wrote:
> > >
> > > I forgot to mention, we should also release alpha2 of 4.0.
> > >
> > >
> > > On Tue, Oct 8, 2019 at 1:04 PM Michael Shuler  
> > > wrote:
> > >
> > >> Thanks Sam, I'm following #15193 and should catch the status change
> > there.
> > >>
> > >> Michael
> > >>
> > >> On Tue, Oct 8, 2019 at 6:17 AM Sam Tunnicliffe wrote:
> > >>>
> > >>> CASSANDRA-15193 just got +1’d yesterday and would be good to include in
> > >> the 3.0 and 3.11 releases. If you don’t mind holding off while I add a
> > >> cqlsh test and merge it, that’d be good.
> > >>>
> > >>> Thanks,
> > >>> Sam
> > >>>
> >  On 7 Oct 2019, at 22:54, Michael Shuler  
> > >> wrote:
> > 
> >  Will do! I probably won't get this done this evening, so will send out
> >  the emails tomorrow.
> > 
> >  Thanks,
> >  Michael
> > 
> >  On Mon, Oct 7, 2019 at 2:37 PM Jon Haddad wrote:
> > >
> > > Michael,
> > >
> > > Would you mind kicking off builds and starting a vote thread for the
> > >> latest
> > > 2.2, 3.0 and 3.11 builds?
> > >
> > > Much appreciated,
> > > Jon
> > 
> >  -  
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > >>>
> > >>>
> > >>> -  
> > >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>
> > >>
> > >> -  
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>  


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: How to stop github notification emails?

[Marcus Eriksson]

Sure, updated the ticket to send them to pr@, but I imagine you would get them 
if you "watch" the github repo?

/Marcus

On Thu, Sep 05, 2019 at 01:03:11PM +0200, Mick Semb Wever wrote:
> 
> 
> > https://issues.apache.org/jira/browse/INFRA-18982
> 
> 
> Marcus, instead of ignoring them can we send them to pr@ (or commits@) please?
>  
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: How to stop github notification emails?

[Marcus Eriksson]

https://issues.apache.org/jira/browse/INFRA-18982

/Marcus

On Thu, Sep 05, 2019 at 09:20:01AM +0100, Benedict Elliott Smith wrote:
> +1
> 
> These should be sent to commits@, not dev@
> 
> On 05/09/2019, 09:19, "Stefan Miklosovic" 
>  wrote:
> 
> Hi,
> 
> maybe I am missing here something but how can I get rid of these
> emails which are polluting my inbox?
> 
> "[GitHub] [cassandra-builds] michaelsembwever commented on issue #10:
> Configure so emails are sent when a build fails"
> 
> It is sent from "g...@apache.org" to dev mailing list.
> 
> As far as I know I have never subscribed to that and I am (in most
> cases) not interested in random pull request comments.
> 
> Could you please let me know if there is some way how to turn this off?
> 
> Thank you a lot and have a nice day
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [GitHub] [cassandra-diff] krummas merged pull request #1: add github actions pull request verification

[Marcus Eriksson]

I created a ticket on infra to stop them:
https://issues.apache.org/jira/browse/INFRA-18946

/Marcus

On Tue, Aug 27, 2019 at 03:56:27PM +0200, Alex Ott wrote:
> Hello
> 
> Maybe it makes sense to send such messages to comm...@cassandra.apache.org ?
> 
> 
> GitBox  at "Tue, 27 Aug 2019 13:14:56 -" wrote:
>  G> krummas merged pull request #1: add github actions pull request 
> verification
>  G> URL: https://github.com/apache/cassandra-diff/pull/1
>  G>  
>  G>  
>  G>
> 
>  G> 
>  G> This is an automated message from the Apache Git Service.
>  G> To respond to the message, please log on to GitHub and use the
>  G> URL above to go to the specific comment.
>  G>  
>  G> For queries about this service, please contact Infrastructure at:
>  G> us...@infra.apache.org
> 
> 
> -- 
> With best wishes,Alex Ott
> Solutions Architect EMEA, DataStax
> http://datastax.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Contributing cassandra-diff

[Marcus Eriksson]

I just created a dedicated repository and pushed the code there

Since there was no outrage over the name, I opted to save myself some painful
renaming work and keep the cassandra-diff name.

https://gitbox.apache.org/repos/asf?p=cassandra-diff.git
https://github.com/apache/cassandra-diff

Pull requests welcome!

/Marcus

On Thu, Aug 22, 2019 at 08:38:55AM +0200, Marcus Eriksson wrote:
> Hi, we are about to open source our tooling for comparing two cassandra 
> clusters and want to get some feedback where to push it. I think the options 
> are: (name bike-shedding welcome)
> 
> 1. create repos/asf/cassandra-diff.git
> 2. create a generic repos/asf/cassandra-contrib.git where we can add more 
> contributed tools in the future
> 
> Temporary location: https://github.com/krummas/cassandra-diff
> 
> Cassandra-diff is a spark job that compares the data in two clusters - it 
> pages through all partitions and reads all rows for those partitions in both 
> clusters to make sure they are identical. Based on the configuration variable 
> “reverse_read_probability” the rows are either read forward or in reverse 
> order.
> 
> Our main use case for cassandra-diff has been to set up two identical 
> clusters, transfer a snapshot from the cluster we want to test to these 
> clusters and upgrade one side. When that is done we run this tool to make 
> sure that 2.1 and 3.0 gives the same results. A few examples of the bugs we 
> have found using this tool:
> 
> * CASSANDRA-14823: Legacy sstables with range tombstones spanning multiple 
> index blocks create invalid bound sequences on 3.0+
> * CASSANDRA-14803: Rows that cross index block boundaries can cause 
> incomplete reverse reads in some cases
> * CASSANDRA-15178: Skipping illegal legacy cells can break reverse iteration 
> of indexed partitions
> 
> /Marcus
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Contributing cassandra-diff

[Marcus Eriksson]

Hi, we are about to open source our tooling for comparing two cassandra 
clusters and want to get some feedback where to push it. I think the options 
are: (name bike-shedding welcome)

1. create repos/asf/cassandra-diff.git
2. create a generic repos/asf/cassandra-contrib.git where we can add more 
contributed tools in the future

Temporary location: https://github.com/krummas/cassandra-diff

Cassandra-diff is a spark job that compares the data in two clusters - it pages 
through all partitions and reads all rows for those partitions in both clusters 
to make sure they are identical. Based on the configuration variable 
“reverse_read_probability” the rows are either read forward or in reverse order.

Our main use case for cassandra-diff has been to set up two identical clusters, 
transfer a snapshot from the cluster we want to test to these clusters and 
upgrade one side. When that is done we run this tool to make sure that 2.1 and 
3.0 gives the same results. A few examples of the bugs we have found using this 
tool:

* CASSANDRA-14823: Legacy sstables with range tombstones spanning multiple 
index blocks create invalid bound sequences on 3.0+
* CASSANDRA-14803: Rows that cross index block boundaries can cause incomplete 
reverse reads in some cases
* CASSANDRA-15178: Skipping illegal legacy cells can break reverse iteration of 
indexed partitions

/Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: [VOTE] Release Apache Cassandra 2.1.21

[Marcus Eriksson]

+1

Den ons 6 feb. 2019 kl 10:54 skrev Benedict Elliott Smith <
bened...@apache.org>:

> +1, and also see no point in EOL; if we have failed to back port something
> important, we should rectify it.
>
> > On 6 Feb 2019, at 05:09, Jeff Jirsa  wrote:
> >
> > +1 (to the release, I see no reason to force this to be EOL; leaving the
> > branch open has zero cost, and if a serious enough patch comes up, we'll
> > likely be happy we have the option to fix it).
> >
> >
> > On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler 
> > wrote:
> >
> >> *EOL* release for the 2.1 series. There will be no new releases from the
> >> 'cassandra-2.1' branch after this release.
> >>
> >> 
> >>
> >> I propose the following artifacts for release as 2.1.21.
> >>
> >> sha1: 9bb75358dfdf1b9824f9a454e70ee2c02bc64a45
> >> Git:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.21-tentative
> >> Artifacts:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/org/apache/cassandra/apache-cassandra/2.1.21/
> >> Staging repository:
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1173/
> >>
> >> The Debian and RPM packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: CHANGES.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> >> [2]: NEWS.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.1.21-tentative
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.18

[Marcus Eriksson]

+1

Den ons 6 feb. 2019 kl 10:53 skrev Benedict Elliott Smith <
bened...@apache.org>:

> +1
>
> > On 6 Feb 2019, at 08:01, Tommy Stendahl 
> wrote:
> >
> > +1 (non-binding)
> >
> > /Tommy
> >
> > On lör, 2019-02-02 at 18:32 -0600, Michael Shuler wrote:
> >
> > I propose the following artifacts for release as 3.0.18.
> >
> > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.18-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/org/apache/cassandra/apache-cassandra/3.0.18/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1171/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.18-tentative
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 2.2.14

[Marcus Eriksson]

+1

Den ons 6 feb. 2019 kl 10:53 skrev Benedict Elliott Smith <
bened...@apache.org>:

> +1
>
> > On 6 Feb 2019, at 05:09, Jeff Jirsa  wrote:
> >
> > +1
> >
> > On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler 
> > wrote:
> >
> >> I propose the following artifacts for release as 2.2.14.
> >>
> >> sha1: af91658353ba601fc8cd08627e8d36bac62e936a
> >> Git:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative
> >> Artifacts:
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/org/apache/cassandra/apache-cassandra/2.2.14/
> >> Staging repository:
> >>
> https://repository.apache.org/content/repositories/orgapachecassandra-1172/
> >>
> >> The Debian and RPM packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: CHANGES.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> >> [2]: NEWS.txt:
> >>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.14-tentative
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.4

[Marcus Eriksson]

+1

Den ons 6 feb. 2019 kl 10:52 skrev Benedict Elliott Smith <
bened...@apache.org>:

> +1
>
> > On 6 Feb 2019, at 08:01, Tommy Stendahl 
> wrote:
> >
> > +1 (non-binding)
> >
> > /Tommy
> >
> > On lör, 2019-02-02 at 18:31 -0600, Michael Shuler wrote:
> >
> > I propose the following artifacts for release as 3.11.4.
> >
> > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193
> > Git:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/org/apache/cassandra/apache-cassandra/3.11.4/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1170/
> >
> > The Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: CHANGES.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> > [2]: NEWS.txt:
> >
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.4-tentative
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Change Jira Workflow

[Marcus Eriksson]

+1

On Mon, Dec 17, 2018 at 03:19:07PM +, Benedict Elliott Smith wrote:
> I propose these changes 
> *
>  to the Jira Workflow for the project.  The vote will be open for 72 hours**.
> 
> I am, of course, +1.
> 
> * With the addendum of the mailing list discussion 
> ;
>  in case of any conflict arising from a mistake on my part in the wiki, the 
> consensus reached by polling the mailing list will take precedence.
> ** I won’t be around to close the vote, as I will be on vacation.  Everyone 
> is welcome to ignore the result until I get back in a couple of weeks, or if 
> anybody is eager feel free to close the vote and take some steps towards 
> implementation.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: JIRA Workflow Proposals

[Marcus Eriksson]

1. D C B A E
2. B C A
3. A
4. -0.5, leaning towards remove but don't really care

On Tue, Dec 11, 2018 at 06:42:09PM +, Aleksey Yeshchenko wrote:
> 1. C, D, A, B, E
> 2. B, C, A
> 3. A
> 4. Meh
> 
> > On 11 Dec 2018, at 16:28, Benedict Elliott Smith  
> > wrote:
> > 
> > Just to re-summarise the questions for people:
> > 
> > 1. (A) Only contributors may edit or transition issues; (B) Only 
> > contributors may transition issues; (C) Only Jira-users may transition 
> > issues*; (D) (C)+Remove contributor role entirely; (E) Leave permission as 
> > they are today
> > 2. Priority on Bug issue type: (A) remove it; (B) auto-populate it; (C) 
> > leave it.  Please rank.
> > 3. Top priority: (A) Urgent; (B) Blocker.  See here for my explanation of 
> > why I chose Urgent 
> >  >  
> > >.
> > 4. Priority keep ‘Wish’ (to replace issue type): +1/-1
> > 
> > With my answers (again, sorry):
> > 
> > 1: A B C D E
> > 2: B C A
> > 3: A
> > 4: +0.5
> > 
> >> On 11 Dec 2018, at 16:25, Benedict Elliott Smith  
> >> wrote:
> >> 
> >> It looks like we have a multiplicity of views on permissions, so perhaps 
> >> we should complicate this particular vote with all of the possible options 
> >> that have been raised so far (including one off-list).  Sorry everyone for 
> >> the confusion.
> >> 
> >> (A) Only contributors may edit or transition issues; (B) Only contributors 
> >> may transition issues; (C) Only Jira-users may transition issues*; (D) 
> >> (C)+Remove contributor role entirely; (E) Leave permission as they are 
> >> today
> >> 
> >> * Today apparently ‘Anyone’ can perform this operation
> >> 
> >> A ranked vote, please.  This makes my votes:
> >> 
> >> 1: A B C D E
> >> 2: B C A
> >> 3: A
> >> 4: +0.5
> >> 
> >> 
> >>> On 11 Dec 2018, at 05:51, Dinesh Joshi  
> >>> wrote:
> >>> 
> >>> I agree with this. I generally am on the side of freedom and 
> >>> responsibility. Limiting edits to certain fields turns people off. 
> >>> Something I want to very much avoid if we can. 
> >>> 
> >>> Dinesh
> >>> 
>  On Dec 10, 2018, at 6:14 PM, Murukesh Mohanan 
>   wrote:
>  
>  On Tue, 11 Dec 2018 at 10:51, Benedict Elliott Smith
>   wrote:
> > 
> >> On 10 Dec 2018, at 16:21, Ariel Weisberg  wrote:
> >> 
> >> Hi,
> >> 
> >> RE #1, does this mean if you submit a ticket and you are not a 
> >> contributor you can't modify any of the fields including description 
> >> or adding/removing attachments?
> > 
> > Attachment operations have their own permissions, like comments.  
> > Description would be prohibited though.  I don’t see this as a major 
> > problem, really; it is generally much more useful to add comments.  If 
> > we particularly want to make a subset of fields editable there is a 
> > workaround, though I’m not sure anybody would have the patience to 
> > implement it:  
> > https://confluence.atlassian.com/jira/how-can-i-control-the-editing-of-issue-fields-via-workflow-149834.html
> >  
> > 
> > 
>  
>  That would be disappointing. Descriptions with broken or no formatting
>  aren't rare (say, command output without code formatting). And every
>  now and then the description might need to be updated. For example, in
>  https://issues.apache.org/jira/browse/CASSANDRA-10989, the link to the
>  paper had rotted, but I managed to find a new one, so I could edit it
>  in. If such a change had to be posted as a comment, it might easily
>  get lost in some of the more active issues.
>  
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
>  
> >>> 
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>> 
> >> 
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >> 
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h.

Re: Cassandra 4.0 (Trunk) - "ant artifacts" does not create binary tarball

[Marcus Eriksson]

In trunk you need to provide JAVA_HOME to both java8 and java11, like this for 
example;

$ JAVA8_HOME= JAVA_HOME= ant artifacts

/Marcus

On Mon, Nov 12, 2018 at 09:21:10AM +, Steinmaurer, Thomas wrote:
> Hello,
> 
> I'm trying to start with some first C* 4.0 experiments, thus tried to locally 
> build and create binary tarball artifcats. While this has worked e.g. with 
> 3.11, I can't create a binary tarball for 4.0 anymore.
> 
> What I did locally:
> * Switched from branch cassandra-3.11 to trunk
> * ant realclean
> * ant artifacts
> 
> I get the apache-cassandra-4.0-SNAPSHOT.jar created but no binary tarball.
> 
> End of "ant artifacts" console output is:
> 
>   [javadoc]  * the compaction strategy placement reflect most up-to-date disk 
> boundaries, call {@link this#maybeReloadDiskBoundaries()}
>   [javadoc]   
>  ^
>   [javadoc] Building index for all the packages and classes...
>   [javadoc] Building index for all classes...
>   [javadoc] Generating 
> C:\workspaces\git\cassandra\build\javadoc\help-doc.html...
>   [javadoc] 92 errors
>   [javadoc] 100 warnings
> 
> gen-doc:
>  [exec]
>  [exec] The 'sphinx-build' command was not found. Make sure you have 
> Sphinx
>  [exec] installed, then set the SPHINXBUILD environment variable to point
>  [exec] to the full path of the 'sphinx-build' executable. Alternatively 
> you
>  [exec] may add the Sphinx directory to PATH.
>  [exec]
>  [exec] If you don't have Sphinx installed, grab it from
>  [exec] http://sphinx-doc.org/
>  [exec] Result: 1
> 
> artifacts:
> 
> BUILD SUCCESSFUL
> Total time: 3 minutes 14 seconds
> 
> 
> Thanks,
> Thomas
> 
> The contents of this e-mail are intended for the named addressee only. It 
> contains information that may be confidential. Unless you are the named 
> addressee or an authorized designee, you may not copy or use it, or disclose 
> it to anyone else. If you received it in error please notify us immediately 
> and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) 
> is a company registered in Linz whose registered office is at 4040 Linz, 
> Austria, Freist?dterstra?e 313

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Moving tickets out of 4.0 post freeze

[Marcus Eriksson]

ok, I guess I should read properly, we should only fix bugs

On Mon, Sep 24, 2018 at 3:42 PM Marcus Eriksson  wrote:

> I have used the 4.0 version as a "we need this before releasing 4.0" - do
> you have another way of marking tickets we need fixed before releasing?
>
> On Mon, Sep 24, 2018 at 2:09 PM Joshua McKenzie 
> wrote:
>
>> We have quite a few tickets still flagged for 4.0 that aren't in keeping
>> with the idea that the code is frozen:
>>
>>
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(%22New%20Feature%22%2C%20Improvement)
>>
>> I propose we move all new features and improvements to 4.0.x to keep the
>> surface area of change for the major stable.
>>
>

Re: Moving tickets out of 4.0 post freeze

[Marcus Eriksson]

I have used the 4.0 version as a "we need this before releasing 4.0" - do
you have another way of marking tickets we need fixed before releasing?

On Mon, Sep 24, 2018 at 2:09 PM Joshua McKenzie 
wrote:

> We have quite a few tickets still flagged for 4.0 that aren't in keeping
> with the idea that the code is frozen:
>
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20cassandra%20and%20(fixversion%20%3D%204.0%20OR%20fixversion%20%3D%204.0.0)%20and%20resolution%20%3D%20unresolved%20and%20type%20in%20(%22New%20Feature%22%2C%20Improvement)
>
> I propose we move all new features and improvements to 4.0.x to keep the
> surface area of change for the major stable.
>

Re: [VOTE] Release Apache Cassandra 3.0.17 (Take 2)

[Marcus Eriksson]

+1

On Fri, Jul 27, 2018 at 5:03 AM Vinay Chella 
wrote:

> +1 nb.
>
> Here are the test results.
> https://circleci.com/gh/vinaykumarchella/cassandra/tree/3.0.17_tentative
>
> Most of the failed tests are related to snapshot_test.TestArchiveCommitlog.
>
> Regards,
> Vinay Chella
>
>
> On Thu, Jul 26, 2018 at 3:05 PM kurt greaves  wrote:
>
> > +1 nb
> >
> > On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe,  wrote:
> >
> > > +1
> > >
> > > On 25 July 2018 at 08:17, Michael Shuler 
> wrote:
> > >
> > > > I propose the following artifacts for release as 3.0.17.
> > > >
> > > > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6
> > > > Git:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > shortlog;h=refs/tags/3.0.17-tentative
> > > > Artifacts:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1165/org/apache/cassandra/apache-cassandra/3.0.17/
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1165/
> > > >
> > > > The Debian and RPM packages are available here:
> > > > http://people.apache.org/~mshuler
> > > >
> > > > The vote will be open for 72 hours (longer if needed).
> > > >
> > > > [1]: CHANGES.txt:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> > > > [2]: NEWS.txt:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.0.17-tentative
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

[Marcus Eriksson]

+1

On Fri, Jul 27, 2018 at 4:59 AM Vinay Chella 
wrote:

> +1 nb.
>
> Here are the failed tests (circleci
> <
> https://circleci.com/gh/vinaykumarchella/workflows/cassandra/tree/3.11.3_tentative
> >),
> if anyone is curious about failed tests.
>
> dtests-no-vnodes  (5 Failed tests)
> test_short_read - consistency_test.TestConsistency
> test_describecluster_more_information_three_datacenters -
> nodetool_test.TestNodetool
> test_failure_threshold_deletions - paging_test.TestPagingWithDeletions
> test_closing_connections - thrift_hsha_test.TestThriftHSHA
> test_mutation_v5 - write_failures_test.TestWriteFailures
>
> dtests-with-vnodes (6 failed tests)
> test_14330 - consistency_test.TestConsistency
> test_remote_query - cql_test.TestCQLSlowQuery
> test_describecluster_more_information_three_datacenters -
> nodetool_test.TestNodetool
> test_failure_threshold_deletions - paging_test.TestPagingWithDeletions
> test_closing_connections - thrift_hsha_test.TestThriftHSHA
> test_mutation_v5 - write_failures_test.TestWriteFailures
>
> Regards,
> Vinay Chella
>
>
> On Thu, Jul 26, 2018 at 3:06 PM kurt greaves  wrote:
>
> > +1 nb
> >
> > On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe,  wrote:
> >
> > > +1
> > >
> > > On 25 July 2018 at 08:16, Michael Shuler 
> wrote:
> > >
> > > > I propose the following artifacts for release as 3.11.3.
> > > >
> > > > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0
> > > > Git:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > shortlog;h=refs/tags/3.11.3-tentative
> > > > Artifacts:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1164/org/apache/cassandra/apache-cassandra/3.11.3/
> > > > Staging repository:
> > > > https://repository.apache.org/content/repositories/
> > > > orgapachecassandra-1164/
> > > >
> > > > The Debian and RPM packages are available here:
> > > > http://people.apache.org/~mshuler
> > > >
> > > > The vote will be open for 72 hours (longer if needed).
> > > >
> > > > [1]: CHANGES.txt:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> > > > [2]: NEWS.txt:
> > > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > > blob_plain;f=CHANGES.txt;hb=refs/tags/3.11.3-tentative
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > > >
> > > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.13

[Marcus Eriksson]

+1

On Fri, Jul 27, 2018 at 12:05 AM kurt greaves  wrote:

> +1 nb
>
> On Fri., 27 Jul. 2018, 00:20 Sam Tunnicliffe,  wrote:
>
> > +1
> >
> > On 25 July 2018 at 08:17, Michael Shuler  wrote:
> >
> > > I propose the following artifacts for release as 2.2.13.
> > >
> > > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8
> > > Git:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > shortlog;h=refs/tags/2.2.13-tentative
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1167/org/apache/cassandra/apache-cassandra/2.2.13/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1167/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: CHANGES.txt:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> > > [2]: NEWS.txt:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > blob_plain;f=CHANGES.txt;hb=refs/tags/2.2.13-tentative
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: RangeAwareCompaction for manual token management

[Marcus Eriksson]

It should work fine with num_tokens: 1

Without vnodes it also flushes to per-range sstables (if you have RF=3 you
will "always" get 3 sstables after flush), while with vnodes it groups the
ranges and flushes a full disk, so if you have a single
data_file_directories you get only one sstable, then compaction will write
them out to per-range sstables once they accumulates enough data.

/Marcus

On Thu, Jul 19, 2018 at 11:34 PM Carl Mueller
 wrote:

> I don't want to comment on the 10540 ticket since it seems very well
> focused on vnode-aligned sstable partitioning and compaction. I'm pretty
> excited about that ticket. RACS should enable:
>
> - smaller scale LCS, more constrained I/O consumption
> - less sstables to hit in read path
> - multithreaded/multiprocessor compactions and even serving of data based
> on individual vnode or pools of vnodes
> - better alignment of tombstones with data they should be
> nullifying/eventually removing
> - repair streaming efficiency
> - backups have more granularity for not uploading sstables that didn't
> change for the range since last backup snapshot
>
> There is ongoing discussions as to using Priam for cluster management where
> I am, and as I understand it (superficially) Priam does not use vnodes and
> use manual tokens, and expands via node multiples. I believe it has certain
> advantages over vnodes including expanding by multiple machines at once,
> backups could possibly do (nodecount / RF) number of nodes for data backups
> rather than the mess of vnodes where you have to do basically all of them.
>
> But we could still do some divisor split of the manual range and apply RACS
> to that. I guess this would be vnode-lite. We could have some number like
> 100 subranges on a  node and expansion might just involve temporary lower
> bound count of subranges until the sstables can be reprocessed to the
> typical subrange count.
>
> Is this theoretically correct, or are there glaring things I might have
> missed with respect to RACS-style compaction and manual tokens?
>

Re: [VOTE] Branching Change for 4.0 Freeze

[Marcus Eriksson]

+1

On Thu, Jul 12, 2018 at 12:37 AM Jeff Jirsa  wrote:

> +1
>
>
> --
> Jeff Jirsa
>
>
> > On Jul 11, 2018, at 2:46 PM, sankalp kohli 
> wrote:
> >
> > Hi,
> >As discussed in the thread[1], we are proposing that we will not
> branch
> > on 1st September but will only allow following merges into trunk.
> >
> > a. Bug and Perf fixes to 4.0.
> > b. Critical bugs in any version of C*.
> > c. Testing changes to help test 4.0
> >
> > If someone has a change which does not fall under these three, we can
> > always discuss it and have an exception.
> >
> > Vote will be open for 72 hours.
> >
> > Thanks,
> > Sankalp
> >
> > [1]
> >
> https://lists.apache.org/thread.html/494c3ced9e83ceeb53fa127e44eec6e2588a01b769896b25867fd59f@%3Cdev.cassandra.apache.org%3E
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Testing 4.0 Post-Freeze

[Marcus Eriksson]

+1 here as well

On Tue, Jul 10, 2018 at 7:06 PM Aleksey Yeshchenko 
wrote:

> +1 from me too.
>
> —
> AY
>
> On 10 July 2018 at 04:17:26, Mick Semb Wever (m...@apache.org) wrote:
>
>
> > We have done all this for previous releases and we know it has not
> worked
> > well. So how giving it one more try is going to help here. Can someone
> > outline what will change for 4.0 which will make it more successful?
>
>
> I (again) agree with you Sankalp :-)
>
> Why not try something new?
> It's easier to discuss these things more genuinely after trying it out.
>
> One of the differences in the branching approaches: to feature-freeze on a
> 4.0 branch or on trunk; is who it is that has to then merge and work with
> multiple branches.
>
> Where that small but additional effort is placed I think becomes a signal
> to what the community values most: new features or stability.
>
> I think most folk would vote for stability, so why not give this approach
> a go and to learn from it.
> It also creates an incentive to make the feature-freeze period as short as
> possible, moving us towards an eventual goal of not needing to
> feature-freeze at all.
>
> regards,
> Mick
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 2.2.12

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 4:18 PM, Gary Dusbabek  wrote:

> +1
>
> On Mon, Feb 12, 2018 at 2:30 PM, Michael Shuler 
> wrote:
>
> > I propose the following artifacts for release as 2.2.12.
> >
> > sha1: 1602e606348959aead18531cb8027afb15f276e7
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/2.2.12-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1153/org/apache/cassandra/apache-cassandra/2.2.12/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1153/
> >
> > Debian and RPM packages are available here:
> > http://people.apache.org/~mshuler
> >
> > *** This release addresses an important fix for CASSANDRA-14092 ***
> > "Max ttl of 20 years will overflow localDeletionTime"
> > https://issues.apache.org/jira/browse/CASSANDRA-14092
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/QkJeXH
> > [2]: (NEWS.txt) https://goo.gl/A4iKFb
> >
> >
>

Re: [VOTE] Release Apache Cassandra 2.1.20

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:30 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 2.1.20.
>
> sha1: b2949439ec62077128103540e42570238520f4ee
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/2.1.20-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1152/org/apache/cassandra/apache-cassandra/2.1.20/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1152/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/5i2nw9
> [2]: (NEWS.txt) https://goo.gl/i9Fg2u
>
>

Re: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:32 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 3.11.2.
>
> sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.2-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/org/apache/cassandra/apache-cassandra/3.11.2/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1156/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RLZLrR
> [2]: (NEWS.txt) https://goo.gl/kpnVHp
>
>

Re: [VOTE] Release Apache Cassandra 3.0.16

[Marcus Eriksson]

+1

On Tue, Feb 13, 2018 at 1:29 PM, Aleksey Yeshchenko 
wrote:

> +1
>
> —
> AY
>
> On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org)
> wrote:
>
> I propose the following artifacts for release as 3.0.16.
>
> sha1: 91e83c72de109521074b14a8eeae1309c3b1f215
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.16-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1154/org/apache/cassandra/apache-cassandra/3.0.16/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1154/
>
> Debian and RPM packages are available here:
> http://people.apache.org/~mshuler
>
> *** This release addresses an important fix for CASSANDRA-14092 ***
> "Max ttl of 20 years will overflow localDeletionTime"
> https://issues.apache.org/jira/browse/CASSANDRA-14092
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/rLj59Z
> [2]: (NEWS.txt) https://goo.gl/EkrT4G
>
>

Proposal: github pull requests for all code changes

[Marcus Eriksson]

To be able to use the github code review UI and closer CI integration we
should make it obligatory to submit github pull requests for all code
changes.

The process would be:
1. Create or find a JIRA ticket
2. Submit GH pull request
 - one PR per branch (one for 3.0, one for 3.11 etc)
 - the PR title should mention the JIRA ticket so that the PR gets
linked on the JIRA
3. Have it reviewed and approved on GH
4. Committer needs to do the manual work of getting the code committed to
the apache repo like today
   - having "closes #123" in the commit message closes the pull request.
Adding the same line to the merge commit messages should close the PRs for
the different branches

Apache Spark does something similar and their guidelines are here:
https://spark.apache.org/contributing.html

Anyone got any concerns or improvement suggestions to this?

/Marcus

Re: Do it need to run 'nodetool upgradesstables' when updating from 2.0.9 to 2.1.19?

[Marcus Eriksson]

https://issues.apache.org/jira/browse/CASSANDRA-10990

On Fri, Oct 13, 2017 at 9:00 AM, Per Otterström  wrote:

> Hepp!
>
> Just to be clear, I'm not claiming this to be the case, it is a sincere
> question. My team is planning an upgrade from 2.2 to 3.0 which is why I'm
> asking. Some initial tests indicate that repairs etc work well before
> running upgradesstables (assuming all nodes are upgraded to 3.0). But if
> there are known corner cases I'd be interested to know.
>
> We need to support reading old sstables in order to support rolling
> upgrades. This seem to be a general assumption that people agree on. I'm
> not sure there is a clear agreement on the streaming part. Would it make
> sense to clarify this in documentation?
>
> /pelle
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: den 13 oktober 2017 08:09
> To: dev@cassandra.apache.org
> Subject: Re: Do it need to run 'nodetool upgradesstables' when updating
> from 2.0.9 to 2.1.19?
>
> Two people say I’m wrong, I’ll believe it - must be imagining restrictions
> that don’t exist.
>
> --
> Jeff Jirsa
>
>
> > On Oct 12, 2017, at 10:55 PM, Per Otterström <
> per.otterst...@ericsson.com> wrote:
> >
> > Hi!
> >
> > This was news to me. I had the impression that we are maintaining
> backwards compatibility for streaming non-upgraded sstables. Is that not
> the case?
> >
> > However, I believe it is a good idea to run upgradesstables at some
> point _before_ upgrading Cassandra next time to make sure there are no old
> sstables around before you take the next step.
> >
> > /pelle
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: den 12 oktober 2017 23:11
> > To: Cassandra DEV 
> > Subject: Re: Do it need to run 'nodetool upgradesstables' when updating
> from 2.0.9 to 2.1.19?
> >
> > You won't notice any issues (all versions of cassandra are backwards
> compatible at least 1 version), and sstables will be slowly migrated to the
> new format as you compact, but you should still run it (upgradesstables)
> explicitly because when it comes time to run repair/boostrap/decommission/etc,
> you'll need all sstables on the same/current format.
> >
> >
> >
> > On Thu, Oct 12, 2017 at 1:59 PM, Li, Guangxing  >
> > wrote:
> >
> >> Hi,
> >>
> >> I recently upgraded my test cluster from C* 2.0.9 to 2.1.19 and I did
> >> not run 'nodetool upgradesstables' at all. Per my confirmation
> >> afterwards, everything is fine. But according to documentation at
> >> https://support.datastax.com/hc/en-us/articles/208040036-
> >> Nodetool-upgradesstables-FAQ.
> >> I need to do that.
> >> So can someone tell me if I must do 'nodetool upgradesstables' after
> >> upgrading each node from 2.0.9 to 2.1.19?
> >>
> >> Thanks.
> >>
> >> George.
> >>
> >  B‹CB•
> È [œÝXœØÜšX™K  K[XZ[
> ˆ  ]‹][œÝXœØÜšX™P Ø\ÜØ[™ ˜K˜\ XÚ K›Ü™ÃB‘›Üˆ Y  ] [Û˜[  ÛÛ[X[™ Ë  K[XZ[
> ˆ  ]‹Z [   Ø\ÜØ[™ ˜K˜\ XÚ K›Ü™ÃBƒB
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposal to retroactively mark materialized views experimental

[Marcus Eriksson]

I was just thinking that we should try really hard to avoid adding
experimental features - they are experimental due to lack of testing right?
There should be a clear path to making the feature non-experimental (or get
it removed) and having that path discussed on dev@ might give more
visibility to it.

I'm also struggling a bit to find good historic examples of "this would
have been better off as an experimental feature" - I used to think that it
would have been good to commit DTCS with some sort of experimental flag,
but that would not have made DTCS any better - it would have been better to
do more testing, realise that it does not work and then not commit it at
all of course.

Does anyone have good examples of features where it would have made sense
to commit them behind an experimental flag? SASI might be a good example,
but for MVs - if we knew how painful they would be, they really would not
have gotten committed at all, right?

/Marcus

On Sat, Sep 30, 2017 at 7:42 AM, Jeff Jirsa  wrote:

> Reviewers should be able to suggest when experimental is warranted, and
> conversation on dev+jira to justify when it’s transitioned from
> experimental to stable?
>
> We should remove the flag as soon as we’re (collectively) confident in a
> feature’s behavior - at least correctness, if not performance.
>
>
> > On Sep 29, 2017, at 10:31 PM, Marcus Eriksson  wrote:
> >
> > +1 on marking MVs experimental, but should there be some point in the
> > future where we consider removing them from the code base unless they
> have
> > gotten significant improvement as well?
> >
> > We probably need to enforce some kind of process for adding new
> > experimental features in the future - perhaps a mail like this one to
> dev@
> > motivating why it should be experimental?
> >
> > /Marcus
> >
> > On Sat, Sep 30, 2017 at 1:15 AM, Vinay Chella
> 
> > wrote:
> >
> >> We tried perf testing MVs internally here but did not see good results
> with
> >> it, hence paused its usage. +1 on tagging certain features which are not
> >> PROD ready or not stable enough.
> >>
> >> Regards,
> >> Vinay Chella
> >>
> >>> On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead 
> wrote:
> >>>
> >>> I'm a fan of introducing experimental flags in general as well, +1
> >>>
> >>>
> >>>
> >>>> On Fri, 29 Sep 2017 at 13:22 Jon Haddad  wrote:
> >>>>
> >>>> I’m very much +1 on this, and to new features in general.
> >>>>
> >>>> I think having a clear line in which we classify something as
> >> production
> >>>> ready would be nice.  It would be great if committers were using the
> >>>> feature in prod and could vouch for it’s stability.
> >>>>
> >>>>> On Sep 29, 2017, at 1:09 PM, Blake Eggleston 
> >>>> wrote:
> >>>>>
> >>>>> Hi dev@,
> >>>>>
> >>>>> I’d like to propose that we retroactively classify materialized views
> >>> as
> >>>> an experimental feature, disable them by default, and require users to
> >>>> enable them through a config setting before using.
> >>>>>
> >>>>> Materialized views have several issues that make them (effectively)
> >>>> unusable in production. Some of the issues aren’t just implementation
> >>>> problems, but problems with the design that aren’t easily fixed. It’s
> >>>> unfair of us to make features available to users in this state without
> >>>> providing a clear warning that bad or unexpected things are likely to
> >>>> happen if they use it.
> >>>>>
> >>>>> Obviously, this isn’t great news for users that have already adopted
> >>>> MVs, and I don’t have a great answer for that. I think that’s sort of
> a
> >>>> sunk cost at this point. If they have any MV related problems, they’ll
> >>> have
> >>>> them whether they’re marked experimental or not. I would expect this
> to
> >>>> reduce the number of users adopting MVs in the future though, and if
> >> they
> >>>> do, it would be opt-in.
> >>>>>
> >>>>> Once MVs reach a point where they’re usable in production, we can
> >>> remove
> >>>> the flag. Specifics of how the experimental flag would work can be
> >>> hammered
> >>>> out in a forthcoming JIRA, but I’d imagine it would just prevent users
> >>> from
> >>>> creating new MVs, and maybe log warnings on startup for existing MVs
> if
> >>> the
> >>>> flag isn’t enabled.
> >>>>>
> >>>>> Let me know what you think.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Blake
> >>>>
> >>>>
> >>>> -
> >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>
> >>>> --
> >>> Ben Bromhead
> >>> CTO | Instaclustr <https://www.instaclustr.com/>
> >>> +1 650 284 9692
> >>> Reliability at Scale
> >>> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> >>>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposal to retroactively mark materialized views experimental

[Marcus Eriksson]

+1 on marking MVs experimental, but should there be some point in the
future where we consider removing them from the code base unless they have
gotten significant improvement as well?

We probably need to enforce some kind of process for adding new
experimental features in the future - perhaps a mail like this one to dev@
motivating why it should be experimental?

/Marcus

On Sat, Sep 30, 2017 at 1:15 AM, Vinay Chella 
wrote:

> We tried perf testing MVs internally here but did not see good results with
> it, hence paused its usage. +1 on tagging certain features which are not
> PROD ready or not stable enough.
>
> Regards,
> Vinay Chella
>
> On Fri, Sep 29, 2017 at 7:22 PM, Ben Bromhead  wrote:
>
> > I'm a fan of introducing experimental flags in general as well, +1
> >
> >
> >
> > On Fri, 29 Sep 2017 at 13:22 Jon Haddad  wrote:
> >
> > > I’m very much +1 on this, and to new features in general.
> > >
> > > I think having a clear line in which we classify something as
> production
> > > ready would be nice.  It would be great if committers were using the
> > > feature in prod and could vouch for it’s stability.
> > >
> > > > On Sep 29, 2017, at 1:09 PM, Blake Eggleston 
> > > wrote:
> > > >
> > > > Hi dev@,
> > > >
> > > > I’d like to propose that we retroactively classify materialized views
> > as
> > > an experimental feature, disable them by default, and require users to
> > > enable them through a config setting before using.
> > > >
> > > > Materialized views have several issues that make them (effectively)
> > > unusable in production. Some of the issues aren’t just implementation
> > > problems, but problems with the design that aren’t easily fixed. It’s
> > > unfair of us to make features available to users in this state without
> > > providing a clear warning that bad or unexpected things are likely to
> > > happen if they use it.
> > > >
> > > > Obviously, this isn’t great news for users that have already adopted
> > > MVs, and I don’t have a great answer for that. I think that’s sort of a
> > > sunk cost at this point. If they have any MV related problems, they’ll
> > have
> > > them whether they’re marked experimental or not. I would expect this to
> > > reduce the number of users adopting MVs in the future though, and if
> they
> > > do, it would be opt-in.
> > > >
> > > > Once MVs reach a point where they’re usable in production, we can
> > remove
> > > the flag. Specifics of how the experimental flag would work can be
> > hammered
> > > out in a forthcoming JIRA, but I’d imagine it would just prevent users
> > from
> > > creating new MVs, and maybe log warnings on startup for existing MVs if
> > the
> > > flag isn’t enabled.
> > > >
> > > > Let me know what you think.
> > > >
> > > > Thanks,
> > > >
> > > > Blake
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > > --
> > Ben Bromhead
> > CTO | Instaclustr 
> > +1 650 284 9692
> > Reliability at Scale
> > Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
> >
>

Re: [VOTE] Release Apache Cassandra 2.2.11

[Marcus Eriksson]

+1

On Fri, Sep 29, 2017 at 12:15 AM, Vinay Chella 
wrote:

> +1
>
> On Thu, Sep 28, 2017 at 8:45 PM, Josh McKenzie 
> wrote:
>
> > +1
> >
> > On Thu, Sep 28, 2017 at 2:14 PM, Aleksey Yeshchenko 
> > wrote:
> >
> > > +1
> > >
> > > —
> > > AY
> > >
> > > On 28 September 2017 at 19:41:13, Michael Shuler (
> mich...@pbandjelly.org
> > )
> > > wrote:
> > >
> > > I propose the following artifacts for release as 2.2.11.
> > >
> > > sha1: c510e001481637e1f74d9ad176f8dc3ab7ebd1e3
> > > Git:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > shortlog;h=refs/tags/2.2.11-tentative
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1149/org/apache/cassandra/apache-cassandra/2.2.11/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1149/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: (CHANGES.txt) https://goo.gl/qTG7xU (also RPM file ownership fix)
> > > [2]: (NEWS.txt) https://goo.gl/ggdkLH
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: [VOTE] Release Apache Cassandra 2.1.19

[Marcus Eriksson]

+1

On Fri, Sep 29, 2017 at 12:14 AM, Vinay Chella 
wrote:

> +1
>
> On Thu, Sep 28, 2017 at 8:38 PM, Josh McKenzie 
> wrote:
>
> > +1
> >
> > On Thu, Sep 28, 2017 at 2:13 PM, Aleksey Yeshchenko 
> > wrote:
> >
> > > +1
> > >
> > > —
> > > AY
> > >
> > > On 28 September 2017 at 19:12:19, Michael Shuler (
> mich...@pbandjelly.org
> > )
> > > wrote:
> > >
> > > I propose the following artifacts for release as 2.1.19.
> > >
> > > sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c
> > > Git:
> > > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > > shortlog;h=refs/tags/2.1.19-tentative
> > > Artifacts:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1148/org/apache/cassandra/apache-cassandra/2.1.19/
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/
> > > orgapachecassandra-1148/
> > >
> > > The Debian and RPM packages are available here:
> > > http://people.apache.org/~mshuler
> > >
> > > The vote will be open for 72 hours (longer if needed).
> > >
> > > [1]: (CHANGES.txt) https://goo.gl/1sZLdP (also RPM file ownership fix)
> > > [2]: (NEWS.txt) https://goo.gl/YKEuRc
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> > >
> >
>

Re: STCS in L0 behaviour

[Marcus Eriksson]

The reason is described here:
https://issues.apache.org/jira/browse/CASSANDRA-5371?focusedCommentId=13621679&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13621679

/Marcus

On Wed, Nov 23, 2016 at 6:31 PM, Jeff Jirsa 
wrote:

> What you’re describing seems very close to what’s discussed in
> https://issues.apache.org/jira/browse/CASSANDRA-10979 - worth reading
> that ticket a bit.
>
>
>
> There does seem to be a check for STCS in L0 before it tries higher
> levels:
>
> https://github.com/apache/cassandra/blob/cassandra-2.2/
> src/java/org/apache/cassandra/db/compaction/LeveledManifest.java#L324-L326
>
>
>
> Why it’s doing that within the for loop (https://github.com/apache/
> cassandra/blob/cassandra-2.2/src/java/org/apache/cassandra/
> db/compaction/LeveledManifest.java#L310 ) is unexpected to me, though –
> Carl / Marcus, any insight into why it’s within the loop instead of before
> it?
>
>
>
>
>
> *From: *Marcus Olsson 
> *Organization: *Ericsson AB
> *Reply-To: *"dev@cassandra.apache.org" 
> *Date: *Wednesday, November 23, 2016 at 7:52 AM
> *To: *"dev@cassandra.apache.org" 
> *Subject: *STCS in L0 behaviour
>
>
>
> Hi everyone,
>
>
> TL;DR
> Should LCS be changed to always prefer an STCS compaction in L0 if it's
> falling behind? Assuming that STCS in L0 is enabled.
> Currently LCS seems to check if there is a possible L0->L1 compaction
> before checking if it's falling behind, which in our case used between
> 15-30% of the compaction thread CPU.
> TL;DR
>
> So first some background:
> We have a Apache Cassandra 2.2 cluster running with a high load. In that
> cluster there is a table with a moderate amount of writes per second that
> is using LeveledCompactionStrategy. The test was to run repair on that
> table while we monitored the cluster through JMC and with Flight Recordings
> enabled. This resulted in a large amount of sstables for that table, which
> I assume others have experienced as well. In this case I think it was
> between 15-20k.
>
> From the Flight Recording one thing we saw was that 15-30% of the CPU time
> in each of the compaction threads was spent on "getNextBackgroundTask()"
> which retrieves the next compaction job. With some further investigation
> this seems to mostly be when it's checking for overlap in L0 sstables
> before performing an L0->L1 compaction. There is a JIRA which seems to be
> related to this https://issues.apache.org/jira/browse/CASSANDRA-11571
> 
> which we backported to 2.2 and tested. In our testing it seemed to improve
> the situation but it was still using noticeable CPU.
>
> My interpretation of the current logic of LCS is (if STCS in L0 is
> enabled):
> 1. Check each level (L1+)
>  - If a L1+ compaction is needed check if L0 is behind and do STCS if
> that's the case, otherwise do the L1+ compaction.
> 2. Check L0 -> L1 compactions and if none is needed/possible check for
> STCS in L0.
>
> My proposal is to change this behavior to always check if L0 is far behind
> first and do a STCS compaction in that case. This would avoid the overlap
> check for L0 -> L1 compactions when L0 is behind and I think it makes sense
> since we already prefer STCS to L1+ compactions. This would not solve the
> repair situation, but it would lower some of the impact that repair has on
> LCS.
>
> For what version this could get in I think trunk would be enough since
> compaction is pluggable.
>
> --
>
>
>
> [image: ricsson]
> 
>
> *MARCUS OLSSON *
> Software Developer
>
> *Ericsson*
> Sweden
> marcus.ols...@ericsson.com
> www.ericsson.com
> 
>

Re: Compaction strategy contribution

[Marcus Eriksson]

Any code specific questions can be asked here or in #cassandra-dev on
freenode.

Discussion regarding usefulness etc is probably best to keep in a JIRA
ticket.

/Marcus

On Mon, Jul 11, 2016 at 7:06 PM, Pedro Gordo 
wrote:

> Hi all
>
> I'm finishing an MSc in which my final project is to implement a new
> compaction strategy in Cassandra. I've discussed the main points of the
> strategy with other community members and received valuable feedback.
> However, I understand this will be a tough challenge for someone who has
> never worked with Cassandra, but after getting to know the technology, I've
> found it fascinating. This mixed with always wanting to contribute to an
> ope source project led me to chose it as the topic for my MSC Project.
>
> But because this is my first time contributing to an open source project,
> I've some questions on how to proceed correctly. Looking at the Contribute
>  page, I see that we're
> supposed to create a ticket before starting working on it, so should I just
> create one or does the strategy usefulness need to be validated by someone
> before? In this case, should I just proceed and implement it, or do
> something else? And finally, is this the correct mailing list to be asking
> this sort of questions? :)
>
> As for the code itself, in case I have a question like "Should we be using
> an abstract class for compaction classes?" or "What is this method supposed
> to do?", can I ask here?
> What is the best course of action to learn about the details of the code in
> Cassandra? I already saw that it has some comments, but probably won't be
> enough for me.
>
> The strategy I have in mind will be very simple until I finish the MSc.
> After that, I'll improve it with other features and feedback I got, but for
> the moment, it'll rely on a time interval (probably scheduled at specific
> hours, maybe during a time with less traffic on the system). During that
> time interval, the rows will be made unique across all SSTables, but only
> if, after a prior analysis, we find that the row exists in a certain number
> of SSTables above a certain threshold.
>
> I suppose it's a naive strategy, but the aim here is to give me experience
> with C*, and of course I'll be happy to take suggestions. But I'll probably
> only use the ideas after delivering the project because, at the moment, I
> need to keep it simple. Otherwise, I'll never be able to deliver the
> project. :)
>
> Sorry for the long email, and thanks for all the help in advance! I'm very
> excited about this project and look forward to being part of this
> community!
>
> Best regards
> Pedro Gordo
>

Re: Compaction Filter in Cassandra

[Marcus Eriksson]

We don't have anything like that, do you have a specific use case in mind?

Could you create a JIRA ticket and we can discuss there?

/Marcus

On Sat, Mar 12, 2016 at 7:05 AM, Dikang Gu  wrote:

> Hello there,
>
> RocksDB has the feature called "Compaction Filter" to allow application to
> modify/delete a key-value during the background compaction.
> https://github.com/facebook/rocksdb/blob/v4.1/include/rocksdb/options.h#L201-L226
>
> I'm wondering is there a plan/value to add this into C* as well? Or is
> there already a similar thing in C*?
>
> Thanks
>
> --
> Dikang
>
>

Re: Proposal: release 2.2 (based on current trunk) before 3.0 (based on 8099)

[Marcus Eriksson]

We should get https://issues.apache.org/jira/browse/CASSANDRA-8568 in 2.2
as well (it is patch avail and I'll get it reviewed this week)

/Marcus

On Mon, May 11, 2015 at 9:42 PM, Jonathan Ellis  wrote:

> Sounds good.  I will add the new version to Jira.
>
> Planned tickets to block 2.2 beta for:
>
> #8374
> #8984
> #9190
>
> Any others?  (If it's not code complete today we should not block for it.)
>
>
> On Mon, May 11, 2015 at 1:59 PM, Aleksey Yeschenko 
> wrote:
>
> > > So I think EOLing 2.0.x when 2.2 comes
> > > out is reasonable, especially considering that 2.2 is realistically a
> > month
> > > or two away even if we can get a beta out this week.
> >
> > Given how long 2.0.x has been alive now, and the stability of 2.1.x at
> the
> > moment, I’d say it’s fair enough to EOL 2.0 as soon as 2.2 gets out.
> Can’t
> > argue here.
> >
> > > If push comes to shove I'm okay being ambiguous here, but can we just
> > say
> > > "when 3.0 is released we EOL 2.1?"
> >
> > Under our current projections, that’ll be exactly “a few months after 2.2
> > is released”, so I’m again fine with it.
> >
> > > P.S. The area I'm most concerned about introducing destabilizing
> changes
> > in
> > > 2.2 is commitlog
> >
> > So long as you don’t you compressed CL, you should be solid. You are
> > probably solid even if you do use compressed CL.
> >
> > Here are my only concerns:
> >
> > 1. New authz are not opt-in. If a user implements their own custom
> > authenticator or authorized, they’d have to upgrade them sooner. The test
> > coverage for new authnz, however, is better than the coverage we used to
> > have before.
> >
> > 2. CQL2 is gone from 2.2. Might force those who use it migrate faster. In
> > practice, however, I highly doubt that anybody using CQL2 is also someone
> > who’d already switch to 2.1.x or 2.2.x.
> >
> >
> > --
> > AY
> >
> > On May 11, 2015 at 21:12:26, Jonathan Ellis (jbel...@gmail.com) wrote:
> >
> > On Sun, May 10, 2015 at 2:42 PM, Aleksey Yeschenko 
> > wrote:
> >
> > > 3.0, however, will require a stabilisation period, just by the nature
> of
> > > it. It might seem like 2.2 and 3.0 are closer to each other than 2.1
> and
> > > 2.2 are, if you go purely by the feature list, but in fact the opposite
> > is
> > > true.
> > >
> >
> > You are probably right. But let me push back on some of the extra work
> > you're proposing just a little:
> >
> > 1) 2.0.x branch goes EOL when 3.0 is out, as planned
> > >
> >
> > 3.0 was, however unrealistically, planned for April. And it's moving the
> > goalposts to say the plan was always to keep 2.0.x for three major
> > releases; the plan was to EOL with "the next major release after 2.1"
> > whether that was called 3.0 or not. So I think EOLing 2.0.x when 2.2
> comes
> > out is reasonable, especially considering that 2.2 is realistically a
> month
> > or two away even if we can get a beta out this week.
> >
> > 2) 3.0.x LTS branch stays, as planned, and helps us stabilise the new
> > > storage engine
> > >
> >
> > Yes.
> >
> >
> > > 3) in a few months after 2.2 gets released, we EOL 2.1. Users upgrade
> to
> > > 2.2, get the same stability as with 2.1.7, plus a few new features
> > >
> >
> > If push comes to shove I'm okay being ambiguous here, but can we just say
> > "when 3.0 is released we EOL 2.1?"
> >
> > P.S. The area I'm most concerned about introducing destabilizing changes
> in
> > 2.2 is commitlog; I will follow up to make sure we have a solid QA plan
> > there.
> >
> > --
> > Jonathan Ellis
> > Project Chair, Apache Cassandra
> > co-founder, http://www.datastax.com
> > @spyced
> >
>
>
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>

Re: March 2015 QA retrospective

[Marcus Eriksson]

On Fri, Apr 10, 2015 at 8:34 PM, Ariel Weisberg  wrote:

> Hi Marcus,
>
> CASSANDRA-8211 
> Overlapping
> sstables in L1+
>
> So the question I would ask is would the workload that reproduces this
> specific bug be interesting in the general sense. Do we have to do anything
> special to reproduce it like make many non-verlapping sstables in L0 and is
> that interesting in the general sense.
>

The way I reproduced it was (and I doubt it is interesting in the general
case)
* insert 10M keys with stress
* major compact
* stop node
* sstablesplit
* start node
* switch to LCS
* wait, repeat if no error within 5 minutes

ie, very specific to the bug


>
> CASSANDRA-8320 
>  2.1.2: NullPointerException in SSTableWriter
>
> What tests did we add for this? Is it a targeted regression test, or are we
> now fully exercising SSTableRewriter the way users do against
> representative configurations and data?
>
>
Yes, we added unit tests that exercises the code in SSTableRewriter


> CASSANDRA-8432 
> Standalone
> Scrubber broken for LCS
>
> OK great. Looks like I didn't need to ask Jeremiah to do to look at the
> offline tools.
>
> CASSANDRA-8386  Make
> sure we release references to sstables after incremental repair
> CASSANDRA-8316  "Did
> not get positive replies from all endpoints" error on incremental repair
> CASSANDRA-8580 
> AssertionErrors
> after activating unchecked_tombstone_compaction with leveled compaction
> CASSANDRA-8458 
> Don't
> give out positions in an sstable beyond its first/last tokens
>
> Can you capture the elements of what we need and put it under
> CASSANDRA-9012. Maybe a ticket for testing repair under load, a ticket for
> switching compaction strategies and what the test scenarios for that would
> be, and when you say configurations what kind of configurations are you
> thinking of?
>

will add subtickets to #9012


>
> CASSANDRA-8525 
> Bloom
> Filter truePositive counter not updated on key cache hit
>
> I think for JMX we only need to test that the access path delivers the
> value. Knowing we had to test for the value was I think an original
> implementer and reviewer issue. There was a metric exposed by the unit so
> we needed a test that shows the metric has a correct value.
>
> CASSANDRA-8532  Fix
> calculation of expected write size during compaction
> https://issues.apache.org/jira/browse/CASSANDRA-8562 Fix checking
> available disk
> space before compaction starts
>
> Great. Linked 9154 to 9012 (Triage missing tests)
>
> CASSANDRA-8635  STCS
> cold sstable omission does not handle overwrites without reads
>
> Can you create a ticket for this then? We should emit this workload pattern
> and then validate after that utilization is as expected.
>
> Alternatively this could be caught as a performance regression? It's
> starting to seem like some regressions could be caught as performance
> regressions.
>

Yes this would definitely be caught in a performance test, if the workload
was correct (ie, very few reads, many writes)

/Marcus

Re: [VOTE] Release Apache Cassandra 2.0.12

[Marcus Eriksson]

regression introduced in
https://issues.apache.org/jira/browse/CASSANDRA-8329 - fixed in
https://issues.apache.org/jira/browse/CASSANDRA-8562 - could we include
that?

On Sat, Jan 10, 2015 at 9:25 AM, Sylvain Lebresne 
wrote:

> +1
>
> On Sat, Jan 10, 2015 at 1:32 AM, Aleksey Yeschenko 
> wrote:
>
> > +1
> >
> > --
> > AY
> >
> > On January 10, 2015 at 1:35:46 AM, Jake Luciani (j...@apache.org) wrote:
> >
> > I propose the following artifacts for release as 2.0.12.
> >
> > sha1: df1f5ead0950d4d3058cf6fe0fcae9ef528014fa
> > Git:
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.12-tentative
> > Artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/org/apache/cassandra/apache-cassandra/2.0.12/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1041/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~jake
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/7JmQWg (CHANGES.txt)
> > [2]: http://goo.gl/bqxiFR (NEWS.txt)
> >
>

Re: Reminder: 68 patches pending review

[Marcus Eriksson]

On Thu, Oct 2, 2014 at 1:17 AM, Pavel Yaskevich  wrote:

> Hi Jonathan,
>
>I have commented on 7885 and can take something of Yuki or Marcus if
> they don't mind.
>

https://issues.apache.org/jira/browse/CASSANDRA-7872 perhaps?

/Marcus

Re: Pointers on writing your own Compaction Strategy

[Marcus Eriksson]

1. create a class that extends AbstractCompactionStrategy (i would keep it
in-tree while developing to avoid having classpath issues etc)
2. Implement the abstract methods
   - getNextBackgroundTask - called when cassandra wants to do a new minor
(background) compaction - return a CompactionTask with the sstables you
want compacted
   - getMaximalTask - called when a user triggers a major compaction
   - getUserDefinedTask - when a user triggers a user defined compaction
from JMX
   - getEstimatedRemainingTasks - return the guessed number of tasks before
we are "done"
   - getMaxSSTableBytes - if your compaction strategy puts a limit on the
size of sstables
3. Execute this in cqlsh to enable your compaction strategy: ALTER TABLE
foo WITH compaction = { class: ‘Bar’ }
4. Things to think about:
- make sure you mark sstables as compacting before returning them from
the compaction strategy (and check the return value!):
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/db/compaction/SizeTieredCompactionStrategy.java#L271
- if you do this on 2.1 - dont mix repaired and unrepaired sstables
(SSTableReader#isRepaired)

Let me know if you need any more information

/Marcus



On Thu, Sep 4, 2014 at 6:50 PM, Ghosh, Mainak  wrote:

> Hello,
>
> I am planning to write a new compaction strategy and I was hoping if
> anyone can point me to the relevant functions and how they are related in
> the call hierarchy.
>
> Thanks for the help.
>
> Regards,
> Mainak.
>

Re: Proposed changes to C* Release Schedule

[Marcus Eriksson]

I totally understand where you are coming from, I've been in the same
situation before, but;

In my experience the only time you want new features in your database is
during development, once the application you built is in production and
stable you really _never_ want to upgrade the db until there is something
major solved (like repair in 2.1 or streaming in 2.0).

Then, even if we did backport features to these experimental branches, you
are extremely likely to fall far behind in those as well, making it equally
painful to qa/upgrade.

I think I would have appreciated having an LTS-like-version back when I was
running clusters where I could basically automate rolling minor versions
without having to worry about something breaking and then once every 6
months/year bite the bullet and do the QA needed for a major upgrade.

So maybe it would be worth it having branches/releases something like:
3.0: bug fixes
3.1: bug fixes from 3.0 + small new non-breaking features
trunk (future 4.0): everything from 3.1 + new breaking features

Of course, as others have noted, this degenerates into merging hell once
4.0 is released

/Marcus




On Tue, Jun 17, 2014 at 7:32 PM, Michael Kjellman <
mkjell...@internalcircle.com> wrote:

> Agreed. But I think shrinking the release cycle naturally will get
> features into usable releases more quickly solving b as well. :)
>
> > On Jun 17, 2014, at 10:28 AM, "Jake Luciani"  wrote:
> >
> > So there are two issues this proposal is trying to address:
> >
> > 1. Shrink the release cycle.
> >
> > 2. Backport things to stable releases.
> >
> > We should discuss these separately since together it's hard to discuss.
> > 1. is less controversial I would think :)
> >
> >
> >
> >
> >
> >
> > On Tue, Jun 17, 2014 at 1:16 PM, Michael Kjellman <
> > mkjell...@internalcircle.com> wrote:
> >
> >> Totally agree — "Also — i’m aware that any additional branches/releases
> >> will add additional work for any developer that works on C*. It would be
> >> great if we could strike a balance that hopefully doesn’t add
> significant
> >> additional merging/rebasing/work for the team…”
> >>
> >> That being said I don’t think i’m alone by identifying the problem. The
> >> proposed solution was what we came up with in the hour or so we
> discussed
> >> this in person. How else can you shrink the release schedule without
> >> creating another branch? Also — the idea is to only have this branch
> >> “active” during the overlap when major release branches need to
> stabilize.
> >>
> >>> On Jun 17, 2014, at 10:03 AM, Brandon Williams 
> wrote:
> >>>
> >>> If that's what we want, merging is going to be much more painful.
> >>> Currently we merge:
> >>>
> >>> 1.2->2.0->2.1->3.0
> >>>
> >>> If we add an experimental branch for each, we still have to merge the
> >>> stable branch into experiemental:
> >>>
> >>> 1-2->1.2ex, 2.0->2.0ex, 2.1->2.1ex, 3.0->3.0ex
> >>>
> >>> And then the experimentals into each other:
> >>>
> >>> 1.2ex->2.0ex, 2.0ex->2.1ex, 2.1ex->3.0ex
> >>>
> >>> That's quite a lot of merging in the end.
> >>>
> >>>
>  On Tue, Jun 17, 2014 at 11:51 AM, Jake Luciani 
> wrote:
> 
>  I'm not sure many people have the problem you are describing.  This is
> >> more
>  of a C* developer issue than a C* user issue.
> 
> 
>  Is the below what you are describing we move to?:
> 
>  1.2 -> 2.0 -> 2.1 -> 3.0 stable
>  1.2 <- 2.0 <- 2.1 <- 3.0 experimental
> 
>  Specific changes would be backported based on the "less riskyness" of
> >> the
>  change which you are assuming will be constant across versions?
> 
>  -Jake
> 
> 
> 
> 
>  On Tue, Jun 17, 2014 at 12:28 PM, Michael Kjellman <
>  mkjell...@internalcircle.com> wrote:
> 
> > It's a bit about features - but it's more an attempt to achieve the
> >> goals
> > of what might happen with a 4 week release cycle (but that itself --
> in
> > practice didn't prove to be valid/reasonable).
> >
> > If something like an executor service for performance is changed (for
> > example) it is definitely a more risky change than what would
> currently
>  go
> > into 1.2 -- but most likely we would want to get patches like that
> >> into a
> > usable build.
> >
> > So I guess: a) reduce code drift between branches we run in
> production
> >> b)
> > get newer "features" into production faster where breaking changes
> >> aren't
> > required for the scope of the patch.
> >
> > Additionally - it's also a question of what release we use when we
> > identify an issue we want to work on internally. If we are on 1.2
> >> because
> > we can't yet take ALL of 2.0 - do we now need to target our work
> >> against
> > 1.2? I would rather write it against the months worth of changes that
>  have
> > happened since.
> >
> > Finally, it's an attempt to make the internal forking not as common
> as
> >> it
> > might be tod

Re: [VOTE] Release Apache Cassandra 2.1.0-rc1

[Marcus Eriksson]

+1


On Fri, May 30, 2014 at 8:28 PM, Brandon Williams  wrote:

> +1
>
>
> On Fri, May 30, 2014 at 11:38 AM, Sylvain Lebresne 
> wrote:
>
> > We've fixed all the bugs we had open for 2.1 so it's time to move on
> > towards
> > the final release. I thus propose the following artifacts for release as
> > 2.1.0-rc1.
> >
> > sha1: c108ce5bf2abc88077c97924def59fa1ea98a66e
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.0-rc1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1013/org/apache/cassandra/apache-cassandra/2.1.0-rc1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1013/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~slebresne/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/rAsFCf (CHANGES.txt)
> > [2]: http://goo.gl/9izAkd (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 2.1.0-beta1

[Marcus Eriksson]

+1


On Mon, Feb 17, 2014 at 9:37 PM, Brandon Williams  wrote:

> +1
>
>
> On Mon, Feb 17, 2014 at 11:23 AM, Sylvain Lebresne  >wrote:
>
> > Cassandra 2.1 is coming along but we now need wider testing. So I propose
> > the
> > following artifacts for release as 2.1.0-beta1. Let it be clear that it
> is
> > only
> > a beta (and the first one at that), so we know it's not perfect, but the
> > current goal is first and foremost to get wider testing.
> >
> > sha1: 73dcdbdf294d5e44f44e7e7eb17655bc40240a61
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.0-beta1-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1006/org/apache/cassandra/apache-cassandra/2.1.0-beta1/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-1006/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~slebresne/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/EhrN7D (CHANGES.txt)
> > [2]: http://goo.gl/D1gBmv (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 2.0.5 (Strike 3)

[Marcus Eriksson]

+1


On Wed, Feb 5, 2014 at 10:50 AM, Sylvain Lebresne wrote:

> As said while closing the previous vote, we needed to re-roll for
> CASSANDRA-6648, so I propose the following artifacts for release as 2.0.5.
> I also propose an expedited 24h vote.
>
> sha1: 29670eb6692f239a3e9b0db05f2d5a1b5d4eb8b0
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.5-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1005/org/apache/cassandra/apache-cassandra/2.0.5/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1005/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 24 hours (longer if needed).
>
> [1]: http://goo.gl/B6rgA6 (CHANGES.txt)
> [2]: http://goo.gl/5qaw5i (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 1.2.15

[Marcus Eriksson]

+1


On Wed, Feb 5, 2014 at 9:23 AM, Sylvain Lebresne wrote:

> We just released 1.2.14 but unfortunately it shipped with a relatively
> serious
> regression: https://issues.apache.org/jira/browse/CASSANDRA-6648. That
> regression has been fixed, but we need to get that fix to users, so I
> propose
> the following artifacts for release as 1.2.15. As there has been little
> changes
> since 1.2.14 (outside the fix for #6648) and since it would be best to get
> this
> fix to users sooner than later, we'll stick to an expedited 24h vote.
>
> sha1: 178e086f1aaa2744dfc8046c9abb0c62e8a65895
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.15-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1004/org/apache/cassandra/apache-cassandra/1.2.15/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1004/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 24 hours (longer if needed).
>
> [1]: http://goo.gl/AuCbcg (CHANGES.txt)
> [2]: http://goo.gl/Fnaj65 (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 2.0.5 (Strike 2)

[Marcus Eriksson]

+1


On Mon, Feb 3, 2014 at 10:07 AM, Sylvain Lebresne wrote:

> With typo introduced by CASSANDRA-6505 fixed, I propose the following
> artifacts
> for release as 2.0.5.
>
> sha1: b71372146135fdcee6353ec8254ebfd87c42f907
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.5-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1003/org/apache/cassandra/apache-cassandra/2.0.5/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1003/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 48 hours (longer if needed).
>
> [1]: http://goo.gl/B6rgA6 (CHANGES.txt)
> [2]: http://goo.gl/5qaw5i (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 1.2.14

[Marcus Eriksson]

+1


On Fri, Jan 31, 2014 at 12:33 PM, Sylvain Lebresne wrote:

> I propose the following artifacts for release as 1.2.14.
>
> sha1: 6a9314408cbd69ce26c2ba04bf49df7809a911bf
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/1.2.14-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1000/org/apache/cassandra/apache-cassandra/1.2.14/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1000/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/MpQunt (CHANGES.txt)
> [2]: http://goo.gl/VLWyfI (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 2.0.3 (Strike 2)

[Marcus Eriksson]

would it be possible to include
https://issues.apache.org/jira/browse/CASSANDRA-6284 ? It is tagged 2.0.4
but it feels pretty serious.


On Fri, Nov 22, 2013 at 6:32 PM, Vijay  wrote:

> +1
>
> Regards,
> 
>
>
> On Fri, Nov 22, 2013 at 2:24 PM, Sylvain Lebresne  >wrote:
>
> > With now CASSANDRA-6374 included, I propose the following artifacts for
> > release as
> > 2.0.3.
> >
> > sha1: 3c9760bdb986f6c2430adfc13c86ecb75c3246ac
> > Git:
> >
> >
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.2-tentative
> > Artifacts:
> >
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-164/org/apache/cassandra/apache-cassandra/2.0.2/
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachecassandra-164/
> >
> > The artifacts as well as the debian package are also available here:
> > http://people.apache.org/~slebresne/
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: http://goo.gl/Ougwt2 (CHANGES.txt)
> > [2]: http://goo.gl/8O6gX2 (NEWS.txt)
> >
>

Re: [VOTE] Release Apache Cassandra 2.0.0-beta1

[Marcus Eriksson]

+1


On Tue, Jul 9, 2013 at 11:20 AM, Sylvain Lebresne wrote:

> Cassandra 2.0 is coming along but we now need wider testing. So I propose
> the
> following artifacts for release as 2.0.0-beta1. Let it be clear that it is
> only
> a beta (and the first one at that), so we know it's not perfect, but the
> current goal is first and foremost to get better testing.
>
> sha1: fcdb39384e8570cf38c027f38b799181da06d56d
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.0.0-beta1-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-117/org/apache/cassandra/apache-cassandra/2.0.0-beta1/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-117/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~slebresne/
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: http://goo.gl/LorY5 (CHANGES.txt)
> [2]: http://goo.gl/zEt5i (NEWS.txt)
>