Re: [DISCUSS] CommitLog default disk access mode

[Sam]

*Glad you brought up compaction here - I think there would be a significant
benefit to moving compaction to direct i/o.*

+1. Would love to see this get traction.

On Mon, 16 Oct 2023 at 19:38, Jon Haddad  wrote:

> Glad you brought up compaction here - I think there would be a significant
> benefit to moving compaction to direct i/o.
>
>
> On 2023/10/16 16:14:28 Benedict wrote:
> > I have some plans to (eventually) use the commit log as memtable payload
> storage (ie memtables would reference the commit log entries directly,
> storing only indexing info), and to back first level of sstables by
> reference to commit log entries. This will permit us to deliver not only
> much bigger memtables (cutting compaction throughput requirements by the
> ratio of size increase - so pretty dramatically), and faster flushing (so
> better behaviour ling write bursts), but also a fairly cheap and simple way
> to support MVCC - which will be helpful for transaction throughput.
> >
> > There is also a new commit log (“journal”) coming with Accord, that the
> rest of C* may or may not transition to.
> >
> > I only say this because this makes the utility of direct IO for commit
> log suspect, as we will be reading from the files as a matter of course
> should this go ahead; and we may end up relying on a different commit log
> implementation before long anyway.
> >
> > This is obviously a big suggestion and is not guaranteed to transpire,
> and probably won’t within the next year or so, but it should perhaps form
> some minimal part of any calculus. If the patch is otherwise simple and
> beneficial I don’t have anything against it, and the use of direct IO could
> well be of benefit eg in compaction - and also in future if we manage to
> bring a page management in process. So laying foundations there could be of
> benefit, even if the commit log eventually does not use it.
> >
> > > On 16 Oct 2023, at 17:00, Jon Haddad 
> wrote:
> > >
> > > I haven't looked at the patch, but at a high level, defaulting to
> direct I/O for commit logs makes a lot of sense to me.
> > >
> > >> On 2023/10/16 06:34:05 "Pawar, Amit" wrote:
> > >> [Public]
> > >>
> > >> Hi,
> > >>
> > >> CommitLog uses mmap (memory mapped ) segments by default. Direct-IO
> feature is proposed through new PR[1] to improve the CommitLog IO speed.
> Enabling this by default could be useful feature to address IO bottleneck
> seen during peak load.
> > >>
> > >> Need your input regarding changing this default. Please suggest.
> > >>
> > >> https://issues.apache.org/jira/browse/CASSANDRA-18464
> > >>
> > >> thanks,
> > >> Amit Pawar
> > >>
> > >> [1] - https://github.com/apache/cassandra/pull/2777
> > >>
> >
>

Re: Project Status Update: 90-day catch-up edition [2023-10-27]

[Sam]

Please can I have an invite to the Slack workspace on this email. I'd like
to take a look through some of the items for first time contributors :-)

Thanks!

On Fri, 27 Oct 2023 at 18:10, Josh McKenzie  wrote:

> In case you're keeping score on how frequently these are coming out: *please
> stop*. ;)
>
> Silver lining - looks like we have a lot to discuss this round! Last
> update was late July and we've been churning through the 5.0 freeze and
> stabilization phase.
>
>
>
> *[New Contributors Getting Started]*
> Check out https://the-asf.slack.com, channel #cassandra-dev. Reply
> directly to me on this email if you need an invite for your account, and
> reach out to the @cassandra_mentors alias in the channel if you need to get
> oriented.
>
> We have a list of curated "getting started" tickets you can find here,
> filtered to "ToDo" (i.e. not yet worked):
> https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=484&quickFilter=2160&quickFilter=2162&quickFilter=2652
> .
>
> *Helpful links:*
> - Getting Started with Development on C*:
> https://cassandra.apache.org/_/development/gettingstarted.html
> - Building and IDE integration (worktrees are your friend; msg me on slack
> if you need pointers): https://cassandra.apache.org/_/development/ide.html
> - Code Style: https://cassandra.apache.org/_/development/code_style.html
>
>
>
> *[Dev mailing list]*
>
> https://lists.apache.org/list?dev@cassandra.apache.org:dfr=2023-7-20%7Cdto=2023-10-27
> :
>
> My last email of shame was 35 threads. Drumroll for this one...
> 91. *Yeesh*. Let me stick to highlights.
>
> Ekaterina pushed through dropping JDK8 support and adding JDK17 support...
> back in July. If you didn't know about it by know, consider yourself doubly
> notified. :) .
> https://lists.apache.org/thread/9pwz3vtpf88fly27psc7yxvcv0lwbz8k I think
> I can speak on behalf of all of us when I say: *Thank You Ekaterina.*
>
> This came up recently on another thread about when to branch 5.1, but we
> discussed our freeze plans and exception rules for TCM and Accord here:
> https://lists.apache.org/thread/mzj3dq8b7mzf60k6mkby88b9n9ywmsgw. Mick
> was essentially looking for a similar waiver for Vector search since it was
> well abstracted, depended on SAI and external libs, and in general
> shouldn't be too big of a disruption to get into 5.0. General consensus at
> the time was "sure", and the work has since been completed. But here's the
> reminder and link for posterity (and in case you missed it).
>
> Jaydeep reached out about a potential short-term solution to detecting
> token-ownership mismatch while we don't yet have TCM; this seems more
> pressing now as we're looking at a 5.0 without yet having TCM in it. The
> dev ML thread is here:
> https://lists.apache.org/thread/4p0orhom42g36osnknqj3fqmqhvqml1g, and he
> created https://issues.apache.org/jira/browse/CASSANDRA-18758 dealing
> with the topic. There's a relatively modest (7 files, just over 300 lines)
> PR available here: https://github.com/apache/cassandra/pull/2595/files; I
> haven't looked into it, but it might be worth considering getting this into
> 5.0 since it looks like we're moving to cutting w/out TCM. Any thoughts?
>
> We had a pretty good discussion about automated repair scheduling,
> discussing whether it should live in the DB proper vs. in the sidecar, pros
> and cons, pressures, etc. Not sure if things moved beyond that; I know
> there's at least a few implementations out there that haven't yet made
> their way back to the ASF project proper. Thread:
> https://lists.apache.org/thread/glvmkwknf91rxc5l6w4d4m1kcvlr6mrv. My hope
> is we can avoid the gridlock we hit for a long time with the sidecar where
> there are multiple implementations with different tradeoffs and everyone's
> disincentivized from accepting a solution different from their own in-house
> one since it'd theoretically require re-tooling. Tough problem with no easy
> solutions, but would love to see this become a first class citizen in the
> ecosystem.
>
> Paulo brought up a discussion about moving to disk_access_mode =
> mmap_index_only on 5.0. Seemed to be a consensus there but I'm not sure we
> actually changed that in the 5.0 branch? Thread:
> https://lists.apache.org/thread/nhp6vftc4kc3dxskngxy5rpo1lp19drw. Just
> pulled on cassandra-5.0 and it looks like auto + hasLargeAddressSpace() ==
> .mmap rather than .mmap_index_only.
>
> David Capwell worked on adding some retries to repair messages when
> they're failing to make the process more robust:
> https://lists.apache.org/thread/wxv6k6slljqcw73xcmpxj4kn5lz95jd1.
> Reception was positive enough that he went so far as to back-port it and
> also work on some for IR. Looks like he could use a reviewer here:
> https://issues.apache.org/jira/browse/CASSANDRA-18962 - and this is patch
> available.
>
> Mike Adamson reached out about adding / taking a dependency on jvector:
> https://lists.apache.org/thread/zkqg7mk9hp35zn0cf1tvywc2m3l63jrn. The
> general gist of it wa

Re: [DISCUSS] CommitLog default disk access mode

[Sam]

*"Glad you brought up compaction here - I think there would be a
significant benefit to moving compaction to direct i/o."*

Support Direct I/O for SSTable writing

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

On Mon, 16 Oct 2023 at 17:38, Jon Haddad  wrote:

> Glad you brought up compaction here - I think there would be a significant
> benefit to moving compaction to direct i/o.
>
>
> On 2023/10/16 16:14:28 Benedict wrote:
> > I have some plans to (eventually) use the commit log as memtable payload
> storage (ie memtables would reference the commit log entries directly,
> storing only indexing info), and to back first level of sstables by
> reference to commit log entries. This will permit us to deliver not only
> much bigger memtables (cutting compaction throughput requirements by the
> ratio of size increase - so pretty dramatically), and faster flushing (so
> better behaviour ling write bursts), but also a fairly cheap and simple way
> to support MVCC - which will be helpful for transaction throughput.
> >
> > There is also a new commit log (“journal”) coming with Accord, that the
> rest of C* may or may not transition to.
> >
> > I only say this because this makes the utility of direct IO for commit
> log suspect, as we will be reading from the files as a matter of course
> should this go ahead; and we may end up relying on a different commit log
> implementation before long anyway.
> >
> > This is obviously a big suggestion and is not guaranteed to transpire,
> and probably won’t within the next year or so, but it should perhaps form
> some minimal part of any calculus. If the patch is otherwise simple and
> beneficial I don’t have anything against it, and the use of direct IO could
> well be of benefit eg in compaction - and also in future if we manage to
> bring a page management in process. So laying foundations there could be of
> benefit, even if the commit log eventually does not use it.
> >
> > > On 16 Oct 2023, at 17:00, Jon Haddad 
> wrote:
> > >
> > > I haven't looked at the patch, but at a high level, defaulting to
> direct I/O for commit logs makes a lot of sense to me.
> > >
> > >> On 2023/10/16 06:34:05 "Pawar, Amit" wrote:
> > >> [Public]
> > >>
> > >> Hi,
> > >>
> > >> CommitLog uses mmap (memory mapped ) segments by default. Direct-IO
> feature is proposed through new PR[1] to improve the CommitLog IO speed.
> Enabling this by default could be useful feature to address IO bottleneck
> seen during peak load.
> > >>
> > >> Need your input regarding changing this default. Please suggest.
> > >>
> > >> https://issues.apache.org/jira/browse/CASSANDRA-18464
> > >>
> > >> thanks,
> > >> Amit Pawar
> > >>
> > >> [1] - https://github.com/apache/cassandra/pull/2777
> > >>
> >
>

Re: [DISCUSS] Merging incremental feature work

[Sam Tunnicliffe]

This is quite timely as we're just gearing up to begin pushing the work we've 
been doing on CEP-21 into the public domain. 

This CEP is a slightly different from others that have gone before in that it 
touches almost every area of the system. This presents a few implementation 
challenges, most obviously around feature flagging and incremental merging. 
When we began prototyping and working on the design presented in CEP-21 it 
quickly became apparent that doing things incrementally would push an already 
large changeset into gargantuan proportions. Keeping changes isolated and 
abstracted would itself have required a vast amount of refactoring and rework 
of existing code and tests. 

I'll go into more detail in a CEP-21 specific mail shortly, but the plan we 
were hoping to follow was to work in a long lived topic branch, with JIRAs, 
sensible commit history and CI, and defer merging to trunk until the work as a 
whole is useable and meets all the existing bars for quality, review and the 
like. 


> On 3 Feb 2023, at 12:43, Josh McKenzie  wrote:
> 
> Anything we either a) have to do (JDK support) or b) have all agreed up front 
> we think we should do (CEP). I.e. things with a lower risk of being left dead 
> in the codebase partially implemented.
> 
> I don't think it's a coincidence we've set up other processes to help de-risk 
> and streamline the consensus building portion of this work given our history 
> with it. We haven't taken steps to optimize the tactical execution of it yet.
> 
> On Fri, Feb 3, 2023, at 7:09 AM, Brandon Williams wrote:
>> On Fri, Feb 3, 2023 at 6:06 AM Josh McKenzie > > wrote:
>> >
>> > My current thinking: I'd like to propose we all agree to move to merge 
>> > work into trunk incrementally if it's either:
>> > 1) New JDK support
>> > 2) An approved CEP
>> 
>> So basically everything?  I'm not sure what large complex bodies of
>> work would be left.

[VOTE] CEP-21 Transactional Cluster Metadata

[Sam Tunnicliffe]

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] CEP-21 Transactional Cluster Metadata

[Sam Tunnicliffe]

The vote passes with 23 +1s (13 binding) and no negative votes.

Thanks all,
Sam


> On 6 Feb 2023, at 16:15, 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

[DISCUSS] CEP-21 Ongoing Development

[Sam Tunnicliffe]

Hi,

In the recent DISCUSS thread on merging incremental feature work[1] I mentioned 
that we've been preparing a code contribution to support CEP-21[2]. Today we 
have a branch based off trunk which supports a significant subset of the 
functionality described in the CEP. Whilst being mindful of the recent 
discussions on merging large features incrementally, we have been working on 
the assumption that this would land in trunk in a complete and usable form. 

To that end, we're proposing work is carried out in a long-lived feature branch 
and only merged to trunk when all the usual bars for quality are met, including 
a regular CI pipeline on that feature branch. The idea is to push the partially 
implemented version to a public repo now as it is, giving the community a way 
to get a better idea of the approach, to provide initial feedback and even to 
begin checking out the integration points. In parallel, we will create the 
feature branch and begin moving portions of the implementation across to it so 
that it can be more easily reviewed. This way of re-organising the git history 
into semantically meaningful commits feels way more achievable than a giant 
rebase.

Are there any concerns about this approach?

[1] https://lists.apache.org/thread/c39yrbdszgz9s34vr17wpjdhv6h2oo61
[2] 
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata

Re: [EXTERNAL] [DISCUSS] Next release date

[Sam Tunnicliffe]

Currently, we anticipate CEP-21 being in a mergeable state around late 
July/August. We're intending to push a feature branch with an implementation 
covering much of the core functionality to the ASF repo this week. Doing so 
will obviously help us get a better idea of the remaining work as we 
incorporate feedback from the community and to document that outstanding effort 
more clearly. 


> On 6 Mar 2023, at 09:24, Benjamin Lerer  wrote:
> 
> Sorry, I realized that when I started the discussion I probably did not frame 
> it enough as I see that it is now going into different directions.
> The concerns I am seeing are:
> 1) A too small amount of time between releases  is inefficient from a 
> development perspective and from a user perspective. From a development point 
> of view because we are missing time to deliver some features. From a user 
> perspective because they cannot follow with the upgrade.
> 2) Some features are so anticipated (Accord being the one mentioned) that 
> people would prefer to delay the release to make sure that it is available as 
> soon as possible.
> 3) We do not know how long we need to go from the freeze to GA. We hope for 2 
> months but our last experience was 6 months. So delaying the release could 
> mean not releasing this year.
> 4) For people doing marketing it is really hard to promote a product when you 
> do not know when the release will come and what features might be there.
> 
> All those concerns are probably even made worse by the fact that we do not 
> have a clear visibility on where we are.
> 
> Should we clarify that part first by getting an idea of the status of the 
> different CEPs and other big pieces of work? From there we could agree on 
> some timeline for the freeze. We could then discuss how to make predictable 
> the time from freeze to GA.  
> 
> 
> 
> Le sam. 4 mars 2023 à 18:14, Josh McKenzie  <mailto:jmcken...@apache.org>> a écrit :
>> (for convenience sake, I'm referring to both Major and Minor semver releases 
>> as "major" in this email)
>> 
>>> The big feature from our perspective for 5.0 is ACCORD (CEP-15) and I would 
>>> advocate to delay until this has sufficient quality to be in production. 
>> This approach can be pretty unpredictable in this domain; often unforeseen 
>> things come up in implementation that can give you a long tail on something 
>> being production ready. For the record - I don't intend to single Accord out 
>> at all on this front, quite the opposite given how much rigor's gone into 
>> the design and implementation. I'm just thinking from my personal 
>> experience: everything I've worked on, overseen, or followed closely on this 
>> codebase always has a few tricks up its sleeve along the way to having 
>> edge-cases stabilized.
>> 
>> Much like on some other recent topics, I think there's a nuanced middle 
>> ground where we take things on a case-by-case basis. Some factors that have 
>> come up in this thread that resonated with me:
>> 
>> For a given potential release date 'X':
>> 1. How long has it been since the last release?
>> 2. How long do we expect qualification to take from a "freeze" (i.e. no new 
>> improvement or features, branch) point?
>> 3. What body of merged production ready work is available?
>> 4. What body of new work do we have high confidence will be ready within Y 
>> time?
>> 
>> I think it's worth defining a loose "minimum bound and upper bound" on 
>> release cycles we want to try and stick with barring extenuating 
>> circumstances. For instance: try not to release sooner than maybe 10 months 
>> out from a prior major, and try not to release later than 18 months out from 
>> a prior major. Make exceptions if truly exceptional things land, are about 
>> to land, or bugs are discovered around those boundaries.
>> 
>> Applying the above framework to what we have in flight, our last release 
>> date, expectations on CI, etc - targeting an early fall freeze (pending CEP 
>> status) and mid to late fall or December release "feels right" to me.
>> 
>> With the exception, of course, that if something merges earlier, is stable, 
>> and we feel is valuable enough to cut a major based on that, we do it.
>> 
>> ~Josh
>> 
>> On Fri, Mar 3, 2023, at 7:37 PM, German Eichberger via dev wrote:
>>> Hi,
>>> 
>>> We shouldn't release just for releases sake. Are there enough new features 
>>> and are they working well enough (quality!).
>>> 
>>> The big feature from our perspective for 5.0 

Re: [DISCUSS] CEP-21 Ongoing Development

[Sam Tunnicliffe]

Hi, 

further to my previous mail I've just pushed a new branch, cep-21-tcm, to the 
ASF repo. This represents the majority of the work to date on CEP-21 and is 
based on recent trunk (7ad746cc83). As you can see from Circle[1], there are a 
number of test failures at the moment, many of which are down to differences in 
test setup and we're working on getting this to parity with trunk. We were able 
to get the git history reorganisation done while doing a rebase, so there isn't 
any point in publishing the original dev branch as I originally proposed.

I've also created a Jira epic (CASSANDRA-18330) as an umberella for CEP-21 and 
over the coming days we'll start to file seperate tickets for the 
upcoming/remaining work. 

[1] 
https://app.circleci.com/pipelines/github/beobal/cassandra/406/workflows/00cdb02e-4b3e-477a-b997-403121172249


> On 13 Feb 2023, at 17:18, Sam Tunnicliffe  wrote:
> 
> Hi,
> 
> In the recent DISCUSS thread on merging incremental feature work[1] I 
> mentioned that we've been preparing a code contribution to support CEP-21[2]. 
> Today we have a branch based off trunk which supports a significant subset of 
> the functionality described in the CEP. Whilst being mindful of the recent 
> discussions on merging large features incrementally, we have been working on 
> the assumption that this would land in trunk in a complete and usable form. 
> 
> To that end, we're proposing work is carried out in a long-lived feature 
> branch and only merged to trunk when all the usual bars for quality are met, 
> including a regular CI pipeline on that feature branch. The idea is to push 
> the partially implemented version to a public repo now as it is, giving the 
> community a way to get a better idea of the approach, to provide initial 
> feedback and even to begin checking out the integration points. In parallel, 
> we will create the feature branch and begin moving portions of the 
> implementation across to it so that it can be more easily reviewed. This way 
> of re-organising the git history into semantically meaningful commits feels 
> way more achievable than a giant rebase.
> 
> Are there any concerns about this approach?
> 
> [1] https://lists.apache.org/thread/c39yrbdszgz9s34vr17wpjdhv6h2oo61
> [2] 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-21%3A+Transactional+Cluster+Metadata

Re: Welcome our next PMC Chair Josh McKenzie

[Sam Tunnicliffe]

Congrats Josh and big thanks to Mick for everything this past year

> On 23 Mar 2023, at 08:22, Mick Semb Wever  wrote:
> 
> It is time to pass the baton on, and on behalf of the Apache Cassandra 
> Project Management Committee (PMC) I would like to welcome and congratulate 
> our next PMC Chair Josh McKenzie (jmckenzie).
> 
> Most of you already know Josh, especially through his regular and valuable 
> project oversight and status emails, always presenting a balance and 
> understanding to the various views and concerns incoming. 
> 
> Repeating Paulo's words from last year: The chair is an administrative 
> position that interfaces with the Apache Software Foundation Board, by 
> submitting regular reports about project status and health. Read more about 
> the PMC chair role on Apache projects:
> - https://www.apache.org/foundation/how-it-works.html#pmc
> - https://www.apache.org/foundation/how-it-works.html#pmc-chair
> - https://www.apache.org/foundation/faq.html#why-are-PMC-chairs-officers
> 
> The PMC as a whole is the entity that oversees and leads the project and any 
> PMC member can be approached as a representative of the committee. A list of 
> Apache Cassandra PMC members can be found on: 
> https://cassandra.apache.org/_/community.html

Re: [VOTE] CEP-28: Reading and Writing Cassandra Data with Spark Bulk Analytics

[Sam Tunnicliffe]

+1

> On 4 May 2023, at 17:46, Doug Rohrer  wrote:
> 
> Hello all,
> 
> I’d like to put CEP-28 to a vote.
> 
> Proposal:
> 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-28%3A+Reading+and+Writing+Cassandra+Data+with+Spark+Bulk+Analytics
> 
> Jira:
> https://issues.apache.org/jira/browse/CASSANDRA-16222
> 
> Draft implementation:
> 
> - Apache Cassandra Spark Analytics source code: 
> https://github.com/frankgh/cassandra-analytics
> - Changes required for Sidecar: 
> https://github.com/frankgh/cassandra-sidecar/tree/CEP-28-bulk-apis
> 
> Discussion:
> https://lists.apache.org/thread/lrww4d7cdxgtg8o3gt8b8foymzpvq7z3
> 
> The vote will be open for 72 hours. 
> A vote passes if there are at least three binding +1s and no binding vetoes. 
> 
> 
> Thanks,
> 
> Doug Rohrer
> 
> 

Re: [VOTE] Release Apache Cassandra 4.0.10

[Sam Tunnicliffe]

+1

> On 25 May 2023, at 16:12, 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] Release Apache Cassandra 4.1.2

[Sam Tunnicliffe]

+1

> On 25 May 2023, at 16:12, 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] CEP-8 Datastax Drivers Donation

[Sam Tunnicliffe]

+1

> On 13 Jun 2023, at 15:14, Jeremy Hanna  wrote:
> 
> Calling for a vote on CEP-8 [1].
> 
> To clarify the intent, as Benjamin said in the discussion thread [2], the 
> goal of this vote is simply to ensure that the community is in favor of the 
> donation. Nothing more.
> The plan is to introduce the drivers, one by one. Each driver donation will 
> need to be accepted first by the PMC members, as it is the case for any 
> donation. Therefore the PMC should have full control on the pace at which new 
> drivers are accepted.
> 
> If this vote passes, we can start this process for the Java driver under the 
> direction of the PMC.
> 
> Jeremy
> 
> 1. 
> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+Datastax+Drivers+Donation
> 2. https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp

Re: [DISCUSSION] Drift backwards compatibility from native protocol version growth to feature flags

[Sam Tunnicliffe]

There are some completely valid points here, but you are conflating internode 
messaging with native (aka client) protocol somewhat. Since native protocol V5 
in C* 4.0, there is a degree of code re-use between the two, native protocol 
having adopted the framing model and resource allocation from internode at this 
point. So the FrameDecoder/Encoder and AbstractMessageHandler concept are 
shared, but the two protocols are distinct and there is very little overlap in 
the message formats or versioning schemes. The handshake protocol that you 
referenced is only part of the internode protocol, client/server negotiation is 
handled differently and the Initiate message is not part of that. 

I absolutely agree that we (ab)use the internode messaging version in several 
places, the issue of storage compatibility being a great example. In CEP-21 we 
do a lot of serialisation both on the wire and into persistent storage of 
metadata components and the operations which modify them. We try to avoid 
perpetuating this coupling by having a distinct versioning scheme for metadata 
so that we can evolve those serialisations independently of message format. 
Whilst this isn't a perfect solution, it has worked fairly well so far. Perhaps 
it's worth doing something similar in other cases, where a component/domain 
specific versioning scheme could be appropriate (e.g. commitlog/sstable/etc). 

Another issue with evolving native protocol is the beta qualifier, which in my 
experience doesn't really work in its current form. V5 for instance, is 
"supported" with the beta flag since C* 3.10, but the framing implementation 
was never backported to 3.x for obvious reasons. So a client which implements 
"final" V5 can't use V5-beta in pre-4.0 versions. Your proposal to negotiate 
features seperately from the protocol version sounds more sustainable, but a 
concern might be that soon enough a new feature will also require protocol 
changes, so clients are then required to do both. e.g. a new data or message 
type is required to make a particular feature viable. 


> On 29 Sep 2023, at 20:22, Maxim Muzafarov  wrote:
> 
> Hello everyone,
> 
> 
> The problem that I'm struggling with is not directly related to the
> topic I'm about to discuss now, but it probably illustrates the
> greater complexity of backwards compatibility with the drivers we now
> support. For instance, I want to replace the algorithm that is used to
> calculate a CRC on the message payload with a new one, and since the
> v5 of the native protocol has already been fixed there is no way to do
> this without bumping the protocol version up to v6, which, in turn,
> seems like too big a leap for such a small change. Right? Correct me
> if I'm wrong.
> 
> From a broader perspective, we use native protocol versioning to
> provide backwards compatibility not only for the protocol changes
> themselves, but also for the internal features that do not appear to
> be not directly dependent on the protocol specification as well. I
> would say a good example of this is the dependency of the
> MessagingService version on the storage compatibility mode [2], which
> makes these two subcomponents tightly coupled.
> 
> Another thing worth mentioning here is the number of Cassandra drivers
> [1] that we have, which have to implement a monotonically growing
> version of the native protocol in order to support new features. The
> main problem with a monotonically growing version is that a driver
> (and a driver's developer) can skip v6 if they are only interested in
> a new feature that only appears in v7, without having fully
> implemented v6. This is probably not a problem for the java, or python
> drivers which always get a lot of attention, but could be a problem
> for others. The next example here is an urgent fix, that might be
> blocked by a heavyweight feature which is difficult to implement in a
> particular driver.
> 
> 
> = Proposal =
> 
> I think we could take a step aside and take a slightly different
> approach here to addressing the same backward compatibility issues,
> rather than bumping up the native protocol version every time. A
> driver could send a bitmask to a server on a connection handshake with
> "features" that it is interested in, and the server could then respond
> to that driver with the features it supports from that list. I have
> checked the handshake protocol and it seems that we have some bits in
> reserve [3] in the Initiate message to allow this.
> 
> I see the following advantages:
> 
> - drivers will have enough flexibility to implement new features they
> want, especially those drivers that have a lack of maintainers (not in
> the order the native protocol specification grows up);
> - it gives security plugins the flexibility to enable/disable features
> they want on both the client and server sides;
> - we decouple internal components and their internal versions from each other;
> - allows us to push out urgent fixes or tuning of internal com

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Sam Tunnicliffe]

+1 from me too. 

Regarding Benedict's point, backwards incompatibility should be minimal; we 
modified snitch behaviour slightly, so that local snitch config only relates to 
the local node, all peer info is fetched from cluster metadata. There is also a 
minor change to the way failed bootstraps are handled, as with TCM they require 
an explicit cancellation step (running a nodetool command). 

Whether consensus decrees that this constitutes a major bump or not, I think 
decoupling these major projects from 5.0 is the right move. 
 

> On 23 Oct 2023, at 12:57, Benedict  wrote:
> 
> I’m cool with this.
> 
> We may have to think about numbering as I think TCM will break some backwards 
> compatibility and we might technically expect the follow-up release to be 6.0
> 
> Maybe it’s not so bad to have such rapid releases either way.
> 
>> On 23 Oct 2023, at 12:52, Mick Semb Wever  wrote:
>> 
>> 
>> 
>> The TCM work (CEP-21) is in its review stage but being well past our cut-off 
>> date¹ for merging, and now jeopardising 5.0 GA efforts, I would like to 
>> propose the following.
>> 
>> We merge TCM and Accord only to trunk.  Then branch cassandra-5.1 and cut an 
>> immediate 5.1-alpha1 release.
>> 
>> I see this as a win-win scenario for us, considering our current situation.  
>> (Though it is unfortunate that Accord is included in this scenario because 
>> we agreed it to be based upon TCM.)
>> 
>> This will mean…
>>  - We get to focus on getting 5.0 to beta and GA, which already has a ton of 
>> features users want.
>>  - We get an alpha release with TCM and Accord into users hands quickly for 
>> broader testing and feedback.
>>  - We isolate GA efforts on TCM and Accord – giving oss and downstream 
>> engineers time and patience reviewing and testing.  TCM will be the biggest 
>> patch ever to land in C*.
>>  - Give users a choice for a more incremental upgrade approach, given just 
>> how many new features we're putting on them in one year.
>>  - 5.1 w/ TCM and Accord will maintain its upgrade compatibility with all 
>> 4.x versions, just as if it had landed in 5.0.
>> 
>> 
>> The risks/costs this introduces are
>>  - If we cannot stabilise TCM and/or Accord on the cassandra-5.1 branch, and 
>> at some point decide to undo this work, while we can throw away the 
>> cassandra-5.1 branch we would need to do a bit of work reverting the changes 
>> in trunk.  This is a _very_ edge case, as confidence levels on the design 
>> and implementation of both are already tested and high.
>>  - We will have to maintain an additional branch.  I propose that we treat 
>> the 5.1 branch in the same maintenance window as 5.0 (like we have with 3.0 
>> and 3.11).  This also adds the merge path overhead.
>>  - Reviewing of TCM and Accord will continue to happen post-merge.  This is 
>> not our normal practice, but this work will have already received its two 
>> +1s from committers, and such ongoing review effort is akin to GA 
>> stabilisation work on release branches.
>> 
>> 
>> I see no other ok solution in front of us that gets us at least both the 5.0 
>> beta and TCM+Accord alpha releases this year.  Keeping in mind users demand 
>> to start experimenting with these features, and our Cassandra Summit in 
>> December.
>> 
>> 
>> 1) https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3
>> 
>> 

Re: [DISCUSS] Harry in-tree

[Sam Tunnicliffe]

Definite +1 to bringing harry-core in tree.

> On 24 Nov 2023, at 15:43, 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

Re: CEP-21 - Transactional cluster metadata merged to trunk

[Sam Tunnicliffe]

I ought to clarify, we did actually have green CI modulo 3 flaky tests on our 
internal CI system. I've attached the test artefacts to CASSANDRA-18330 
now[1][2]: 2 of the 3 failures are upgrade dtests, with 1 other python dtest 
failure noted. None of these were reproducible in a dev setup, so we suspected 
them to be environmental and intended to merge before returning to confirm 
that. The "known" failures that we mentioned in the email that started this 
thread were ones observed by Mick running the cep-21-tcm branch through Circle 
before merging.  

As the CEP-21 changeset was approaching 88k LoC touching over 900 files, 
permanently rebasing as we tried to eradicate every flaky test was simply 
unrealistic, especially as other significant patches continued to land in 
trunk. With that in mind, we took the decision to merge so that we could focus 
on actually removing any remaining instability.

[1] https://issues.apache.org/jira/secure/attachment/13064727/ci_summary.html
[2] 
https://issues.apache.org/jira/secure/attachment/13064728/result_details.tar.gz


> On 27 Nov 2023, at 10:28, Berenguer Blasi  wrote:
> 
> Hi,
> 
> I have written this email like 10 times before sending it and I can't manage 
> to avoid making it sound with a negative spin to it. So pardon my English or 
> poor choice of words in advance and try to read it in a positive way.
> 
> It is really demotivating to me seeing things getting merged without green 
> CI. I had to go through an herculean effort and pain (at least to me) to keep 
> rebasing the TTL patch continuously (a huge one imo) when it would have been 
> altogether much easier to merge, post-fix and post-add downgradability along 
> the TCM merge lines.
> 
> If this merge-post fix approach is a thing I would like it clarified so we 
> can all benefit from it and to avoid the big-patch rebase pain.
> 
> Regards
> 
> On 27/11/23 10:38, Jacek Lewandowski wrote:
>> Hi,
>> 
>> I'm happy to hear that the feature got merged. Though, I share Benjamin's 
>> worries about that being a bad precedent.
>> 
>> I don't think it makes sense to do repeated runs in this particular case. 
>> Detecting flaky tests would not prove anything; they can be caused by this 
>> patch, but we would not know that for sure. We would have to have a similar 
>> build with the same tests repeated to compare. It would take time and 
>> resources, and in the end, we will have to fix those flaky tests regardless 
>> of whether they were caused by this change. IMO, it makes sense to do a 
>> repeated run of the new tests, though. Aside from that, we can also consider 
>> making it easier and more automated for the developer to determine whether a 
>> particular flakiness comes from a feature branch one wants to merge.
>> 
>> thanks,
>> Jacek
>> 
>> 
>> pon., 27 lis 2023 o 10:15 Benjamin Lerer > <mailto:ble...@apache.org>> napisał(a):
>>> Hi,
>>> 
>>> I must admit that I have been surprised by this merge and this following 
>>> email. We had lengthy discussions recently and the final agreement was that 
>>> the requirement for a merge was a green CI.
>>> I could understand that for some reasons as a community we could wish to 
>>> make some exceptions. In this present case there was no official discussion 
>>> to ask for an exception.
>>> I believe that this merge creates a bad precedent where anybody can feel 
>>> entitled to merge without a green CI and disregard any previous community 
>>> agreement.
>>> 
>>> Le sam. 25 nov. 2023 à 09:22, Mick Semb Wever >> <mailto:m...@apache.org>> a écrit :
>>>> 
>>>> Great work Sam, Alex & Marcus !
>>>> 
>>>>  
>>>>> 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.
>>>> 
>>>> 
>>>> Can we get these tests temporarily annotated as skipped while all the 
>>>> subtickets to 19055 are being worked on ? 
>>>> 
>>>> As we have seen from CASSANDRA-18166 and CASSANDRA-19034 there's a lot of 
>>>> overhead now on 5.0 tickets having to navigate around these failures in 
>>>> trunk CI runs.
>>>> 
>>>> Also, we're still trying to figure out how to do repeated runs for a patch 
>>>> so big… (the list of touched tests was too long for circleci, i need to 
>>>> figure out what the limit is and chunk it into separate circleci configs) 
>>>> … and it probably makes sense to wait until most of 19055 is done (or 
>>>> tests are temporarily annotated as skipped).
>>>> 
>>>> 

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Sam Tunnicliffe]

Congrats Francisco!

> On 28 Nov 2023, at 18:52, Dinesh Joshi  wrote:
> 
> The PMC members are pleased to announce that Francisco Guerrero Hernandez has 
> accepted
> the invitation to become committer today.
> 
> Congratulations and welcome!
> 
> The Apache Cassandra PMC members

Re: [VOTE] Release Harry 0.0.2

[Sam Tunnicliffe]

+1

> On 29 Nov 2023, at 11:14, 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] CASSANDRA-16999 introduction of a column in system.peers_v2

[Sam Tunnicliffe]

Late to the party I'm afraid, but I'd agree with Abe's proposal to deprecate 
the dual port approach given that CASSANDRA-10559 makes it pretty much 
redundant. Adding further yaml options like "default ssl/no ssl" feels like 
another nasty band-aid that we'll have to live with for the foreseeable future.

Also, if CASSANDRA-16999 is only going to trunk, why can't we just deprecate 
dual ports in 5.0 (as it isn't at -rc stage yet) and remove it from trunk? That 
seems preferable to shoehorning something into the new system_views.peers 
table, which isn't going to help any existing drivers anyway as none of them 
will be using it.

 
> On 12 Feb 2024, at 07:58, Štefan Miklošovič  
> wrote:
> 
> I think that the situation like
> 
> client_encryption_options.enabled = true
> client_encryption_options.optional=true
> native_transport_port != native_transport_port_ssl
> 
> is a legit bug and should be fixed. If we look here (1), when these ports are 
> not equal, the normal port is explicitly set to be unencrypted but it is 
> encrypted on _ssl port. This is not always true for _ssl port, because in (2) 
> we throw only if client_encryption_options' encryption_policy is UNENCRYPTED. 
> We do not throw if it is OPTIONAL. If we say that the normal port is always 
> unencrypted, why don't we also say that _ssl port is always encrypted? This 
> asymmetry should be fixed.
> 
> However, I think it is too late to fix anything but trunk. Adding a column 
> might break clients and fixing the logic around ports might potentially break 
> the deployments so our best shot seems to be:
> 
> 1) from 4.0 to trunk - apply a patch which would inform a user that it is 
> preferable to use single port instead of dual ports
> 2) for trunk - apply a patch which adds native_port_ssl column to 
> system_views.peers so Cassandra Java Driver can connect to such a deployment
> 3) optionally fix the bug I was describing above.
> 
> I am not sure how to evaluate the severity of 3). I would like to see it from 
> 4.0 to trunk but I also understand that if it is too disruptive, we can leave 
> it just to trunk.
> 
> The problems you described are the result of us using one 
> client_encryption_options for both ssl and non-ssl ports. I would say that 
> the first problem you described, even if it looks weird, is less serious, 
> because a user knowingly uses two ports and one of them is said to be 
> unencrypted and another one encrypted. So the fact that a non-ssl port still 
> enables unencrypted traffic is somehow expected. What is not expected is that 
> _ssl port might still accept unencrypted traffic.
> 
> To sum it up for the driver, I do not think this has a nice solution for dual 
> ports deployments already out there so it would work just for the trunk. 
> Actually, because there is missing native_port_ssl in a system table, there 
> is currently no way to successfully use dual ports because Java driver just 
> can not connect to SSL-enabled nodes reliably using ssl and non-ssl ports.
> 
> (1) 
> https://github.com/apache/cassandra/blob/097c1231e2466163fe3f8b36b12cdc5235eb1403/src/java/org/apache/cassandra/service/NativeTransportService.java#L94
> 
> (2) 
> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/config/DatabaseDescriptor.java#L905-L915
> 
> On Thu, Feb 8, 2024 at 9:58 PM Abe Ratnofsky  > wrote:
>> > Deprecating helps nothing for existing releases. We can’t/shouldn’t remove 
>> > the feature in existing releases.
>> 
>> The deprecation I'm proposing is intended to push people to configure their 
>> servers in a way that is more secure and maximizes compatibility with 
>> clients. Deprecating can help for existing releases - the better 
>> configuration already exists, and it's likely that users of dual-native-port 
>> optional SSL can use it. At the very least, users should be made aware of 
>> the risks of dual-native-port operation.
>> 
>> Currently, if a user specifies the following server configuration:
>> - client_encryption_options.enabled=true
>> - client_encryption_options.optional=false
>> - native_transport_port != native_transport_port_ssl
>> 
>> then the server will still handle unencrypted traffic on 
>> native_transport_port. This feels like a security risk: it would be 
>> reasonable to interpret that this configuration requires all traffic to be 
>> encrypted.
>> 
>> And if a user specifies this server configuration:
>> - client_encryption_options.enabled=true
>> - client_encryption_options.optional=true
>> - native_transport_port != native_transport_port_ssl
>> 
>> then clients can still send unencrypted traffic to 
>> native_transport_port_ssl, since the server handles optional encryption on 
>> this port. In this case, there are two ports that accept unencrypted 
>> traffic, one of which also accepts encrypted traffic.
>> 
>> In both cases:
>> - Clients configured to use SSL will discover non-SSL ports from 
>> system.peers_v2 and fail to connect to those 

Re: [DISCUSS] New CQL command/option for listing roles with superuser privileges

[Sam Tunnicliffe]

>Regarding removal of inheriting superuser role needs broader discussion. There 
>must be a reason why it was done and removing this feature may impact existing 
>use cases.

The reason behind the current behaviour is almost irrelevant, the fact is that 
this is the way that it works and has done since its inception. I implemented 
RBAC in the first place (CASSANDRA-7653) and I don't remember why we chose to 
have superuser privilege inherited in this way, though with hindsight I do 
agree with Bowen that perhaps it would have been better were it not 
inheritable. Not to say that decisions can never be revisited, but we all know 
that the cost of changing established behaviour in a database is extremely high 
even during a major release and so is not something to be undertaken lightly. 

The discussion here is also rather pre-occupied with the default implementation 
and any changes to behaviour or semantics would need to consider external/third 
party implementations. Any solution which involves simply querying the 
system.roles table in some new way, or updating it somehow differently only 
works for the default IRoleManager that ships with C*. (On a practical level, 
dynamically setting the is_super column based on role assignment doesn't work 
as proposed because it can't differentiate between inherited and granted 
status). 

What Shailaja is proposing is essentially just some CQL sugar to expose what 
Roles::hasSuperUserStatus does internally. That doesn't seem entirely 
unreasonable as it will work with any backing implementation and saves 
duplicating that logic in any system that consumes this, particularly the 
sidecar.


> On 1 Mar 2024, at 12:04, shailajako...@icloud.com wrote:
> 
> - Forgot to mention, is_superuser of roles table cannot be altered as it is 
> just showing what is persisted in the table. We can think about changing 
> super column of LIST ROLES command instead.
> 
> - Regarding change of the underlying state while we retrieve superusers info, 
> I believe we do not need a transaction for that, because it can happen to any 
> column of almost any CQL query. For example, state of 
> login/options/datacenters etc can also change while we are processing a 
> query. From my understanding it’s acceptable that user runs the same query 
> twice and sees difference in the output because of ongoing state changes. 
> Caller if caching results of a CQL query, may rerun the query periodically to 
> refresh their cache.
> 
> 
> 
>> On Mar 1, 2024, at 11:39 AM, shailajako...@icloud.com wrote:
>> 
>> Don’t know why is_superuser was not set to true for acquired superusers. Now 
>> if we change it, may break existing tools/scripts/understanding of 
>> customers, so do we want to update current understanding of is_superuser 
>> column or introduce a new column or option instead?
>> 
>> 
>>> On Feb 29, 2024, at 11:30 AM, Štefan Miklošovič 
>>>  wrote:
>>> 
>>> Why don't we just update the is_superuser column of a role when it 
>>> effectively achieves a superuser status when it is granted some superuser 
>>> role? Similarly, we would remove its superuser status when there are no 
>>> superuser roles granted to it anymore.
>>> 
>>> I think that at least for the second case (when a superuser role is revoked 
>>> and there is none anymore), there would need to be some transaction because 
>>> as it checks if there are any superuser roles or not to set it to false, 
>>> somebody else might grant that superuser role to it again so we might end 
>>> up with having is_superuser set to false while it might still have a 
>>> superuser role granted.
>>> 
>>> I am not sure if this is achievable and I am sorry if this was already 
>>> answered / rejected elsewhere.
>>> 
>>> On Thu, Feb 29, 2024 at 11:33 AM >> > wrote:
 Hi Maxwell,
 
 Currently system_auth.roles table doesn’t have acquired superuser info 
 available in columns to filter on it. Below is the system_auth.roles table 
 for the example I have listed in the previous email. If you notice, though 
 role1 and role11 acquired superuser status through grants, is_superuser 
 column is False for these roles and acquired superuser status is not 
 apparent directly from the columns of this table. member_of column shows 
 immediate parent/grant of a given role. But these grants can result in a 
 huge tree of roles hierarchy and there may be a role anywhere up in the 
 hierarchy which is a superuser.
 
 cassandra@cqlsh> select * from system_auth.roles;
 
  role  | can_login | is_superuser | member_of  | salted_hash
 ---+---+--++--
  role2 | False |False |   null |   
   null
 role11 | False |False |  {'role1'} |   
  

Re: [DISCUSS] CEP-42: Constraints Framework

[Sam Tunnicliffe]

We've been working on a draft CEP for migrating config from yaml to cluster 
metadata but have been a bit short of time recently, I'll try to get something 
out for discussion as soon as possible. 
A little delay isn't such a bad thing IMO, as we're still ironing out the kinks 
in the TCM implementation itself. It'd be good to get a bit more road testing 
done with that before we start adding more to it, which I'm sure will start to 
ramp up once 5.0 is out.  

Thanks,
Sam

> On 7 Jun 2024, at 19:19, Štefan Miklošovič  
> wrote:
> 
> Yes, all configuration should be transactional (configuration which makes 
> sense to require to be the same cluster-wide). Guardrails in TCM are just a 
> subset of this problem. When I started to do CEP-24 I started with guardrails 
> in TCM but then I realized it leads to more general "all config in TCM" and I 
> found myself rabbit-hole-ing endlessly.
> 
> BTW I do not think that once CEP-24 is in place without guardrails in TCM 
> then implementing it would blow up things a lot. It is really just about a 
> couple mutable virtual tables and a couple transformations for various 
> guardrail types we have but I expect that its integration into more general 
> config in TCM should be rather straightforward.
> 
> Config in TCM definitely deserves its own CEP, it is too much to handle under 
> CEP-24 and CEP-24 can go without it already. It just put a little bit more 
> configuration acumen to nail it down correctly. 
> 
> Regards
> 
> On Fri, Jun 7, 2024 at 8:12 PM Doug Rohrer  <mailto:droh...@apple.com>> wrote:
>> There’s a difference between the two though. Constraints are part of the 
>> table schema, and (independent of the interaction with Guardrails), have no 
>> dependency on yaml files being perfectly in sync across the cluster. 
>> Therefore, the feature (Constraints) on its own doesn’t depend on 
>> configuration files to be correct in its own right. The only place where 
>> this isn’t true is it’s interaction with Guardrails, which happen to be 
>> yaml-file based and cause issues. 
>> 
>> CEP-24’s password length requirements, however, is intended to be 
>> implemented by adding a new guardrail, which is totally dependent on YAML 
>> files today (and thus the concerns around a single misconfigured server 
>> allowing someone to use an insecure password). If CEP-24 fixes guardrails’ 
>> dependence on yaml files, it would also fix the problematic interaction 
>> between guardrails and constraints.
>> 
>> I agree that it would be incredibly valuable to find a solution to the “yaml 
>> files need to be correct everywhere or something breaks” problem, and I 
>> think CEP-24, being security-focused, is more likely to be problematic 
>> without a solution to this issue. That said, I think Dinesh is right in 
>> that, at the end of the day, CEP-24 could be implemented without fixing the 
>> yaml config issue.
>> 
>> I do wonder if the “Guardrails should be transactional” should really be 
>> “configuration should be transactional”, or at least as much config as 
>> possible should be, but that would blow up CEP-24 fairly dramatically 
>> (maybe?). Maybe “cluster-wide configuration should be read from a 
>> distributed source on startup/joining the cluster” or something would make 
>> sense, so the yaml file works as the source of truth on startup, but as soon 
>> as possible it’s read from a TCM-backed data source, and anything the node 
>> can get from other nodes it would… but now I’m designing a different CEP in 
>> a discuss thread, which is probably a bad idea...
>> 
>> Regardless, I hope that I’m explaining why I see a difference between 
>> constraints and guardrails, and why I think it makes sense that constraints 
>> can move forward without a solution the misconfiguration problem where I 
>> also think you were right in calling it out in CEP-24 (even if we eventually 
>> move forward on CEP-24 without the solution in place).
>> 
>> Doug
>> 
>> 
>> 
>>> On Jun 7, 2024, at 1:51 AM, Dinesh Joshi >> <mailto:djo...@apache.org>> wrote:
>>> 
>>> On Thu, Jun 6, 2024 at 1:03 PM Štefan Miklošovič 
>>> mailto:stefan.mikloso...@gmail.com>> wrote:
>>>> It is interesting to see this feedback. When I look at CEP-24 where I am 
>>>> obsessing about a user being able to misconfigure the password validation 
>>>> strength so if a user hits a "weak" node then she would be able to bypass 
>>>> it, and I see what is our approach here, then I am not sure what I was 
>>>> waiting so long for and

Re: Suggestions for CASSANDRA-18078

[Sam Tunnicliffe]

100% Option 1. Once it's out in GA release we're stuck with it so any short 
term disruption to adopters of pre-release versions is a trivial price to pay. 

> On 20 Jun 2024, at 17:46, Štefan Miklošovič  wrote:
> 
> List,
> 
> we need your opinions about CASSANDRA-18078.
> 
> That ticket is about the removal of MAXWRITETIME function which was added in 
> CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
> 
> This function was identified to be redundant in favor of CASSANDRA-8877 and 
> CASSANDRA-18060.
> 
> The idea of the removal was welcomed and the patch was prepared doing so but 
> it was never delivered and the question what to do with it, in connection 
> with 5.0.0, still remains.
> 
> The options are:
> 
> 1) since 18078 was never released in GA, there is still time to remove it.
> 2) it is too late for the removal hence we would keep it in 5.0.0 and we 
> would deprecate it in 5.0.1 and remove it in trunk.
> 
> It is worth to say that there is a precedent in 2), in CASSANDRA-17495, where 
> it was the very same scenario. A guardrail was introduced in alpha1. We 
> decided to release and deprecate in 5.0.1 and remove in trunk. The same might 
> be applied here, however we would like to have it confirmed if this is indeed 
> the case or we prefer to just go with 1) and be done with it.
> 
> Regards

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

[Sam Tunnicliffe]

-1 

I'm afraid we have found an issue with coordinator level latency metrics being 
artificially inflated for certain types of queries. 
Unfortunately this is a new regression, introduced by CASSANDRA-19534, so we 
shouldn't knowingly include it in the release.
The good news is that only a subset of queries are affected and we have a patch 
ready, so hopefully it won't delay things too much. 
Further details in CASSANDRA-19755

> On 2 Jul 2024, at 12:19, Mick Semb Wever  wrote:
> 
> 
> Proposing the test build of Cassandra 5.0-rc1 for release.
> 
> sha1: 01eea8a0d74deaede236edb25335fa470502106e
> Git: https://github.com/apache/cassandra/tree/5.0-rc1-tentative
> Maven Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1337/org/apache/cassandra/cassandra-all/5.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/5.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://github.com/apache/cassandra/blob/5.0-rc1-tentative/CHANGES.txt
> [2]: NEWS.txt: 
> https://github.com/apache/cassandra/blob/5.0-rc1-tentative/NEWS.txt

Re: Optimizing queries for partition keys

[Sam Klock]

Thanks.  For those interested: opened CASSANDRA-14415.

SK

On 2018-04-19 06:04, Benjamin Lerer wrote:
> Hi Sam,
> 
> Your finding is interesting. Effectively, if the number of bytes to skip is
> larger than the remaining bytes in the buffer + the buffer size it could be
> faster to use seek.
> Feel free to open a JIRA ticket and attach your patch. It will be great if
> you could add to the ticket your table schema as well
>  as some information on your environment (e.g. disk type).
> 
> On Tue, Apr 17, 2018 at 8:53 PM, Sam Klock  wrote:
> 
>> Thanks (and apologies for the delayed response); that was the kind of
>> feedback we were looking for.
>>
>> We backported the fix for CASSANDRA-10657 to 3.0.16, and it partially
>> addresses our problem in the sense that it does limit the data sent on
>> the wire.  The performance is still extremely poor, however, due to the
>> fact that Cassandra continues to read large volumes of data from disk.
>> (We've also confirmed this behavior in 3.11.2.)
>>
>> With a bit more investigation, we now believe the problem (after
>> CASSNDRA-10657 is applied) is in RebufferingInputStream.skipBytes(),
>> which appears to read bytes in order to skip them.  The subclass used in
>> our case, RandomAccessReader, exposes a seek(), so we overrode
>> skipBytes() in it to make use of seek(), and that seems to resolve the
>> problem.
>>
>> This change is intuitively much safer than the one we'd originally
>> identified, but we'd still like to confirm with you folks whether it's
>> likely safe and, if so whether it's also potentially worth contributing.
>>
>> Thanks,
>> Sk
>>
>>
>> On 2018-03-22 18:16, Benjamin Lerer wrote:
>>
>>> You should check the 3.x release. CASSANDRA-10657 could have fixed your
>>> problem.
>>>
>>>
>>> On Thu, Mar 22, 2018 at 9:15 PM, Benjamin Lerer <
>>> benjamin.le...@datastax.com
>>>
>>>> wrote:
>>>>
>>>
>>> Syvlain explained the problem in CASSANDRA-4536:
>>>> " Let me note that in CQL3 a row that have no live column don't exist, so
>>>> we can't really implement this with a range slice having an empty columns
>>>> list. Instead we should do a range slice with a full-row slice predicate
>>>> with a count of 1, to make sure we do have a live column before including
>>>> the partition key. "
>>>>
>>>> By using ColumnFilter.selectionBuilder(); you do not select all the
>>>> columns. By consequence, some partitions might be returned while they
>>>> should not.
>>>>
>>>> On Thu, Mar 22, 2018 at 6:24 PM, Sam Klock  wrote:
>>>>
>>>> Cassandra devs,
>>>>>
>>>>> We use workflows in some of our clusters (running 3.0.15) that involve
>>>>> "SELECT DISTINCT key FROM..."-style queries.  For some tables, we
>>>>> observed extremely poor performance under light load (i.e., a small
>>>>> number of rows per second and frequent timeouts), which we eventually
>>>>> traced to replicas shipping entire rows (which in some cases could store
>>>>> on the order of MBs of data) to service the query.  That surprised us
>>>>> (partly because 2.1 doesn't seem to behave this way), so we did some
>>>>> digging, and we eventually came up with a patch that modifies
>>>>> SelectStatement.java in the following way: if the selection in the query
>>>>> only includes the partition key, then when building a ColumnFilter for
>>>>> the query, use:
>>>>>
>>>>>  builder = ColumnFilter.selectionBuilder();
>>>>>
>>>>> instead of:
>>>>>
>>>>>  builder = ColumnFilter.allColumnsBuilder();
>>>>>
>>>>> to initialize the ColumnFilter.Builder in gatherQueriedColumns().  That
>>>>> seems to repair the performance regression, and it doesn't appear to
>>>>> break any functionality (based on the unit tests and some smoke tests we
>>>>> ran involving insertions and deletions).
>>>>>
>>>>> We'd like to contribute this patch back to the project, but we're not
>>>>> convinced that there aren't subtle correctness issues we're missing,
>>>>> judging both from comments in the code and the existence of
>>>>> CASSANDRA-5912, which suggests optimizing this kind of query is
>>>>> nontrivial.
>>>>>
>>>>> So: does this change sound safe to make, or are there corner cases we
>>>>> need to account for?  If there are corner cases, are there plausibly
>>>>> ways of addressing them at the SelectStatement level, or will we need to
>>>>> look deeper?
>>>>>
>>>>> Thanks,
>>>>> SK
>>>>>
>>>>> -
>>>>> 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: Optimizing queries for partition keys

[Sam Klock]

Can someone please take a look at CASSANDRA-14415 when you have chance?
Getting a fix into a Cassandra release is not especially urgent for us,
but in lieu of that we would like to know whether it's safe to include
in our local build of Cassandra before attempting to deploy it.

Thanks,
SK

On 2018-04-24 14:16, Sam Klock wrote:
> Thanks.  For those interested: opened CASSANDRA-14415.
> 
> SK
> 
> On 2018-04-19 06:04, Benjamin Lerer wrote:
>> Hi Sam,
>>
>> Your finding is interesting. Effectively, if the number of bytes to skip is
>> larger than the remaining bytes in the buffer + the buffer size it could be
>> faster to use seek.
>> Feel free to open a JIRA ticket and attach your patch. It will be great if
>> you could add to the ticket your table schema as well
>>  as some information on your environment (e.g. disk type).
>>
>> On Tue, Apr 17, 2018 at 8:53 PM, Sam Klock  wrote:
>>
>>> Thanks (and apologies for the delayed response); that was the kind of
>>> feedback we were looking for.
>>>
>>> We backported the fix for CASSANDRA-10657 to 3.0.16, and it partially
>>> addresses our problem in the sense that it does limit the data sent on
>>> the wire.  The performance is still extremely poor, however, due to the
>>> fact that Cassandra continues to read large volumes of data from disk.
>>> (We've also confirmed this behavior in 3.11.2.)
>>>
>>> With a bit more investigation, we now believe the problem (after
>>> CASSNDRA-10657 is applied) is in RebufferingInputStream.skipBytes(),
>>> which appears to read bytes in order to skip them.  The subclass used in
>>> our case, RandomAccessReader, exposes a seek(), so we overrode
>>> skipBytes() in it to make use of seek(), and that seems to resolve the
>>> problem.
>>>
>>> This change is intuitively much safer than the one we'd originally
>>> identified, but we'd still like to confirm with you folks whether it's
>>> likely safe and, if so whether it's also potentially worth contributing.
>>>
>>> Thanks,
>>> Sk
>>>
>>>
>>> On 2018-03-22 18:16, Benjamin Lerer wrote:
>>>
>>>> You should check the 3.x release. CASSANDRA-10657 could have fixed your
>>>> problem.
>>>>
>>>>
>>>> On Thu, Mar 22, 2018 at 9:15 PM, Benjamin Lerer <
>>>> benjamin.le...@datastax.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>> Syvlain explained the problem in CASSANDRA-4536:
>>>>> " Let me note that in CQL3 a row that have no live column don't exist, so
>>>>> we can't really implement this with a range slice having an empty columns
>>>>> list. Instead we should do a range slice with a full-row slice predicate
>>>>> with a count of 1, to make sure we do have a live column before including
>>>>> the partition key. "
>>>>>
>>>>> By using ColumnFilter.selectionBuilder(); you do not select all the
>>>>> columns. By consequence, some partitions might be returned while they
>>>>> should not.
>>>>>
>>>>> On Thu, Mar 22, 2018 at 6:24 PM, Sam Klock  wrote:
>>>>>
>>>>> Cassandra devs,
>>>>>>
>>>>>> We use workflows in some of our clusters (running 3.0.15) that involve
>>>>>> "SELECT DISTINCT key FROM..."-style queries.  For some tables, we
>>>>>> observed extremely poor performance under light load (i.e., a small
>>>>>> number of rows per second and frequent timeouts), which we eventually
>>>>>> traced to replicas shipping entire rows (which in some cases could store
>>>>>> on the order of MBs of data) to service the query.  That surprised us
>>>>>> (partly because 2.1 doesn't seem to behave this way), so we did some
>>>>>> digging, and we eventually came up with a patch that modifies
>>>>>> SelectStatement.java in the following way: if the selection in the query
>>>>>> only includes the partition key, then when building a ColumnFilter for
>>>>>> the query, use:
>>>>>>
>>>>>>  builder = ColumnFilter.selectionBuilder();
>>>>>>
>>>>>> instead of:
>>>>>>
>>>>>>  builder = ColumnFilter.allColumnsBuilder();
>>>>>>
>>>>>> to initialize the ColumnFilter

Re: [VOTE] Release Apache Cassandra 3.11.3

[Sam Tunnicliffe]

-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified.  The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.


On 3 July 2018 at 04:02, Nate McCall  wrote:

> +1
>
> On Tue, Jul 3, 2018 at 8:11 AM, Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.11.3.
> >
> > sha1: aed1b5fdf1e953d19bdd021ba603618772208cdd
> > 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-1161/org/apache/cassandra/apache-cassandra/3.11.3/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1161/
> >
> > 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=NEWS.txt;hb=refs/tags/3.11.3-tentative
> >
> > --
> > Michael
> >
> > -
> > 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.17

[Sam Tunnicliffe]

-1 I think CASSANDRA-14252 should be reverted from 3.0 & 3.11, at least the
effect on streaming is verified.  The concern is that the snitch change
could make cross DC streaming more likely. I’ve opened CASSANDRA-14555 for
this.


On 3 July 2018 at 04:02, Nate McCall  wrote:

> +1
>
> On Tue, Jul 3, 2018 at 8:10 AM, Michael Shuler 
> wrote:
> > I propose the following artifacts for release as 3.0.17.
> >
> > sha1: c4e6cd2a1aca84a88983192368bbcd4c8887c8b2
> > 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-1160/org/apache/cassandra/apache-cassandra/3.0.17/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1160/
> >
> > 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=NEWS.txt;hb=refs/tags/3.0.17-tentative
> >
> > --
> > Michael
> >
> > -
> > 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: Testing 4.0 Post-Freeze

[Sam Tunnicliffe]

+1 here too

On Tue, 10 Jul 2018 at 18:52, Marcus Eriksson  wrote:

> +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] Branching Change for 4.0 Freeze

[Sam Tunnicliffe]

+1

On 12 July 2018 at 08:49, Mick Semb Wever  wrote:

>
> > Vote will be open for 72 hours.
>
>
> +1 (non-binding)
>
> -
> 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.17 (Take 2)

[Sam Tunnicliffe]

+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 2.2.13

[Sam Tunnicliffe]

+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: [VOTE] Release Apache Cassandra 3.11.3 (Take 2)

[Sam Tunnicliffe]

+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: Side Car New Repo vs not

[Sam Tunnicliffe]

+1 for a separate repo

On Fri, 24 Aug 2018 at 06:40, Michael Shuler  wrote:

> +1 for a separate repository.
>
> Michael
>
> On 08/23/2018 07:30 PM, Murukesh Mohanan wrote:
> > FWIW, I think it's possible to merge in a separate repository into a
> > subdirectory while keeping git history, but I don't know if the other way
> > will be possible if commits span other parts of the repo as well\* (which
> > will likely happen sooner or later). So a separate repo is a choice we
> can
> > backtrack from if it proves problematic later.
> >
> >
> > \* it may be possible, but the commit messages might not make much sense
> > after that.
> >
> > On Fri, 24 Aug 2018, 09:12 Benedict Elliott Smith, 
> > wrote:
> >
> >> +1 also for separate repo
> >>
> >>> On 24 Aug 2018, at 01:11, Jeff Jirsa  wrote:
> >>>
> >>> +1 for separate repo
> >>>
> >>>
> >>> --
> >>> Jeff Jirsa
> >>>
> >>>
>  On Aug 23, 2018, at 1:00 PM, sankalp kohli 
> >> wrote:
> 
>  Separate repo is in a majority so far. Please reply to this thread
> with
>  your responses.
> 
>  On Tue, Aug 21, 2018 at 4:34 PM Rahul Singh <
> >> rahul.xavier.si...@gmail.com>
>  wrote:
> 
> > +1 for separate repo. Especially on git. Maybe make it a submodule.
> >
> > Rahul
> > On Aug 21, 2018, 3:33 PM -0500, Stefan Podkowinski  >,
> > wrote:
> >> I'm also currently -1 on the in-tree option.
> >>
> >> Additionally to what Aleksey mentioned, I also don't see how we
> could
> >> make this work with the current build and release process. Our
> scripts
> >> [0] for creating releases (tarballs and native packages), would need
> >> significant work to add support for an independent side-car. Our ant
> >> based build process is also not a great start for adding new tasks,
> >> let
> >> alone integrating other tool chains for web components for a
> potential
> > UI.
> >>
> >> [0] https://git-wip-us.apache.org/repos/asf?p=cassandra-builds.git
> >>
> >>
> >>> On 21.08.18 19:20, Aleksey Yeshchenko wrote:
> >>> Sure, allow me to elaborate - at least a little bit. But before I
> do,
> > just let me note that this wasn’t a veto -1, just a shorthand for “I
> >> don’t
> > like this option”.
> >>>
> >>> It would be nice to have sidecar and C* version and release cycles
> > fully decoupled. I know it *can* be done when in-tree, but the way we
> >> vote
> > on releases with tags off current branches would have to change
> >> somehow.
> > Probably painfully. It would be nice to be able to easily enforce
> >> freezes,
> > like the upcoming one, on the whole C* repo, while allowing feature
> > development on the sidecar. It would be nice to not have sidecar
> >> commits in
> > emails from commits@ mailing list. It would be nice to not have C*
> CI
> > trigger necessarily on sidecar commits. Groups of people working on
> >> the two
> > repos will mostly be different too, so what’s the point in sharing
> the
> >> repo?
> >>>
> >>> Having an extra repo with its own set of branches is cheap and
> easy -
> > we already do that with dtests. I like cleanly separated things when
> > coupling is avoidable. As such I would prefer the sidecar to live in
> a
> > separate new repo, while still being part of the C* project.
> >>>
> >>> —
> >>> AY
> >>>
> >>> On 21 August 2018 at 17:06:39, sankalp kohli (
> kohlisank...@gmail.com
> >> )
> > wrote:
> >>>
> >>> Hi Aleksey,
> >>> Can you please elaborate on the reasons for your -1? This
> >>> way we can make progress towards any one approach.
> >>> Thanks,
> >>> Sankalp
> >>>
> >>> On Tue, Aug 21, 2018 at 8:39 AM Aleksey Yeshchenko <
> >> alek...@apple.com>
> >>> wrote:
> >>>
>  FWIW I’m strongly -1 on in-tree approach, and would much prefer a
> > separate
>  repo, dtest-style.
> 
>  —
>  AY
> 
>  On 21 August 2018 at 16:36:02, Jeremiah D Jordan (
>  jeremiah.jor...@gmail.com) wrote:
> 
>  I think the following is a very big plus of it being in tree:
> >> * Faster iteration speed in general. For example when we need to
> > add a
> >> new
> >> JMX endpoint that the sidecar needs, or change something from
> > JMX to a
> >> virtual table (e.g. for repair, or monitoring) we can do all
> > changes
> >> including tests as one commit within the main repository and
> > don't
>  have
> >> to
> >> commit to main repo, sidecar repo,
> 
>  I also don’t see a reason why the sidecar being in tree means it
> > would not
>  work in a mixed version cluster. The nodes themselves must work
> in a
> > mixed
>  version cluster during a rolling upgrade, I would expect any
> > management
>  side car to operate in the same manor, in tre

Request for post-freeze merge exception

[Sam Tunnicliffe]

Hey all,

On 2018-31-08 CASSANDRA-14145 had been +1'd by two reviewers and CI was
green, and so it was marked Ready To Commit. This was before the 4.0
feature freeze but before it landed, CASSANDRA-14408, which touched a few
common areas of the code, was merged. I didn't have chance to finish the
rebase over the weekend but in the end it turned out that most of the
conflicts were in test code and were straightforward to resolve. I'd like
to commit this now; the rebase is done (& has been re-reviewed), and the CI
is still green so I suspect most of the community would probably be ok with
that. We did vote for a freeze though and I don't want to subvert or
undermine that decision, so I wanted to check and give a chance for anyone
to raise objections before I did.

I'll wait 24 hours, and if nobody objects before then I'll merge to trunk.

Thanks,
Sam

Re: JIRA Workflow Proposals

[Sam Tunnicliffe]

1: A
2: +1
3: +1
4: +1
5: +0
6: +1

On the question of keeping the contributors-only restriction on moving from 
Triage->Open, I tend to agree with Benedict that a low barrier can be useful in 
deterring bogus transitions (accidental or malicious) which keeps the general 
noise down. I’m thinking of the current situation where tickets are routinely 
marked "Ready To Commit” and which contributors have to spend time/energy 
watching for and fixing. That said, that only requires hitting a button not 
potentially filling out a bunch of fields so maybe we can afford to be 
permissive in the first instance here and tighten things up if it becomes a 
problem.


> On 6 Dec 2018, at 08:16, Sylvain Lebresne  wrote:
> 
> Not much to add really, but just to close the loop, responses inline.
> 
> On Wed, Dec 5, 2018 at 11:58 AM Benedict Elliott Smith  >
> wrote:
> 
>> Thanks for the feedback and further questions.  I’m sure there will be
>> more, particularly around permissions and roles, so it’s good to get some
>> of these other discussions moving.
>> 
>> No doubt we’ll do a second poll once the first one concludes.  Please,
>> everyone, keep your first poll answers coming!
>> 
>>> On 5 Dec 2018, at 09:50, Sylvain Lebresne  wrote:
>>> 
>>> Thanks for all those that contributed to the proposal, and specifically
>> to
>>> Benedict for leading the discussion.
>>> 
>>> On the general proposal, I suspect there is a few details we may have to
>>> tweak going forward, but hard to be sure before trying and as I do think
>>> it's progress, I'm personally happy to move forward with this. But for
>> the
>>> sake of discussions, a minor remarks that I don't think have been
>> mentioned
>>> above:
>>> - at least the platform and feature fields will be moving targets (the
>>> features hopefully more so than the platform, but new java version gets
>>> release regularly for instance). Do we know technically if we can get
>> those
>>> easily updated without requiring an infra JIRA ticket?
>> 
>> This is actually a really good question.  I had assumed this would be
>> treated much like Component, Version, etc
>> 
>> However, I was wrong:
>> 
>> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
>> <
>> https://community.atlassian.com/t5/Jira-questions/Adding-options-to-a-custom-field-as-project-administrator/qaq-p/113311
>>> 
>> 
>> There are some possible workarounds, but none of them seem great.  There’s
>> a plugin, but not sure if Infra would be OK with this:
>> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
>> <
>> https://marketplace.atlassian.com/apps/1212096/customfield-editor-plugin?hosting=server&tab=overview
>>> 
>> 
>> This is potentially a real blocker for these two fields.
>> 
>> So, for feature an alternative is to merge Feature/[Feature] into
>> Component.  This would implicitly make it non-mandatory, however.  This
>> could potentially be fixed with a custom field validator, but this might
>> need a plugin.
>> 
>> For Platform, I don’t have a good alternative idea right now.  This is
>> something that is best curated, but definitely needs to be easily updated.
>> 
> 
> That's what I feared, and that sucks. And I'm coming short as well of a
> good alternative that don't require plugins.
> That said, if push comes to shove, if we just make them free-form but
> mandatory to get out of triage (with "all" and "none" being explicitly ok
> values), and have a bit of documentation, there is still a good change
> we'll get meaningful information out of this. Better than what we have at
> least.
> 
> 
>>> - I'd personally probably remove the condition of being "jira
>> contributor"
>>> to move tickets out of triage. Being a "jira contributor" is a pretty
>>> arbitrary in practice. Anyone that ever asked has been added, no question
>>> asked, but it can actually be annoying to get added if no-one that knows
>>> how to do it is around. So if, as I assume, the goal is to ensure that
>>> fields are properly fielded, I don't think it will help much, and so I
>>> suspect it would just be an annoyance to new, not-yet-"jira contributor"
>>> users that are willing to fill all the required fields seriously (but
>> will
>>> see their ticket stuck in triage until they either get added, or some
>> other
>>> random user flip the switch). And why assume people will mis-field
>> stuffs?
>>> So I'd vote for just letting anyone transition out of triage as long as
>> all
>>> required field are there. Side-note: fwiw, I'd very much be in favor of
>>> removing the "jira contributor" concept for the reasons exposed above: I
>>> never felt it was anything else than an hindrance.
>> 
>> I realise we have no real barrier to becoming a contributor, and that many
>> of these permissions are going to have limited impact.  But I think a
>> really easy to jump gate can still be helpful, and I don’t recall
>

Re: JIRA Workflow Proposals

[Sam Tunnicliffe]

1: D C B A E
2: B C A
3: A 
4: -1 (get rid of Wish entirely)

Thanks,
Sam


> On 11 Dec 2018, at 22:01, Joseph Lynch  wrote:
> 
> Just my 2c
> 
> 1. D C B E A
> 2. B, C, A
> 3. A
> 4. +0.5
> 
> -Joey
> 
> On Tue, Dec 11, 2018 at 8:28 AM 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 <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/c7b95b827d8da4efc5c017df80029676a032b150ec00bf11ca9c7fa7@%3Cdev.cassandra.apache.org%3E
>>>> .
>> 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 <
>> murukesh.moha...@gmail.com> 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
>> <
>> 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

Re: [VOTE] Change Jira Workflow

[Sam Tunnicliffe]

+1

On Tue, 18 Dec 2018 at 13:47, Joshua McKenzie  wrote:

> +1
>
> On Tue, Dec 18, 2018 at 7:30 AM Aleksey Yeshchenko
>  wrote:
>
> > Sure, +1
> >
> > > On 18 Dec 2018, at 09:42, Joseph Lynch  wrote:
> > >
> > > +1 non-binding
> > >
> > > On Tue, Dec 18, 2018 at 1:15 AM Sylvain Lebresne 
> > wrote:
> > >
> > >> +1
> > >> --
> > >> Sylvain
> > >>
> > >>
> > >> On Tue, Dec 18, 2018 at 9:34 AM Oleksandr Petrov <
> > >> oleksandr.pet...@gmail.com>
> > >> wrote:
> > >>
> > >>> +1
> > >>>
> > >>> On Mon, Dec 17, 2018 at 7:12 PM Nate McCall 
> > wrote:
> > 
> >  On Tue, Dec 18, 2018 at 4:19 AM Benedict Elliott Smith
> >   wrote:
> > >
> > > I propose these changes <
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/CASSANDRA/JIRA+Workflow+Proposals
> > >>> *
> > >>> to the Jira Workflow for the project.  The vote will be open for 72
> > >> hours**.
> > >
> > 
> > 
> >  +1
> > 
> > 
> -
> >  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >  For additional commands, e-mail: dev-h...@cassandra.apache.org
> > 
> > >>>
> > >>>
> > >>> --
> > >>> alex p
> > >>>
> > >>> -
> > >>> 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
> >
> >
>

Question about PartitionUpdate.singleRowUpdate()

[Sam Klock]

Cassandra devs,

I have a question about the implementation of
PartitionUpdate.singleRowUpdate(), in particular the choice to use
EncodingStats.NO_STATS when building the resulting PartitionUpdate.  Is
there a functional reason for that -- i.e., is it safe to modify it to
use an EncodingStats built from deletionInfo, row, and staticRow?

Context: under 3.0.17, we have a table using TWCS and a secondary index.
We've been having a problem with the sstables for the index lingering
essentially forever, despite the correlated sstables for the parent
table being removed pretty much when we expect them to.  We traced the
problem to the use of EncodingStats.NO_STATS in singleRowUpdate(), which
is being used to create the index updates when we write to the parent
table.  It appears that NO_STATS is making Cassandra think the memtables
for the index have data from September 2015 in them, which in turn
prevents it from dropping expired sstables (all of which are much more
recent than that) for the index.

Experimentally, modifying singleRowUpdate() to build an EncodingStats
from its inputs (plus the MutableDeletionInfo it creates) seems to fix
the problem.  We don't have any insight into why the existing logic uses
NO_STATS, however, so we don't know if this change is really safe.  Does
it sound like we're on the right track?  (Also: I'm sure we'd be happy
to open an issue and submit a patch if this sounds like it would be
useful generally.)

Thanks,
SK

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

Re: Question about PartitionUpdate.singleRowUpdate()

[Sam Klock]

Thanks for the feedback.  I've opened:

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

SK

On 2018-12-19 17:03, Jeff Jirsa wrote:
> Definitely worth a JIRA. Suspect it may be slow to get a response this
> close to the holidays, but a JIRA will be a bit more durable than the
> mailing list post.
> 
> 
> On Wed, Dec 19, 2018 at 1:58 PM Sam Klock  wrote:
> 
>> Cassandra devs,
>>
>> I have a question about the implementation of
>> PartitionUpdate.singleRowUpdate(), in particular the choice to use
>> EncodingStats.NO_STATS when building the resulting PartitionUpdate.  Is
>> there a functional reason for that -- i.e., is it safe to modify it to
>> use an EncodingStats built from deletionInfo, row, and staticRow?
>>
>> Context: under 3.0.17, we have a table using TWCS and a secondary index.
>> We've been having a problem with the sstables for the index lingering
>> essentially forever, despite the correlated sstables for the parent
>> table being removed pretty much when we expect them to.  We traced the
>> problem to the use of EncodingStats.NO_STATS in singleRowUpdate(), which
>> is being used to create the index updates when we write to the parent
>> table.  It appears that NO_STATS is making Cassandra think the memtables
>> for the index have data from September 2015 in them, which in turn
>> prevents it from dropping expired sstables (all of which are much more
>> recent than that) for the index.
>>
>> Experimentally, modifying singleRowUpdate() to build an EncodingStats
>> from its inputs (plus the MutableDeletionInfo it creates) seems to fix
>> the problem.  We don't have any insight into why the existing logic uses
>> NO_STATS, however, so we don't know if this change is really safe.  Does
>> it sound like we're on the right track?  (Also: I'm sure we'd be happy
>> to open an issue and submit a patch if this sounds like it would be
>> useful generally.)
>>
>> Thanks,
>> SK
>>
>> -
>> 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

Git Repo Migration

[Sam Tunnicliffe]

As per the announcement on 7th December 2018[1], ASF infra are planning to 
shutdown the service behind git-wip-us.apache.org and migrate all existing 
repos to gitbox.apache.org 

There are further details in the original mail, but apparently one of the 
benefits of the migration is that we'll have full write access via Github, 
including the ability finally to close PRs. This affects the cassandra, 
cassandra-dtest and cassandra-build repos (but not the new cassandra-sidecar 
repo).

A pre-requisite of the migration is to demonstrate consensus within the 
community, so to satisfy that formality I'm starting this thread to gather any 
objections or specific requests regarding the timing of the move.

I'll collate responses in a week or so and file the necessary INFRA Jira.

Thanks,
Sam

[1] 
https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%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: Git Repo Migration

[Sam Tunnicliffe]

Yeah, I wasn’t really proposing a vote as like you said, it’s happening anyway. 
I was just going to give a few days for people to chime in about timings, 
seeing as some may still be afk after holidays etc. I’ll give it a little while 
to at least maintain the illusion of waiting for consensus, but filing the JIRA 
early next week SGTM.

Thanks,
Sam

> On 4 Jan 2019, at 16:24, Michael Shuler  wrote:
> 
> This change will be forced on Feb 7, so a vote isn't really relevant :)
> 
> I'm in favor of sooner is better. Things are relatively quiet right now,
> post-holidays. Let's do it Monday, for example, and we can work through
> the config changes while most people are fresh from a break.
> 
> The longer we wait, the more things people have in flight and they get
> bothered about being interrupted. Just interrupt ASAP, IMO.
> 
> Michael
> 
> On 1/4/19 4:49 AM, Sam Tunnicliffe wrote:
>> As per the announcement on 7th December 2018[1], ASF infra are
>> planning to shutdown the service behind git-wip-us.apache.org and
>> migrate all existing repos to gitbox.apache.org
>> 
>> There are further details in the original mail, but apparently one of
>> the benefits of the migration is that we'll have full write access
>> via Github, including the ability finally to close PRs. This affects
>> the cassandra, cassandra-dtest and cassandra-build repos (but not the
>> new cassandra-sidecar repo).
>> 
>> A pre-requisite of the migration is to demonstrate consensus within
>> the community, so to satisfy that formality I'm starting this thread
>> to gather any objections or specific requests regarding the timing of
>> the move.
>> 
>> I'll collate responses in a week or so and file the necessary INFRA
>> Jira.
>> 
>> Thanks, Sam
>> 
>> [1]
>> https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%3Cdev.cassandra.apache.org%3E
>> 
>> 
>> 
>> -
>> 
>> 
> 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: Git Repo Migration

[Sam Tunnicliffe]

https://issues.apache.org/jira/browse/INFRA-17593 
<https://issues.apache.org/jira/browse/INFRA-17593>

Thanks,
Sam

> On 4 Jan 2019, at 21:43, Jonathan Haddad  wrote:
> 
> Great news, we can also remove this line: We cannot merge or close any pull
> requests opened for the apache/cassandra repository, so please don't open
> them.
> 
> On Fri, Jan 4, 2019 at 1:27 PM Michael Shuler 
> wrote:
> 
>> Patches:
>> cassandra - https://github.com/apache/cassandra/pull/297
>> cassandra-builds - https://github.com/apache/cassandra-builds/pull/8
>> cassandra-dtest
>> <https://github.com/apache/cassandra-builds/pull/8cassandra-dtest> - no
>> git-wip usage found.
>> 
>> URL update for the DSL seed job repo should be the only change needed
>> there, after the above cassandra-builds commit.
>> - https://builds.apache.org/job/Cassandra-Job-DSL/
>> 
>> The only other consideration I can think of after migration is checking
>> the git.a.o bare and github mirror post-commit hooks work as expected.
>> - http://git.apache.org/cassandra.git/
>> 
>> Michael
>> 
>> On 1/4/19 2:00 PM, Jonathan Haddad wrote:
>>> Silence can be interpreted either as non-awareness or implicit approval.
>>> 
>>> I interpreted (and meant) +1 as "go for it now".
>>> 
>>> On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe  wrote:
>>> 
>>>> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
>>>> anyway. I was just going to give a few days for people to chime in about
>>>> timings, seeing as some may still be afk after holidays etc. I’ll give
>> it a
>>>> little while to at least maintain the illusion of waiting for consensus,
>>>> but filing the JIRA early next week SGTM.
>>>> 
>>>> Thanks,
>>>> Sam
>>>> 
>>>>> On 4 Jan 2019, at 16:24, Michael Shuler 
>> wrote:
>>>>> 
>>>>> This change will be forced on Feb 7, so a vote isn't really relevant :)
>>>>> 
>>>>> I'm in favor of sooner is better. Things are relatively quiet right
>> now,
>>>>> post-holidays. Let's do it Monday, for example, and we can work through
>>>>> the config changes while most people are fresh from a break.
>>>>> 
>>>>> The longer we wait, the more things people have in flight and they get
>>>>> bothered about being interrupted. Just interrupt ASAP, IMO.
>>>>> 
>>>>> Michael
>>>>> 
>>>>> On 1/4/19 4:49 AM, Sam Tunnicliffe wrote:
>>>>>> As per the announcement on 7th December 2018[1], ASF infra are
>>>>>> planning to shutdown the service behind git-wip-us.apache.org and
>>>>>> migrate all existing repos to gitbox.apache.org
>>>>>> 
>>>>>> There are further details in the original mail, but apparently one of
>>>>>> the benefits of the migration is that we'll have full write access
>>>>>> via Github, including the ability finally to close PRs. This affects
>>>>>> the cassandra, cassandra-dtest and cassandra-build repos (but not the
>>>>>> new cassandra-sidecar repo).
>>>>>> 
>>>>>> A pre-requisite of the migration is to demonstrate consensus within
>>>>>> the community, so to satisfy that formality I'm starting this thread
>>>>>> to gather any objections or specific requests regarding the timing of
>>>>>> the move.
>>>>>> 
>>>>>> I'll collate responses in a week or so and file the necessary INFRA
>>>>>> Jira.
>>>>>> 
>>>>>> Thanks, Sam
>>>>>> 
>>>>>> [1]
>>>>>> 
>>>> 
>> https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%3Cdev.cassandra.apache.org%3E
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 
> 
> -- 
> Jon Haddad
> http://www.rustyrazorblade.com
> twitter: rustyrazorblade

Re: Git Repo Migration

[Sam Tunnicliffe]

This migration is done, you'll need to update your git remotes like:

git remote set-url origin https://gitbox.apache.org/repos/asf/cassandra.git 

Committers, you'll need to link your github and apache accounts via 
htts://gitbox.apache.org to get push access.

Thanks,
Sam

> On 9 Jan 2019, at 11:48, Sam Tunnicliffe  wrote:
> 
> https://issues.apache.org/jira/browse/INFRA-17593 
> <https://issues.apache.org/jira/browse/INFRA-17593>
> 
> Thanks,
> Sam
> 
>> On 4 Jan 2019, at 21:43, Jonathan Haddad  wrote:
>> 
>> Great news, we can also remove this line: We cannot merge or close any pull
>> requests opened for the apache/cassandra repository, so please don't open
>> them.
>> 
>> On Fri, Jan 4, 2019 at 1:27 PM Michael Shuler 
>> wrote:
>> 
>>> Patches:
>>> cassandra - https://github.com/apache/cassandra/pull/297
>>> cassandra-builds - https://github.com/apache/cassandra-builds/pull/8
>>> cassandra-dtest
>>> <https://github.com/apache/cassandra-builds/pull/8cassandra-dtest> - no
>>> git-wip usage found.
>>> 
>>> URL update for the DSL seed job repo should be the only change needed
>>> there, after the above cassandra-builds commit.
>>> - https://builds.apache.org/job/Cassandra-Job-DSL/
>>> 
>>> The only other consideration I can think of after migration is checking
>>> the git.a.o bare and github mirror post-commit hooks work as expected.
>>> - http://git.apache.org/cassandra.git/
>>> 
>>> Michael
>>> 
>>> On 1/4/19 2:00 PM, Jonathan Haddad wrote:
>>>> Silence can be interpreted either as non-awareness or implicit approval.
>>>> 
>>>> I interpreted (and meant) +1 as "go for it now".
>>>> 
>>>> On Fri, Jan 4, 2019 at 8:48 AM Sam Tunnicliffe  wrote:
>>>> 
>>>>> Yeah, I wasn’t really proposing a vote as like you said, it’s happening
>>>>> anyway. I was just going to give a few days for people to chime in about
>>>>> timings, seeing as some may still be afk after holidays etc. I’ll give
>>> it a
>>>>> little while to at least maintain the illusion of waiting for consensus,
>>>>> but filing the JIRA early next week SGTM.
>>>>> 
>>>>> Thanks,
>>>>> Sam
>>>>> 
>>>>>> On 4 Jan 2019, at 16:24, Michael Shuler 
>>> wrote:
>>>>>> 
>>>>>> This change will be forced on Feb 7, so a vote isn't really relevant :)
>>>>>> 
>>>>>> I'm in favor of sooner is better. Things are relatively quiet right
>>> now,
>>>>>> post-holidays. Let's do it Monday, for example, and we can work through
>>>>>> the config changes while most people are fresh from a break.
>>>>>> 
>>>>>> The longer we wait, the more things people have in flight and they get
>>>>>> bothered about being interrupted. Just interrupt ASAP, IMO.
>>>>>> 
>>>>>> Michael
>>>>>> 
>>>>>> On 1/4/19 4:49 AM, Sam Tunnicliffe wrote:
>>>>>>> As per the announcement on 7th December 2018[1], ASF infra are
>>>>>>> planning to shutdown the service behind git-wip-us.apache.org and
>>>>>>> migrate all existing repos to gitbox.apache.org
>>>>>>> 
>>>>>>> There are further details in the original mail, but apparently one of
>>>>>>> the benefits of the migration is that we'll have full write access
>>>>>>> via Github, including the ability finally to close PRs. This affects
>>>>>>> the cassandra, cassandra-dtest and cassandra-build repos (but not the
>>>>>>> new cassandra-sidecar repo).
>>>>>>> 
>>>>>>> A pre-requisite of the migration is to demonstrate consensus within
>>>>>>> the community, so to satisfy that formality I'm starting this thread
>>>>>>> to gather any objections or specific requests regarding the timing of
>>>>>>> the move.
>>>>>>> 
>>>>>>> I'll collate responses in a week or so and file the necessary INFRA
>>>>>>> Jira.
>>>>>>> 
>>>>>>> Thanks, Sam
>>>>>>> 
>>>>>>> [1]
>>>>>>> 
>>>>> 
>>> https://lists.apache.org/thread.html/667772efdabf49a0a23d585539c127f335477e033f1f9b6f5079aced@%3Cdev.cassandra.apache.org%3E
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>>> 
>> 
>> -- 
>> Jon Haddad
>> http://www.rustyrazorblade.com
>> twitter: rustyrazorblade
> 


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

Re: Cassandra Integrated Auth for JMX

[Sam Tunnicliffe]

The built-in Cassandra auth for JMX works at the connector (i.e. RMI) level. If 
you try a direct JMX connection, such as jconsole, you should see the Cassandra 
access controls being enforced. As I understand it, Jolokia bypasses the 
connectors and so this auth config has no effect. In fact, Jolokia ships with 
its own policy-based method of configuring access controls. I haven't looked 
into it too much, but I think it would be possible to duplicate the 
functionality of Cassandra's built-in auth with a custom Jolokia Restrictor.

Thanks,
Sam


> On 16 Dec 2018, at 05:21, Cyril Scetbon  wrote:
> 
> Hey guys,
> 
> I’ve followed 
> https://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureJmxAuthentication.html
>  to setup JMX with Cassandra’s internal auth using Cassandra 3.11.3
> 
> However I still can connect to JMX without authenticating. You can see in the 
> following attempts that authentication is set up :
> 
> cassandra@ 2a1d064ce844 / $ cqlsh -u cassandra -p cassandra
> Connected to MyCluster at 127.0.0.1:9042.
> [cqlsh 5.0.1 | Cassandra 3.11.3 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> cassandra@cqlsh>
> 
> cassandra@ 2a1d064ce844 / $ cqlsh -u cassandra -p cassandra2
> Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
> AuthenticationFailed('Failed to authenticate to 127.0.0.1: Error from server: 
> code=0100 [Bad credentials] message="Provided username cassandra and/or 
> password are incorrect"',)})
> 
> Here is my whole JVM's configuration :
> 
> -Xloggc:/var/log/cassandra/gc.log, -XX:+UseThreadPriorities, 
> -XX:ThreadPriorityPolicy=42, -XX:+HeapDumpOnOutOfMemoryError, -Xss256k, 
> -XX:StringTableSize=103, -XX:+AlwaysPreTouch, -XX:-UseBiasedLocking, 
> -XX:+UseTLAB, -XX:+ResizeTLAB, -Djava.net.preferIPv4Stack=true, -Xms128M, 
> -Xmx128M, -XX:+UseG1GC, -XX:G1RSetUpdatingPauseTimePercent=5, 
> -XX:+PrintGCDetails, -XX:+PrintGCDateStamps, -XX:+PrintHeapAtGC, 
> -XX:+PrintTenuringDistribution, -XX:+PrintGCApplicationStoppedTime, 
> -XX:+PrintPromotionFailure, 
> -javaagent:/usr/local/share/jolokia-agent.jar=host=0.0.0.0,executor=fixed, 
> -javaagent:/usr/local/share/prometheus-agent.jar=1234:/etc/cassandra/prometheus.yaml,
>  -XX:+PrintCommandLineFlags, -Xloggc:/var/lib/cassandra/log/gc.log, 
> -XX:+UseGCLogFileRotation, -XX:NumberOfGCLogFiles=10, -XX:GCLogFileSize=10M, 
> -Dcassandra.migration_task_wait_in_seconds=1, 
> -Dcassandra.ring_delay_ms=3, 
> -XX:CompileCommandFile=/etc/cassandra/hotspot_compiler, 
> -javaagent:/usr/share/cassandra/lib/jamm-0.3.0.jar, 
> -Dcassandra.jmx.remote.port=7199, 
> -Dcom.sun.management.jmxremote.rmi.port=7199, 
> -Djava.library.path=/usr/share/cassandra/lib/sigar-bin, 
> -Dcom.sun.management.jmxremote.authenticate=true, 
> -Dcassandra.jmx.remote.login.config=CassandraLogin, 
> -Djava.security.auth.login.config=/etc/cassandra/cassandra-jaas.config, 
> -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy, 
> -Dcom.sun.management.jmxremote, -Dcom.sun.management.jmxremote.ssl=false, 
> -Dcom.sun.management.jmxremote.local.only=false, 
> -Dcassandra.jmx.remote.port=7199, 
> -Dcom.sun.management.jmxremote.rmi.port=7199, -Djava.rmi.server.hostname= 
> 2a1d064ce844, 
> -Dcassandra.libjemalloc=/usr/lib/x86_64-linux-gnu/libjemalloc.so.1, 
> -XX:OnOutOfMemoryError=kill -9 %p, -Dlogback.configurationFile=logback.xml, 
> -Dcassandra.logdir=/var/log/cassandra, 
> -Dcassandra.storagedir=/var/lib/cassandra, -Dcassandra-foreground=yes
> 
> But I still can query JMX without authenticating :
> 
> echo '{"mbean": "org.apache.cassandra.db:type=StorageService", "attribute": 
> "OperationMode", "type": "read"}' | http -a cassandra:cassandra POST 
> http://localhost:8778/jolokia/
> HTTP/1.1 200 OK
> Cache-control: no-cache
> Content-type: text/plain; charset=utf-8
> Date: Sun, 16 Dec 2018 05:15:36 GMT
> Expires: Sun, 16 Dec 2018 04:15:36 GMT
> Pragma: no-cache
> Transfer-encoding: chunked
> 
> {
>"request": {
>"attribute": "OperationMode",
>"mbean": "org.apache.cassandra.db:type=StorageService",
>"type": "read"
>},
>"status": 200,
>"timestamp": 1544937336,
>"value": "NORMAL"
> }
> 
> 
> I also have to add that I had to change permissions on the file 
> $JAVA_HOME/lib/management/jmxremote.password which is weird as it should not 
> be used in that case, but Cassandra was complaining before I did it.
> 
> Is there anything I'm missing ?
> 
> Thanks
> —
> Cyril Scetbon
> 


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

Re: Stabilising Internode Messaging in 4.0

[Sam Tunnicliffe]

+1 Thanks for articulating that so well Josh.

Sam

> On 12 Apr 2019, at 16:19, Blake Eggleston  
> wrote:
> 
> Well said Josh. You’ve pretty much summarized my thoughts on this as well.
> 
> +1 to moving forward with this
> 
>> On Apr 11, 2019, at 10:15 PM, Joshua McKenzie  wrote:
>> 
>> As one of the two people that re-wrote all our unit tests to try and help
>> Sylvain get 8099 out the door, I think it's inaccurate to compare the scope
>> and potential stability impact of this work to the truly sweeping work that
>> went into 8099 (not to downplay the scope and extent of this work here).
>> 
>> TBH, one of the big reasons we tend to drop such large PRs is the fact that
>>> Cassandra's code is highly intertwined and it makes it hard to precisely
>>> change things. We need to iterate towards interfaces that allow us to
>>> iterate quickly and reduce the amount of highly intertwined code. It helps
>>> with testing as well. I want us to have a meaningful discussion around it
>>> before we drop a big PR.
>> 
>> This has been a huge issue with our codebase since at least back when I
>> first encountered it five years ago. To date, while we have made progress
>> on this front, it's been nowhere near sufficient to mitigate the issues in
>> the codebase and allow for large, meaningful changes in smaller incremental
>> patches or commits. Having yet another discussion around this (there have
>> been many, many of them over the years) as a blocker for significant work
>> to go into the codebase is an unnecessary and dangerous blocker. Not to say
>> we shouldn't formalize a path to try and make incremental progress to
>> improve the situation, far from it, but blocking other progress on a
>> decade's worth of accumulated hygiene problems isn't going to make the
>> community focus on fixing those problems imo, it'll just turn away
>> contributions.
>> 
>> So let me second jd (and many others') opinion here: "it makes sense to get
>> it right the first time, rather than applying bandaids to 4.0 and rewriting
>> things for 4.next". And fwiw, asking people who have already done a huge
>> body of work to reformat that work into a series of commits or to break up
>> that work in a fashion that's more to the liking of people not involved in
>> either the writing of the patch or reviewing of it doesn't make much sense
>> to me. As I am neither an assignee nor reviewer on this contribution, I
>> leave it up to the parties involved to do things professionally and with a
>> high standard of quality. Admittedly, a large code change merging in like
>> this has implications for rebasing on anyone else's work that's in flight,
>> but be it one commit merged or 50, or be it one JIRA ticket or ten, the
>> end-result is the same; any large contribution in any format will ripple
>> outwards and require re-work from others in the community.
>> 
>> The one thing I *would* strongly argue for is performance benchmarking of
>> the new messaging code on a representative sample of different
>> general-purpose queries, LWT's, etc, preferably in a 3 node RF=3 cluster,
>> plus a healthy suite of jmh micro-benches (assuming they're not already in
>> the diff. If they are, disregard / sorry). From speaking with Aleksey
>> offline about this work, my understanding is that that's something they
>> plan on doing before putting a bow on things.
>> 
>> In the balance between "fear change because it destabilizes" and "go forth
>> blindly into that dark night, rewriting All The Things", I think the
>> Cassandra project's willingness to jettison the old and introduce the new
>> has served it well in keeping relevant as the years have gone by. I'd hate
>> to see that culture of progress get mired in a dogmatic adherence to
>> requirements on commit counts, lines of code allowed / expected on a given
>> patch set, or any other metrics that might stymie the professional needs of
>> some of the heaviest contributors to the project.
>> 
>> On Wed, Apr 10, 2019 at 5:03 PM Oleksandr Petrov 
>> wrote:
>> 
>>> Sorry to pick only a few points to address, but I think these are ones
>>> where I can contribute productively to the discussion.
>>> 
>>>> In principle, I agree with the technical improvements you
>>> mention (backpressure / checksumming / etc). These things should be there.
>>> Are they a hard requirement for 4.0?
>>> 
>>> One thing that comes to mind i

Re: Jira Suggestion

[Sam Tunnicliffe]

+1 

> On 14 May 2019, at 20:10, Benedict Elliott Smith  wrote:
> 
> It will be possible to insert n/a.  It will simply be a text field - Jira 
> doesn’t know anything about the concept of a SHA, and I don’t intend to 
> introduce validation logic.  It’s just a logical and consistent place for it 
> to live, and a strong reminder to include it.  My intention is for it to be a 
> text field supporting Jira markup, like Test and Doc Plan, so that we can 
> insert cleanly formatted links to GitHub just like we do now in comments.
> 
> 
> 
>> On 14 May 2019, at 20:04, Dinesh Joshi  wrote:
>> 
>> I am +0.5 on this. I think it is a good idea. I want to ensure that we 
>> capture use-cases such as Tasks that may not have a git commit associated 
>> with them. There might be tickets that may have multiple git commits across 
>> repos. SVN commits may also need to be handled.
>> 
>> Dinesh
>> 
>>> On May 14, 2019, at 11:34 AM, Jeff Jirsa  wrote:
>>> 
>>> Please
>>> 
>>> -- 
>>> Jeff Jirsa
>>> 
>>> 
 On May 14, 2019, at 7:53 AM, Benedict Elliott Smith  
 wrote:
 
 How would people feel about introducing a field for the (git) commit SHA, 
 to be required on (Jira) commit?
 
 The norm is that we comment the SHA, but given this is the norm perhaps we 
 should codify it instead, while we have the chance?  It would also make it 
 easier to find.
 -
 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: Java8 compatibility broken in 4.0

[Sam Tunnicliffe]

> On 11 Jun 2019, at 10:04, Tommy Stendahl  wrote:
> 
> Hi,
> 
> I can't find a way to build 4.0 artifacts so I can run Cassandra using Java8. 
> Building the artifacts ("ant artifacts" or "ant mvn-install") requires 
> building with Java11 but since CASSANDRA-15108 the result is not Java8 
> compatible anymore, is this intentional or was this done by mistake?

This was unintentional, it looks like we just missed removing the 
“unless=java.version.8” from the artifacts & _artifacts-init targets in 
build.xml.
I’ve tested that with those removed, it’s just a matter of having the 
appropriate target jdk specified in $JAVA_HOME (and using -Duse.jdk11=true or 
$CASSANDRA_USE_JDK11=true if building with jdk11).

We’ll fix this in trunk, but in the meantime removing those conditions should 
unblock you.

Thanks,
Sam

> 
> I also tried to change this back and force Java11 to build Java8 compatible 
> code but it seams that there are some  changes in the ByetBuffer 
> implementation in Java11 that breaks when execution in a Java8 jvm, when I 
> started Cassandra it throws a NoSuchMethodError when trying to open the 
> sstables.
> 
> 2019-05-28T16:20:24.506+0200 [SSTableBatchOpen:4] ERROR 
> o.a.c.i.s.format.SSTableReader$2:576 run Corrupt sstable 
> /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big=[CompressionInfo.db,
>  TOC.txt, Statistics.db, Summary.db, Index.db, Data.db, Filter.db, 
> Digest.crc32]; skipping table
> org.apache.cassandra.io.sstable.CorruptSSTableException: Corrupted: 
> /var/lib/cassandra/data/system/sstable_activity-5a1ff267ace03f128563cfae6103c65e/mc-2202-big-Statistics.db
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:504)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:375)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader$2.run(SSTableReader.java:571)
>at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NoSuchMethodError: 
> java.nio.ByteBuffer.position(I)Ljava/nio/ByteBuffer;
>at 
> org.apache.cassandra.utils.memory.BufferPool.allocateDirectAligned(BufferPool.java:528)
>at 
> org.apache.cassandra.utils.memory.BufferPool.access$600(BufferPool.java:46)
>at 
> org.apache.cassandra.utils.memory.BufferPool$GlobalPool.allocateMoreChunks(BufferPool.java:279)
>at 
> org.apache.cassandra.utils.memory.BufferPool$GlobalPool.get(BufferPool.java:248)
>at 
> org.apache.cassandra.utils.memory.BufferPool$LocalPool.addChunkFromGlobalPool(BufferPool.java:354)
>at 
> org.apache.cassandra.utils.memory.BufferPool$LocalPool.get(BufferPool.java:397)
>at 
> org.apache.cassandra.utils.memory.BufferPool.maybeTakeFromPool(BufferPool.java:143)
>at 
> org.apache.cassandra.utils.memory.BufferPool.takeFromPool(BufferPool.java:115)
>at org.apache.cassandra.utils.memory.BufferPool.get(BufferPool.java:94)
>at 
> org.apache.cassandra.io.util.BufferManagingRebufferer.(BufferManagingRebufferer.java:45)
>at 
> org.apache.cassandra.io.util.BufferManagingRebufferer$Unaligned.(BufferManagingRebufferer.java:117)
>at 
> org.apache.cassandra.io.util.SimpleChunkReader.instantiateRebufferer(SimpleChunkReader.java:60)
>at 
> org.apache.cassandra.io.util.RandomAccessReader.open(RandomAccessReader.java:319)
>at 
> org.apache.cassandra.io.sstable.metadata.MetadataSerializer.deserialize(MetadataSerializer.java:126)
>at 
> org.apache.cassandra.io.sstable.format.SSTableReader.open(SSTableReader.java:500)
>... 8 common frames omitted
> 
> The reason for this is that some methods in the ByteBuffer implementation in 
> Java11 returns a Bytebuffer but in Java8 and before they returned a Buffer. I 
> found a bit of information on Stackoverflow 
> (https://stackoverflow.com/questions/48693695/java-nio-buffer-not-loading-clear-method-on-runtime)
>  so there seams to be a way to fix this even if the resulting code looks ugly 
> to me.
> 
> My question is, are we intentionally giving up Java8 comparability in 4.0 or 
> do we still want to support Java8?
> 
> Regards,
> Tommy


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

Re: Time for a new 3.0/3.11 release?

[Sam Tunnicliffe]

It would also be good to include CASSANDRA-15193 (which I only just created, 
sorry), as the counterpart to CASSANDRA-15176. I have a patch for this mostly 
done and will post it in the next day or two.

> On 2 Jul 2019, at 07:13, Mick Semb Wever  wrote:
> 
>> It would be nice to have time to get CASSANDRA-14812 in
> 
> Yes.
> 
> I will try and wrap up my review of 14812 today.  Another pair of eyes is 
> always welcome, especially anyone with experience on the various 
> StoppingTransformation usages.
> 
> regards,
> Mick
> 
> -
> 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

[Sam Tunnicliffe]

My own weak preference would be for a dedicated repo in the first instance. 
If/when additional tools are contributed we should look at co-locating common 
stuff, but rushing toward a monorepo would be a mistake IMO.

> On 22 Aug 2019, at 11:10, Jeff Jirsa  wrote:
> 
> I weakly prefer contrib.
> 
> 
> On Thu, Aug 22, 2019 at 12:09 PM 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

Re: Can we kick off a release?

[Sam Tunnicliffe]

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

Re: [VOTE] Release Apache Cassandra 4.0-alpha2

[Sam Tunnicliffe]

+1

> On 24 Oct 2019, at 18:26, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 4.0-alpha2.
> 
> sha1: ca928a49c68186bdcd57dea8b10c30991c6a3c55
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0-alpha2-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/org/apache/cassandra/apache-cassandra/4.0-alpha2/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1185/
> 
> 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/4.0-alpha2-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0-alpha2-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.5

[Sam Tunnicliffe]

+1

> On 24 Oct 2019, at 18:26, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.11.5.
> 
> sha1: b697af87f8e1b20d22948390d516dba1fbb9eee7
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.5-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/org/apache/cassandra/apache-cassandra/3.11.5/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1184/
> 
> 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.5-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.11.5-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 2.2.15

[Sam Tunnicliffe]

+1

> On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 2.2.15.
> 
> sha1: 4ee4ceea28a1cb77b283c7ce0135340ddff02086
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.15-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/org/apache/cassandra/apache-cassandra/2.2.15/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1179/
> 
> 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.15-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/2.2.15-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.19

[Sam Tunnicliffe]

+1

> On 24 Oct 2019, at 18:25, Michael Shuler  wrote:
> 
> I propose the following artifacts for release as 3.0.19.
> 
> sha1: a81bfd6b7db3a373430b3c4e8f4e930b199796f0
> Git: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.19-tentative
> Artifacts: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/org/apache/cassandra/apache-cassandra/3.0.19/
> Staging repository: 
> https://repository.apache.org/content/repositories/orgapachecassandra-1183/
> 
> 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.19-tentative
> [2]: NEWS.txt: 
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/3.0.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 dtest-api 0.0.1

[Sam Tunnicliffe]

+1

Sam

> On 23 Mar 2020, at 09:36, Oleksandr Petrov  wrote:
> 
> Thanks to everyone who participated in the previous vote, I appreciate your
> feedback.
> 
> @Mick, thank you for sending a patch and helping to figure out the release
> procedure and specifics.
> 
> Proposing the test build of in-jvm dtest API 0.0.1 for release.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.1
> Candidate SHA:
> https://github.com/apache/cassandra-in-jvm-dtest-api/commit/7a2f029676d3b9294f10263742aa4ba07b9abcfd
> /
> tagged with 0.0.1
> Artifact:
> https://repository.apache.org/content/repositories/orgapachecassandra-1201/org/apache/cassandra/dtest-api/0.0.1/
> Key signature: 9E66CEC6106D578D0B1EB9BFF1000962B7F6840C
> 
> Changes since the previous vote (see [3] for details):
> 
>  * code is now in master branch; pointing to the right SHA
>  * release version is 0.0.1, not 0.0.3
>  * there's only a source jar, no source zip; checksum files are now correct
>  * NOTICE file is now added, missing license headers added, RAT checks are
> passing
> 
> 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.
> 
> To make sure, my key is still not in Cassandra KEYS file, there's an issue
> [2] open to track it.
> 
> -- Alex
> 
> [1] https://issues.apache.org/jira/browse/CASSANDRA-15539
> [2] https://issues.apache.org/jira/browse/CASSANDRA-15652
> [3] https://www.mail-archive.com/dev@cassandra.apache.org/msg14741.html


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

Re: Keeping test-only changes out of CHANGES.txt

[Sam Tunnicliffe]

+1

> On 8 Apr 2020, at 15:08, Mick Semb Wever  wrote:
> 
> Can we agree on keeping such test changes out of CHANGES.txt ?
> 
> We already don't put entries into CHANGES.txt if it is not a change
> from any previous release.
> 
> There was some discussion before¹ about this, and the problem that
> being selective meant what ended up there being arbitrary. I think
> this can be solved with an easy rule of thumb that if it only touches
> *Test.java classes, or it is only about fixing a test, then it
> shouldn't be in CHANGES.txt. That means if the patch does touch any
> runtime code then you do still need to add an entry to CHANGES.txt.
> This avoids the whole "arbitrary" problem,  and maintains CHANGES.txt
> as user-facing formatted text to be searched through.
> 
> If there's agreement I can commit to going through 4.0 changes and
> removing those that never touched runtime code.
> 
> regards,
> Mick
> 
> ¹) 
> https://lists.apache.org/thread.html/a94946887081d8a408dd5cd01a203664f4d0197df713f0c63364a811%40%3Cdev.cassandra.apache.org%3E
> 
> -
> 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: Simplify voting rules for in-jvm-dtest-api releases

[Sam Tunnicliffe]

+1

> On 15 Apr 2020, at 14:35, Oleksandr Petrov  wrote:
> 
> Hi everyone,
> 
> Apache release rules were made for first-class projects. I would like to
> propose simplifying voting rules for in-jvm-dtest-api project [1].
> 
> A bit of background: in-jvm-dtest-api is a project that is used by all
> active Cassandra branches (2.2, 3.0, 3.11, and trunk) to unify interfaces
> that allows creating clusters and running tests, much like Python dtests,
> just with a potential to run and develop them faster. Previously, anyone
> could break API compatibility by committing to only one of the branches and
> not updating the other one, which has happened on several occasions and has
> went unnoticed, and has added work for people who had to bring changes to
> more than one branch. This unified API and tests are particularly useful
> for upgrade tests, but are also good for any kind of testing.
> 
> Since this project was made to simplify contributions to in-jvm dtests,
> it'd be great if making changes to this project would actually be simple.
> Before that, in order to make changes in in-jvm-dtest API, we required
> only +1 from a contributor and a committer could just commit the change.
> 
> I would say that in order to cut a (minor) release of in-jvm-dtest-api you
> should:
> 
> 1. Get a +1 from a contributor who can review and test your change
> 2. Get a +1 from one of committers who are familiar with in-jvm dtests (we
> have enough, I just don't want to volunteer anyone)
> 
> This will guard us from unnecessary changes, and add an extra pair of eyes
> for things that influence moore than one branch, but leave us flexible
> enough to be able to move forward without conducting a vote.
> 
> Since in-jvm-dtest-api is only used to test Cassandra, and isn't intended
> for production purposes, this is a low-risk change in procedure. Moreover,
> even if we package in-jvm-dtest-api with some Cassandra release, there will
> be an additional vote on the release, where anyone who has concerns about
> in-jvm-dtest-api changes can still voice them.
> 
> Please let me know if you'd like more information about in-jvm-dtest API,
> or have comments about this change in procedure.
> 
> Thank you,
> -- Alex
> [1] https://github.com/apache/cassandra-in-jvm-dtest-api


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

Re: Calling for release managers (Committers and PMC)

[Sam Tunnicliffe]

Me too.

> On 11 May 2020, at 20:23, Jake Luciani  wrote:
> 
> Happy to lend a hand
> 
> On Mon, May 11, 2020 at 3:12 PM Eric Evans 
> wrote:
> 
>> I can take a turn.
>> 
>> On Fri, May 8, 2020 at 11:10 AM Vinay Chella 
>> wrote:
>>> 
>>> I would like to help as well.
>>> 
>>> 
>>> On Fri, May 8, 2020 at 8:54 AM Chris Lohfink 
>> wrote:
>>> 
 I'd like to get involved in this as well.
 
 On Thu, May 7, 2020 at 2:06 PM Jon Meredith 
>> wrote:
 
> Sign me up.
> 
> On Thu, May 7, 2020 at 12:36 PM Robert Stupp  wrote:
>> 
>> I can help
>> 
>> --
>> Robert Stupp
>> @snazy
>> 
>>> Am 07.05.2020 um 20:29 schrieb Mick Semb Wever :
>>> 
>>> The Cassandra release process has had some improvements to
>> better in
>>> line with the ASF guidelines: sha256 & sha512 checksums, staged
>>> artefacts in svnpubsub, dep and rpm repositories complete and
>> signed
>>> in staging, and separate scripts and manual steps merged
>> together.
>>> 
>>> The updated documentation for cutting, voting, and publishing a
>>> release is found here:
>>> 
> 
>> https://cassandra.apache.org/doc/latest/development/release_process.html
>>> 
>>> I am hoping to get as many Committers* and PMC members
>> interested as
>>> possible for cutting a future release.
>>> 
>>> Who is interested? How many names can I get :-)
>>> 
>>> The more that are interested then the easier it is to take turns
>> and
>>> be flexible depending on our own availability each time. I will
>> help
>>> out everyone on their first run. Indeed most of my motivation in
>>> getting involved with the release process was to make it all as
 simple
>>> and as forgettable as possible, so the role of the role manager
>> can
>>> change easily from release to release.
>>> 
>>> *When a Committer cuts a release, a PMC member has to perform the
 very
>>> last post-vote publish step.
>>> 
>>> regards,
>>> Mick
>>> 
>>> 
>> -
>>> 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
> 
> 
 
>>> --
>>> 
>>> Thanks,
>>> Vinay Chella
>> 
>> 
>> 
>> --
>> Eric Evans
>> john.eric.ev...@gmail.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: [DISCUSSION] Flaky tests

[Sam Tunnicliffe]

> I have the feeling that the thing that prevents us primarily from
cutting beta at the moment is flaky tests

CASSANDRA-15299 is still in progress and I think we have to consider it a 
blocker, given that beta "should be interface-stable, so that consumers do not 
have to incur any code changes on their end, as the release progresses from 
Alpha through EOL."


> On 28 May 2020, at 01:23, Joshua McKenzie  wrote:
> 
>> 
>> So my idea was to suggest to start tracking an exact Jenkins report maybe?
> 
> Basing our point of view on the canonical test runs on apache infra makes
> sense to me, assuming that infra is behaving these days. :) Pretty sure
> Mick got that in working order.
> 
> At least for me, what I learned in the past is we'd drive to a green test
> board and immediately transition it as a milestone, so flaky tests would
> reappear like a disappointing game of whack-a-mole. They seem frustratingly
> ever-present.
> 
> I'd personally advocate for us taking the following stance on flaky tests
> from this point in the cycle forward:
> 
>   - Default posture to label fix version as beta
>   - *excepting* on case-by-case basis, if flake could imply product defect
>   that would greatly impair beta testing we leave alpha
>   - Take current flakes and go fixver beta
>   - Hard, no compromise position on "we don't RC until all flakes are dead"
>   - Use Jenkins as canonical source of truth for "is beta ready" cutoff
> 
> I'm personally balancing the risk of flaky tests confounding beta work
> against my perceived value of being able to widely signal beta's
> availability and encourage widespread user testing. I believe the value in
> the latter justifies the risk of the former (I currently perceive that risk
> as minimal; I could be wrong). I am also weighting the risk of "test
> failures persist to or past RC" at 0. That's a hill I'll die on.
> 
> 
> On Wed, May 27, 2020 at 5:13 PM Ekaterina Dimitrova <
> ekaterina.dimitr...@datastax.com> wrote:
> 
>> Dear all,
>> I spent some time these days looking into the Release Lifecycle document.
>> As we keep on saying we approach Beta based on the Jira board, I was
>> curious what is the exact borderline to cut it.
>> 
>> Looking at all the latest reports (thanks to everyone who was working on
>> that; I think having an overview on what's going on is always a good
>> thing), I have the feeling that the thing that prevents us primarily from
>> cutting beta at the moment is flaky tests. According to the lifecycle
>> document:
>> 
>>   - No flaky tests - All tests (Unit Tests and DTests) should pass
>>   consistently. A failing test, upon analyzing the root cause of failure,
>> may
>>   be “ignored in exceptional cases”, if appropriate, for the release,
>> after
>>   discussion in the dev mailing list."
>> 
>> Now the related questions that popped up into my mind:
>> - "ignored in exceptional cases" - examples?
>> - No flaky tests according to Jenkins or CircleCI? Also, some people run
>> the free tier, others take advantage of premium CircleCI. What should be
>> the framework?
>> - Furthermore, flaky tests with what frequency? (This is a tricky question,
>> I know)
>> 
>> In different conversations with colleagues from the C* community I got the
>> impression that canonical suite (in this case Jenkins) might be the right
>> direction to follow.
>> 
>> To be clear, I am always checking any failures seen in any environment and
>> I truly believe that they are worth it to be checked. Not advocating to
>> skip anything!  But also, sometimes I feel in many cases CircleCI could
>> provide input worth tracking but less likely to be product flakes. Am I
>> right? In addition, different people use different CircleCI config and see
>> different output. Not to mention flaky tests on Mac running with two
>> cores... Yes, this is sometimes the only way to reproduce some of the
>> reported tests' issues...
>> 
>> So my idea was to suggest to start tracking an exact Jenkins report maybe?
>> Anything reported out of it also to be checked but potentially to be able
>> to leave it for Beta in case we don't feel it shows a product defect. One
>> more thing to consider is that the big Test epic is primarily happening in
>> beta.
>> 
>> Curious to hear what the community thinks about this topic. Probably people
>> also have additional thoughts based on experience from the previous
>> releases. How those things worked in the past? Any lessons learned? What is
>> our "plan Beta"?
>> 
>> Ekaterina Dimitrova
>> e. ekaterina.dimitr...@datastax.com
>> w. www.datastax.com
>> 


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

Re: [DISCUSS] Considering when to push tickets out of 4.0

[Sam Tunnicliffe]

> On 17 Jun 2020, at 09:36, Benedict Elliott Smith  wrote:
> 
> If these tickets are the only blockers I agree with Scott's assessment.  We 
> could even disable the v5 protocol if we're keen to get it out of the door 
> today, and only enable it once 15299 lands.  I don't personally think the 
> other two tickets would be impossible to land during a beta either, even if 
> they are API affecting - they should be backwards compatible after all.

I feel the same way, though rather than disabling v5 we could just decide that 
removing its beta status needn't be a requirement for 4.0. As has been 
mentioned in previous threads, we aren't planning to remove v4, or even v3, 
support in 4.0 so keeping v5 as a beta protocol version would allow time for 
the drivers to implement full support before promoting it to a fully supported 
version. Making such a change, which only modifies the status of the version, 
seems reasonable in a minor provided that the beta version has been thoroughly 
validated.  

As far as I'm aware, neither the java, python nor gocql drivers currently 
support the existing checksumming feature from CASSANDRA-13304. So I'm 100% in 
agreement with Benedict that we should revert this before beta. The remaining 
decision is whether we feel it's appropriate and desirable to release v5 
without any additional mechanism for ensuring integrity. If so, then we could 
punt 15299 out of 4.0/v5 entirely; if not then we either hold off cutting 4.0 
beta until 15299 is available or we remove the expectation that v5 will come 
out of beta in 4.0 

Responding to Mick from earlier in the thread:

> I understand the importance of CASSANDRA-15299. But it hasn't had any
> comments in 12 twelve days, and in this stage of the feature freeze, with
> so few alpha bugs remaining, that's a long time. Sam, can you speak to its
> eta?

That is way too long without any visible progress and I apologise for the radio 
silence. I have a rather small amount of tidying up to do, but otherwise I 
think what I have is ready for review and the client facing aspects are stable. 
I'm still actively working on a test harness and have some bulk renaming to do 
to, but I don't think that these should hold up the review too much. I'll aim 
to push an update to the JIRA tomorrow.


> 
>> [Josh] however historically on the project we've had a large number of 
>> defects surfaced by a diverse collection of users
>> [Scott] this was in part a case of a pressing need to investigate a 
>> potential 3.0 data resurrection issue drawing attention from 4.0
> 
> This is a really common theme with 4.0, whose timeline has been hit primarily 
> because of issues still circulating with the 3.0 line that were never 
> discovered by testing or user reports during beta, RC, or four years of 
> releases.  My personal view, informed by this, is that we _didn't find_ the 
> most serious bugs historically, even with user reports, and we need to be 
> honest with ourselves about this in order to plot a route forwards to high 
> quality releases.  We cannot _depend_ on community feedback for determining 
> release quality; we need a plan to consciously deliver it ourselves.
> 
> 
> On 17/06/2020, 05:12, "Scott Andreas"  wrote:
> 
>I'll take attribution for the delay in comment on 15299; this was in part 
> a case of a pressing need to investigate a potential 3.0 data resurrection 
> issue drawing attention from 4.0.
> 
>I agree with the statement that we shouldn't consider protocol V5 ready 
> for finalization in its current form. If we feel that this ticket alone is 
> what delays release of beta and are comfortable with a release note caveating 
> that one V5 ticket remains before the new protocol is finalized, that could 
> be a reasonable compromise.
> 
>I don't have especially strong feelings re: 15146 and 14825 and think 
> these are reasonable candidates for deferral.
> 
>
>From: Joshua McKenzie 
>Sent: Tuesday, June 16, 2020 4:08 PM
>To: dev@cassandra.apache.org
>Subject: Re: [DISCUSS] Considering when to push tickets out of 4.0
> 
>I completely respect and agree with the need for a drumbeat to change our
>culture around testing and quality; I also agree we haven't done much to
>materially change that uniquely to 4.0. The 40_quality_testing epic is our
>first step in that direction though I have some personal concerns about
>leaning on bespoke manual testing for quality since we humans are
>infinitely fallible. :)
> 
>What elicited that response from me is the claim that we haven't yet tested
>the software, implicitly invalidating the time and energy the

Re: [VOTE] Project governance wiki doc

[Sam Tunnicliffe]

+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

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

[Sam Tunnicliffe]

+1

> On 22 Jun 2020, at 08:54, Sylvain Lebresne  wrote:
> 
> +1
> --
> Sylvain
> 
> 
> On Mon, Jun 22, 2020 at 9:48 AM Benjamin Lerer 
> wrote:
> 
>> +1
>> 
>> On Mon, Jun 22, 2020 at 8:54 AM Marcus Eriksson 
>> wrote:
>> 
>>> +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
>>> 
>>> 
>> 


-
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.17

[Sam Tunnicliffe]

+1

> On 24 Jul 2020, at 12:07, Mick Semb Wever  wrote:
> 
>> Proposing the test build of Cassandra 2.2.17 for release.
>> 
>> sha1: cd006d275aa9b6e937c6ebd036d4d27c4ed18dbe
> 
> 
> +1 (binding)
> 
> 
> Test Results:  
> https://ci-cassandra.apache.org/job/Cassandra-2.2/28/testReport/
> 
> 
> Checked:
> - gpg signatures (maven artefacts, dist artefacts, deb/rpm packages
> and repositories),
> - sha checksums (maven artefacts, dist artefacts, deb/rpm packages
> and repositories),
> - binary convenience artefact runs
> - src convenience artefacts builds with one command, and runs
> - deb and rpm install and run
> 
> Remaining issues:
> - binary convenience artefact contains javadoc (CASSANDRA-15561)
> - lib/ directory (binary files) bundled into the src artefact
> 
> -
> 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-beta2

[Sam Tunnicliffe]

+1

> On 28 Aug 2020, at 15:18, Mick Semb Wever  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 Apache Cassandra 3.0.22

[Sam Tunnicliffe]

+1

> On 28 Aug 2020, at 14:09, Mick Semb Wever  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

[Sam Tunnicliffe]

+1

> On 28 Aug 2020, at 13:44, Mick Semb Wever  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 3.11.8

[Sam Tunnicliffe]

+1

> On 28 Aug 2020, at 14:37, Mick Semb Wever  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 2.1.22

[Sam Tunnicliffe]

+1

> On 28 Aug 2020, at 16:42, Mick Semb Wever  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

CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability

[Sam Tunnicliffe]

CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability

Versions Affected:
All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2

Description:
It is possible for a local attacker without access to the Apache Cassandra 
process or configuration files to manipulate the RMI registry to perform a 
man-in-the-middle attack and capture user names and passwords used to access 
the JMX interface. The attacker can then use these credentials to access the 
JMX interface and perform unauthorised operations.
Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables 
this issue to be exploited remotely.

Mitigation:
2.1.x users should upgrade to 2.1.22
2.2.x users should upgrade to 2.2.18
3.0.x users should upgrade to 3.0.22
3.11.x users should upgrade to 3.11.8
4.0-beta1 users should upgrade to 4.0-beta2

Re: [DISCUSS] Change style guide to recommend use of @Override

[Sam Tunnicliffe]

+1

> On 2 Sep 2020, at 09:03, Benjamin Lerer  wrote:
> 
> +1
> 
> 
> 
> On Wed, Sep 2, 2020 at 5:36 AM Berenguer Blasi 
> wrote:
> 
>> +1
>> 
>> On 2/9/20 5:09, Joshua McKenzie wrote:
>>> +1
>>> 
>>> On Tue, Sep 1, 2020 at 6:26 PM Jordan West  wrote:
>>> 
 +1
 
 On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith <
 bened...@apache.org>
 wrote:
 
> +1
> 
> 
> 
> On 01/09/2020, 20:09, "Caleb Rackliffe" 
 wrote:
> 
> 
>+1
> 
> 
> 
>On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang <
> jasonstack.z...@gmail.com>
> 
>wrote:
> 
> 
> 
>> +1
> 
>> 
> 
>> On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi 
 wrote:
>> 
> 
>>> +1
> 
>>> 
> 
 On Sep 1, 2020, at 11:27 AM, David Capwell <
>> dcapw...@gmail.com
> 
> wrote:
> 
 
> 
 Currently our style guide recommends to avoid using @Override
 and
>> updates
> 
 intellij's code style to exclude it by default; I would like
>> to
> propose
> 
>>> we
> 
 change this recommendation to use it and to update intellij's
> style to
> 
 include it by default.
> 
 
> 
 @Override is used by javac to enforce that a method is in
>> fact
> 
>> overriding
> 
 from an abstract class or an interface and if this stops
>> being
> true
> 
>> (such
> 
 as a refactor happens) then a compiler error is thrown; when
>> we
> default
> 
>>> to
> 
 excluding, it makes it harder to detect that a refactor
>> catches
> all
> 
 implementations and can lead to subtle and hard to track down
> bugs.
> 
 
> 
 This proposal is for new code and would not be to go rewrite
 all
> code
> 
>> at
> 
 once, but would recommend new code adopt this style, and to
 pull
> old
> 
>> code
> 
 forward which is related to changes being made (similar to
>> our
> stance
> 
>> on
> 
 imports).
> 
 
> 
 If people are ok with this, I will file a JIRA, update the
 docs,
> and
> 
 update intellij's formatting.
> 
 
> 
 Thanks for your time!
> 
>>> 
> 
>>> 
> 
>>> 
> -
> 
>>> 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: [VOTE] Accept the Harry donation

[Sam Tunnicliffe]

+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

Re: [VOTE] Release dtest-api 0.0.5

[Sam Tunnicliffe]

+1

> On 25 Sep 2020, at 15:45, Oleksandr Petrov  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: Cassandra Contributor Meeting to focus on outstanding 4.0 issues

[Sam Tunnicliffe]

> On 29 Sep 2020, at 09:50, Mick Semb Wever  wrote:
> 
>> Regarding the proposed agenda of going through the unassigned issues to
>> improve visibility on what needs to be done to ship 4.0 GA I think this is
>> a great start but only covers part of the problem.
>> 
>> I think we have 3 outstanding issues that are hampering visibility of 4.0
>> progress:
>> a) Quality testing issues with no shepherd;
>> b) Quality testing issues with shepherd, but no recent activity (~2 months
>> or less);
>> c) Quality testing issues with no objective acceptance criteria/Definition
>> of Done;
> 
> 
> These Quality testing epics are a great focal point.  How will we ensure
> this QA persists, so it's not a manual checklist every release?
> 
> The following is what I can see outstanding for the 4.0 release, that is
> not afaik attached to these epic tickets…
> 
> ** Those issues that slipped alpha…
>*** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming
> and compression in protocol v5-beta
>*** CASSANDRA-15234 – Standardise config and JVM parameters
>*** CASSANDRA-13701 – Lower default num_tokens (blocked by
> 'CASSANDRA-16079 Improve dtest runtime' )
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** 631 jira bug tickets with no assigned "fix version"
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
> ** Reports from driver tests, and other external test systems
> ** Reports and/or integration with Fallout and Harry
> 
> 
> In a bit more detail…
> 
> 
> *** CASSANDRA-15299 – CASSANDRA-13304 follow-up: improve checksumming and
> compression in protocol v5-beta
> 
> This looks like it is in its final patch and review. Is that correct Sam?
> 

Yes it is. I hope to get review finished and post some further perf numbers 
this week.

> 
> *** CASSANDRA-15234 – Standardise config and JVM parameters
> 
> It looks like we have dropped the ball on this.
> 
> 
> *** CASSANDRA-13701 – Lower default num_tokens, and CASSANDRA-16079
> 
> Some effort is undergoing from Ekaterina, David, and myself.
> I've put together a prototype for caching bootstrapped ccm clusters, but
> i'm not yet sure I can get much savings over the current tests and only a
> minimal saving off the 13701 patch. Berenguer brought up that 40% of the
> dtests are single-node, their performance not changed by 13701, and
> probably better off rewritten to in-jvm tests.
> 
> 
> ** 95 jira tickets in 4.0-beta and 4.0-rc
> ** Remaining flakey unit and dtests
> ** Hundreds of failing and flakey upgrade dtests
> 
> Do all remaining flakey and failing units and dtests have jira tickets
> entered for 4.0-beta?
> Has the same been done, at least with rough grouping, for the upgrade tests?
> 
> Are these tied to the testing epics in any way?
> 
> 
> ** 631 jira bug tickets with no assigned "fix version" (who knows how many
> of these are applicable to 4.0?)
> 
> Has any triage efforts happened here?
> Do triaged bugs in this list get moved to fix version "4.x" ?
> Are we duplicating efforts in the testing epics when others have already
> identified and reported the bugs but we just haven't triage them?


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

Changes to JMX metric names in 4.0 beta

[Sam Tunnicliffe]

In CASSANDRA-15299, native protocol V5 is being reworked to incorporate the 
framing format of internode messaging. This is mildly controversial given we're 
well into the beta now and there has been discussion[1] about this previously, 
so I won't rehash that here but I did want to call out another much smaller 
related change I think we need also to make. 

CASSANDRA-15704 (4.0-alpha4) introduced new metrics to track the network 
traffic between clients and servers. I've had cause to touch this code in the 
course of 15299 and IMO there are a couple of issues with the naming of the 
metrics we expose here. 

I'm planning to take care of this as part of 15299, but wanted to flag it on 
list as the existing metric names form part of the published JMX interface. I 
don't imagine this causing too many problems, especially as these metrics are 
all new in 4.0, but changing externally facing stuff at this point is not ideal.

The changes I plan to make are here: 
https://github.com/beobal/cassandra/commit/3cb8cf5366a71b4a00a208716d09b4c9c9bd0544
If nobody objects, I'll go ahead and include this commit when 15299 finishes 
review, which hopefully isn't too far off.

Thanks, 
Sam

[1] 
https://lists.apache.org/thread.html/rb50766fbd1c4b5eeeccbccd10681bf5b6d1c0e7bf7dbb43054609c34%40%3Cdev.cassandra.apache.org%3E


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

[DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sam Tunnicliffe]

CASSANDRA-15299 has revised the wire format of CQL native protocol to add a 
framing layer around the existing CQL messages. This is targetted at protocol 
v5, which is (still) currently in beta. There's a small problem with this 
though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, the new wire 
format is only committed to trunk. This means that if clients upgrade to a 
version of their driver which supports the new wire format (3.10.0 for the java 
driver, python driver is not yet offically released), connections to Cassandra 
3.11.x nodes will break if the client specifies v5-beta as the preferred 
protocol version. 

Of course, any protocol changes that landed in v5-beta have had the potential 
to cause this breakage and in some ways this particular change has a better 
failure mode as it prevents incompatible clients from connecting at all. As we 
have no intention of backporting the new wire format to 3.11.x, and because 
v5-beta has always been characterised as an unsupported, dev-only preview, I'm 
proposing we remove support for it from the 3.11 line. At the same time, we 
should promote v5 from beta and create a new v6-beta for future development 
(CASSANDRA-14973).

If there are no objections, I'll file a JIRA for 3.11.x and post a patch 
shortly.

Thanks,
Sam


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

Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sam Tunnicliffe]

Ye, that would be the alternative. We could finalise v5 as it was prior to the 
new framing format, then create v6-beta in trunk only with the 15299 changes.

> On 8 Dec 2020, at 11:33, Benedict Elliott Smith  wrote:
> 
> Perhaps we should skip v5, and move to v6 for the new protocol to avoid this 
> issue?
> 
> On 08/12/2020, 10:53, "Sam Tunnicliffe"  wrote:
> 
>CASSANDRA-15299 has revised the wire format of CQL native protocol to add 
> a framing layer around the existing CQL messages. This is targetted at 
> protocol v5, which is (still) currently in beta. There's a small problem with 
> this though; while v5-beta is supported in Cassandra 3.11.x and 4.0.0, the 
> new wire format is only committed to trunk. This means that if clients 
> upgrade to a version of their driver which supports the new wire format 
> (3.10.0 for the java driver, python driver is not yet offically released), 
> connections to Cassandra 3.11.x nodes will break if the client specifies 
> v5-beta as the preferred protocol version. 
> 
>Of course, any protocol changes that landed in v5-beta have had the 
> potential to cause this breakage and in some ways this particular change has 
> a better failure mode as it prevents incompatible clients from connecting at 
> all. As we have no intention of backporting the new wire format to 3.11.x, 
> and because v5-beta has always been characterised as an unsupported, dev-only 
> preview, I'm proposing we remove support for it from the 3.11 line. At the 
> same time, we should promote v5 from beta and create a new v6-beta for future 
> development (CASSANDRA-14973).
> 
>If there are no objections, I'll file a JIRA for 3.11.x and post a patch 
> shortly.
> 
>Thanks,
>Sam
> 
> 
>-
>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: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sam Tunnicliffe]

> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti  
> wrote:
> 
> +1 to moving v5-beta changes in trunk to new protocol v6.
> 
> Regarding 3.11 and v5, I suppose we could say, v5 could never get matured
> beyond beta, but not sure if it would be confusing to see v6 while v5 is
> still in beta (curious on others' thoughts as well)
> 
> On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever  wrote:
> 
>>> …move to v6 for the new protocol to avoid this issue
>> 
>> 
>> +1,  feels more the "grown-up thing to do".
>> 
>> 
 Perhaps we should skip v5…
>>> We could finalise v5 as it was prior to the new framing format, then
>> create v6-beta in trunk only with the 15299 changes.
>> 
>> 
>> Would v5 come out of beta then in 3.11?, or would it stay as beta forever,
>> with the focus on maturing v6 in 4.0+?
>> 


Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11. 
That is, the v5 protocol itself would be identical in both C* versions, but 
there would be some considerations on the client side. Namely, if connecting to 
a cluster with any 3.11 nodes, clients would need to set the beta flag in CQL 
frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would simply 
ignore the flag, as it wouldn't be required for v5 connections. So the most 
straightforward path would be probably to promote v5 out of beta in the next 
3.11 and 4.0-beta releases. Clients would just need to ensure that they stay on 
a *current* driver (i.e. one which sets that flag for v5) until after upgrading 
clusters to either the latest 3.11 or 4.0-beta releases. 

I have patches for C*, java and python drivers ready, so I'll file a JIRA and 
open some PRs.






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

Re: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sam Tunnicliffe]

After a little bit of investigation, it turns out that we can't bring v5 out of 
beta in 3.11 as there are already a number of v5 features which 3.11 doesn't 
support. This necessarily couples the C*, protocol and driver versions. For 
instance, java driver 3.0.x is able to support v5 with 3.11, but not with 4.0 
(and the inverse is true of driver 3.10.x). Going back to the genesis of v5 in 
CASSANDRA-10786, this was always the intent:

"v5 beta" will mean different things at different times, and there might be 
errors when an older driver version (supporting "v5 beta with new feature A")   
  connects to a newer C* version (supporting "v5 beta with new features A and 
B"). But with the provision that "bad things can happen when you're in beta" 
that's acceptable, so we don't need to make things any more complicated." [1]

This simplifies things, we promote v5 out of beta in trunk only with no need to 
bump the framing format to v6-beta. If clients currently using v5-beta on 
3.11.x want to upgrade their drivers, they must either revert to v4 or upgrade 
the cluster to 4.0. Because CI uses the same python driver version for all C* 
branches, we'll need to make dtests which require v5 exclusive to 4.0, which 
I'll take care of. Tickets already exist for the python and java drivers 
([2],[3],[4]), but we'll need to bundle a SNAPSHOT java driver with C* 
temporarily for testing. I'll file a 4.0-rc blocker to replace it with a 
release version, as we've done previously.

[1] 
https://issues.apache.org/jira/browse/CASSANDRA-10786?focusedCommentId=15344506&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15344506
[2] https://datastax-oss.atlassian.net/browse/PYTHON-1232
[3] https://datastax-oss.atlassian.net/browse/JAVA-2704
[4] https://datastax-oss.atlassian.net/browse/JAVA-2705


> On 9 Dec 2020, at 11:02, Sam Tunnicliffe  wrote:
> 
> 
> 
>> On 9 Dec 2020, at 02:41, Sumanth Pasupuleti 
>>  wrote:
>> 
>> +1 to moving v5-beta changes in trunk to new protocol v6.
>> 
>> Regarding 3.11 and v5, I suppose we could say, v5 could never get matured
>> beyond beta, but not sure if it would be confusing to see v6 while v5 is
>> still in beta (curious on others' thoughts as well)
>> 
>> On Tue, Dec 8, 2020 at 12:33 PM Mick Semb Wever  wrote:
>> 
>>>> …move to v6 for the new protocol to avoid this issue
>>> 
>>> 
>>> +1,  feels more the "grown-up thing to do".
>>> 
>>> 
>>>>> Perhaps we should skip v5…
>>>> We could finalise v5 as it was prior to the new framing format, then
>>> create v6-beta in trunk only with the 15299 changes.
>>> 
>>> 
>>> Would v5 come out of beta then in 3.11?, or would it stay as beta forever,
>>> with the focus on maturing v6 in 4.0+?
>>> 
> 
> 
> Technically, it *could* come out of beta in 4.0, but stay as it is in 3.11. 
> That is, the v5 protocol itself would be identical in both C* versions, but 
> there would be some considerations on the client side. Namely, if connecting 
> to a cluster with any 3.11 nodes, clients would need to set the beta flag in 
> CQL frame (meaning a frame in v5 terms). Any 4.0 nodes in the cluster would 
> simply ignore the flag, as it wouldn't be required for v5 connections. So the 
> most straightforward path would be probably to promote v5 out of beta in the 
> next 3.11 and 4.0-beta releases. Clients would just need to ensure that they 
> stay on a *current* driver (i.e. one which sets that flag for v5) until after 
> upgrading clusters to either the latest 3.11 or 4.0-beta releases. 
> 
> I have patches for C*, java and python drivers ready, so I'll file a JIRA and 
> open some PRs.
> 
> 
> 
> 
> 
> 
> -
> 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: [DISCUSS] Bringing protocol v5 out of beta and dropping support from 3.11.x

[Sam Tunnicliffe]

> What's the verdict now for CASSANDRA-14973 ?

My aim is to have a C* patch and PRs for the python and java drivers this week, 
but really there's nothing to block cutting a new C* beta now (or whenever 
we're ready).

> On 15 Dec 2020, at 15:39, Mick Semb Wever  wrote:
> 
>> 
>> To use a beta flag, one absolutely has to have matching server
>> and client versions, since otherwise things can break in unexpected ways.
>> In fact, this specific issue makes it easy since you'd see that something
>> has changed immediately.
>> 
> 
> 
> That could certainly deserve better documentation. For example, an extra
> sentence at
> https://github.com/apache/cassandra/blob/trunk/doc/native_protocol_v5.spec#L140-L142
> 
> And it would also be awesome to see this on the website docs. It's a bit of
> tribal knowledge and crawling jira tickets atm.
> 
> I think it can also be made more explicit here by what we mean by "matching
> server and client versions". To my understanding this is not explicit
> versions within V5, as there is only that, but just
> different build/implementation versions. And that this basically also means
> mixed server versions are outside the scope of the beta flag.
> 
> Nit-picking,  "beta" isn't sounding like the most accurate classifier here.
> It sounds to me more like it is "in development", i.e. 'dev', rather than
> beta.
> 
> 
>> +1 to have 4.0 with v5.
> 
> 
> I agree, v6 is not needed. What's the verdict now for CASSANDRA-14973 ?


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

Re: Which fix version should be used for the Quality Testing tickets

[Sam Tunnicliffe]

> On 17 Dec 2020, at 10:54, Michael Semb Wever  wrote:
> 
> 
>> I propose to:
>> 
>>   - update the documentation to clarify the meaning of the fix version as
>>   'The version in which the item must be fixed' (e.g 4.0-beta if the ticket
>>   must be fixed in a beta release)
>>   - create a 4.0-GA fix version and use it for the Quality testing tickets
>>   - Start a discussion beginning of January to discuss the scope of those
>>   tickets
>> 
>> If you disagree on any of the points do not hesitate to raise your concerns
> 
> 
> Even though we have gone ahead and created the `4.0-GA` label, and have 
> already moved the Quality testing tickets to it, I do think we have made a 
> small mistake here…
> 
> What would the difference between `4.0-rc` and `4.0-GA` be?
> 
> If `4.0-beta` is a "Placeholder for blockers to 4.0-rc1",
> then `4.0-rc` would be a "Placeholder for blockers to 4.0.0",
> so then what is `4.0-GA` ?
> 
> This was half-documented in the fixVersion descriptions here
> https://issues.apache.org/jira/projects/CASSANDRA?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> (`4.0-rc` did fail to have any useful description).
> 
> Can I suggest we move all `4.0-GA`  to `4.0-rc`, and delete `4.0-GA` ?
> 

+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 3.11.10

[Sam Tunnicliffe]

+1

> On 29 Jan 2021, at 12:50, 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

[Sam Tunnicliffe]

+1

> On 29 Jan 2021, at 13:21, Oleksandr Petrov  wrote:
> 
>> Proposing the test build of Cassandra 4.0-beta4 for release.
> 
> Correction: test build of 3.0.24. The rest looks right.
> 
> On Fri, Jan 29, 2021 at 1:48 PM 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
>> 
> 
> 
> -- 
> alex p


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

Re: [DISCUSS] Releases after 4.0

[Sam Tunnicliffe]

+1 to both the yearly cadence and the periodic publishing of bleeding edge 
snapshots.

> On 5 Feb 2021, at 16:14, Benedict Elliott Smith  wrote:
> 
> +1
> 
> +1 also to mixing this with an experiment on regular "releasable" (without 
> API stability) snapshots from trunk.
> 
> On 05/02/2021, 16:07, "Joshua McKenzie"  wrote:
> 
>+1 from me on the yearly cadence fwiw. The space this project is in (infra
>software) is directly at odds for many users' preferred release cadence
>(preferably never or bugfix only for existing / stable projects) compared
>to how fast the NoSQL / database ecosystem is evolving; once a year seems
>to strike a reasonable balance between the various constituents.
> 
>On Fri, Feb 5, 2021 at 9:58 AM Benjamin Lerer 
>wrote:
> 
>> Thanks for your responses.
>> 
>> I had some offline discussions with different persons to gather more
>> feedback on the current discussion.
>> The people I talked to appeared to be in favor of one supported release
>> every year as Benedict initially suggested.
>> The advantages mentioned were:
>> * it is long enough to allow us to have a significant amount of work done
>> * if some work slip to the next release it will only be delayed for one
>> year
>> * it does not create too much burden in term of release maintenance
>> * it provides some certainty to the community
>> 
>> I believe that there is an appetite for the bleeding edge snapshots where
>> we do not guarantee stability and that the semver discussion is not
>> finished yet but I would like us to let those discussions go for some
>> follow up threads.
>> My goal with this thread was to reach an agreement on a release cadence for
>> the version we will officially support after 4.0.
>> 
>> My impression is that most people agree with *one release every year* so I
>> would like to propose it as our future release cadence.
>> 
>> Your feedback is welcome.
>> 
>> 
>> On Thu, Jan 28, 2021 at 6:45 PM Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com>
>> wrote:
>> 
>>> I think we are confusing things between minor vs patch.  Can we talk
>> about
>>> branch names?
>>> 
>>> I think we can agree on the following statements?
>>> 
>>> Releases made from stable maintenance branches,
>>> cassandra-3.0/cassandra-3.11/cassandra-4.0 (once created), will limit
>>> features being added to them and should be mostly bug fix only.
>>> 
>>> New features will be developed in trunk.
>>> 
>>> Now I think the thing under discussion here is “how often will we cut new
>>> maintenance branches from trunk” and also “how long will we maintain
>> those
>>> branches"
>>> 
>>> I would definitely like to see the project able to release binaries from
>>> trunk more often then once a year.  As long as we keep our quality goals
>> in
>>> line post 4.0 GA I think this is possible.
>>> 
 I'd like to see us have three branches: life support (critical fixes),
>>> stable (fixes), and development. Minors don't fit very well into that
>> IMO.
>>> 
>>> If we want to go with semver ideas, then minors fit perfectly well.
>>> Server doesn’t meant you make patch releases for every version you have
>>> ever released, it is just a way of versioning the releases so people can
>>> understand what the upgrade semantics are for that release.  If you
>> dropped
>>> support for some existing thing, you need to bump the major version, if
>> you
>>> added something new you bump the minor version, if you only fixed bugs
>> with
>>> no user visible changes you bump the patch version.
>>> 
 I suppose in practice all this wouldn't be too different to tick-tock,
>>> just with a better state of QA, a higher bar to merge and (perhaps) no
>>> fixed release cadence. This realisation makes me less keen on it, for
>> some
>>> reason.
>>> 
>>> I was thinking something along these lines might be useful as well.
>>> 
>>> I could see a process where we cut new maintenance branches every X time,
>>> ~1 year?, 6 months?, we would fix bugs and make patch releases from those
>>> maintenance branches.
>>> We would also cut releases from the development branch (trunk) more
>>> often.  The version number in trunk would be updated based on what had
>>> changed since the last release made from trunk.  If we dropped support
>> for
>>> something since the last release, bump major.  If we added new features
>>> (most likely thing), bump minor.
>>> 
>>> So when we release 4.0 we cut the cassandra-4.0 maintenance branch.  We
>>> make future 4.0.1 4.0.2 4.0.3 releases from this branch.
>>> 
>>> Trunk continues development, some new features are added there.  After a
>>> few months we release 4.1.0 from trunk, we do not cut a cassandra-4.1
>>> branch.  Development continues along on trunk, some new features get in
>> so
>>> we bump the version in the branch to 4.2.0.  A few months go by we
>> release
>>> 4.2.0 from trunk.  Some bug fixes go into trunk with no new features, the
>>> version on the branch bumps to 4.2.1, we decide to make a release from
>>> 

Reconciling expiring cells and tombstones

[Sam Klock]

Hi folks,

I have a question about a design choice on how expiring cells are
reconciled with tombstones.  For two cells with the same timestamp, if
one is expiring and one is a tombstone, Cassandra *always* prefers the
tombstone.  This matches its behavior for normal/non-expiring cells, but
the folks in my organization worry about what it may imply for nodes
experiencing clock skew.  Specifically, we're concerned about scenarios
like the following:

1) An expiring cell is committed via some node with a non-skewed clock.
2) Another replica for that cell experiences forward clock skew and
decides that the cell is expired.  It eventually runs a compaction that
converts the cell to a tombstone.
3) The tombstone propagates to other nodes via, e.g., node repair.
4) The other nodes all eventually run their own compactions.  Because of
the reconciliation logic, the expiring cell is purged on all of the
replicas, leaving behind only the tombstone.

If the cell should have still been live at (4), the reconciliation logic
will result in it being prematurely purged.  We have confirmed this
behavior experimentally.

My organization may be more concerned about clock skew than the larger
community, so I don't think we're inclined to propose a patch at this
time.  But to account for this kind of scenario we would like to patch
our internal version of Cassandra to conditionally prefer expiring cells
to tombstones if the node believes they should still be live; i.e., in
reconcile() in *ExpiringCell.java, instead of:

if (cell instanceof DeletedCell)
return cell;

use:

if (cell instanceof DeletedCell)
return isLive() ? this : cell;

Before we do so, however, we'd like to understand the rationale for the
existing behavior and the risks of making changes to it.  Why does
Cassandra consistently prefer tombstones to other kinds of cells?  By
modifying this behavior in this particular case, do we risk hitting
bizarre corner cases?

Thanks,
SK

Re: Reconciling expiring cells and tombstones

[Sam Klock]

Thanks Tyler.  Sounds like the risk of making this change is tolerable
for us.

Josef: thanks for the links.  We're thinking carefully about our NTP
configuration, but we also would like to account for unusual failure
modes (e.g., nodes with fast clocks experiencing partitions from NTP
servers/peers).  Making sure Cassandra's internals are arranged to
minimize the damage when these things happen is part of our strategy.

Thanks,
SK

On 06/17/2015 11:17 AM, Tyler Hobbs wrote:
>>
>> Why does Cassandra consistently prefer tombstones to other kinds of cells?
>>
> 
> It's primarily to have deterministic conflict resolution.  I don't recall
> any specific conversations about preferring tombstones expiring cells, and
> the original ticket (https://issues.apache.org/jira/browse/CASSANDRA-699)
> doesn't mention anything.
> 
> By modifying this behavior in this particular case, do we risk hitting
>> bizarre corner cases?
>>
> 
> I think this would be safe.  The only problem I can think of would happen
> while your cluster has some patched nodes and some unpatched nodes.  If you
> had any nodes that had both an expiring cell and a tombstone with the same
> timestamp, then patched replicas would return different results/digests
> than the unpatched nodes.  However, unless you're mixing TTLs with deletes,
> that's not too likely to happen.  Maybe repair combined with clock skew
> could result in that, but not much else.
> 
> 
> On Wed, Jun 17, 2015 at 10:05 AM, Josef Lindman Hörnlund 
> wrote:
> 
>>
>> Hello Sam,
>>
>> This is not answering your direct question but if you worry about clock
>> skew take a look at this great two-part blogpost:
>>
>>
>> https://blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-1-the-problem/
>> <
>> https://blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-1-the-problem/
>>>
>>
>> https://blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-2-solutions/
>> <
>> https://blog.logentries.com/2014/03/synchronizing-clocks-in-a-cassandra-cluster-pt-2-solutions/
>>>
>>
>>
>> Josef Lindman Hörnlund
>> Chief Data Scientist
>> AppData
>> jo...@appdata.biz
>>
>>
>>
>>
>>> On 16 Jun 2015, at 20:45, Sam Klock  wrote:
>>>
>>> Hi folks,
>>>
>>> I have a question about a design choice on how expiring cells are
>>> reconciled with tombstones.  For two cells with the same timestamp, if
>>> one is expiring and one is a tombstone, Cassandra *always* prefers the
>>> tombstone.  This matches its behavior for normal/non-expiring cells, but
>>> the folks in my organization worry about what it may imply for nodes
>>> experiencing clock skew.  Specifically, we're concerned about scenarios
>>> like the following:
>>>
>>> 1) An expiring cell is committed via some node with a non-skewed clock.
>>> 2) Another replica for that cell experiences forward clock skew and
>>> decides that the cell is expired.  It eventually runs a compaction that
>>> converts the cell to a tombstone.
>>> 3) The tombstone propagates to other nodes via, e.g., node repair.
>>> 4) The other nodes all eventually run their own compactions.  Because of
>>> the reconciliation logic, the expiring cell is purged on all of the
>>> replicas, leaving behind only the tombstone.
>>>
>>> If the cell should have still been live at (4), the reconciliation logic
>>> will result in it being prematurely purged.  We have confirmed this
>>> behavior experimentally.
>>>
>>> My organization may be more concerned about clock skew than the larger
>>> community, so I don't think we're inclined to propose a patch at this
>>> time.  But to account for this kind of scenario we would like to patch
>>> our internal version of Cassandra to conditionally prefer expiring cells
>>> to tombstones if the node believes they should still be live; i.e., in
>>> reconcile() in *ExpiringCell.java, instead of:
>>>
>>>if (cell instanceof DeletedCell)
>>>return cell;
>>>
>>> use:
>>>
>>>if (cell instanceof DeletedCell)
>>>return isLive() ? this : cell;
>>>
>>> Before we do so, however, we'd like to understand the rationale for the
>>> existing behavior and the risks of making changes to it.  Why does
>>> Cassandra consistently prefer tombstones to other kinds of cells?  By
>>> modifying this behavior in this particular case, do we risk hitting
>>> bizarre corner cases?
>>>
>>> Thanks,
>>> SK
>>
>>
> 
> 

Re: Discussion: reviewing larger tickets

[Sam Tunnicliffe]

I'm +1 with Sylvain here; keeping the discussions open, accessible to all
and persistent seems more valuable than reducing the friction for
contributors & reviewers.

Personally, my workflow involves following the JIRA firehose, so I tend to
be aware (at least to some degree) of both "major" & "minor" comments, a
lot of which I would surely miss were they to move GH. I also agree with
the point that what seems minor to one viewer may raise red flags with
another.

That said, I often have offline conversations (from both the
reviewer/contributor perspective) around minor-ish things like naming, nits
and so forth. At the moment these are a) not recorded & b) marginally more
difficult to do asynchronously. So I think in future I may personally start
using a GH branch for such remarks, though I don't think that should become
a mandated part of The Process.

Sam

On Thu, Jul 9, 2015 at 11:47 AM, Sylvain Lebresne 
wrote:

> > One downside to that approach is that the extra barrier to entry makes it
> > more of a 1-on-1 conversation rather than an open discussion via JIRA
> > comments.
>
> Yes, and I really worry about that. And I (see the "I", that's a totally
> personal opinion) value keeping discussions as open as possible much more
> than
> additional convenience for making and processing review comments. I'll
> admit
> however that the current use of JIRA comments for reviews has never burden
> me
> all that much so I don't see all that much convenience to be gained by
> changing
> that process (but then again, I'm happy using vim for my development, so
> your
> mileage probably varies).
>
> Typically, if we talk of work-flow, I personally read JIRA updates fairly
> religiously, which allows me to keep vaguely up to date on what's going on
> with
> reviews even for tickets I'm a priori not involved with. I consider it a
> good,
> healthy thing. If we move some of the review material outside of JIRA, I
> strongly suspect this won't be the case anymore due to the burden of having
> to
> check multiple places.
>
> Anyway, I worry a bit that changing for what I perceive as relatively minor
> convenience will make us lose more than we get. Just my 2 cents however
> really.
>
> --
> Sylvain
>
> On Wed, Jul 8, 2015 at 11:21 PM, Michael Shuler 
> wrote:
>
> > When we set up autojobs for the dev branches, I did some digging around
> > the jenkins / githubPR integration, similar to what spark is doing. I'd
> be
> > completely on board with working through that setup, if it helps this
> > workflow.
> >
> > Michael
> >
> >
> > On 07/08/2015 03:02 PM, Carl Yeksigian wrote:
> >
> >> Spark has been using the GitHub PRs successfully; they have an
> additional
> >> mailing list which contains updates from GitHub (
> >> http://mail-archives.apache.org/mod_mbox/spark-reviews/), and they also
> >> have their PRs linked to JIRA so that going from the ticket to the PR is
> >> easily done.
> >>
> >> If we are going to start using GitHub PRs to conduct reviews, we should
> >> follow similar contribution guidelines to what Spark has (
> >>
> >>
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-PullRequest
> >> <
> https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark
> >> >),
> >> and have Infra set up the same hooks for our repo. We can also hook up
> >> cassci to do the same jobs as the AmplabJenkins performs currently.
> >>
> >>
> >> On Wed, Jul 8, 2015 at 3:21 PM, Josh McKenzie 
> >> wrote:
> >>
> >>  As some of you might have noticed, Tyler and I tossed around a couple
> of
> >>> thoughts yesterday regarding the best way to perform larger reviews on
> >>> JIRA.
> >>>
> >>> I've been leaning towards the approach Benedict's been taking lately
> >>> w/putting comments inline on a branch for the initial author to inspect
> >>> as
> >>> that provides immediate locality for a reviewer to write down their
> >>> thoughts and the same for the initial developer to ingest them. One
> >>> downside to that approach is that the extra barrier to entry makes it
> >>> more
> >>> of a 1-on-1 conversation rather than an open discussion via JIRA
> >>> comments.
> >>> Also, if one deletes branches from github we then lose our discussion
> >>> history on the review process which is a big problem for digging into
> why
> >>&g

Re: [VOTE] Release Apache Cassandra 3.0.0-beta1

[Sam Tunnicliffe]

+1

On Sat, 22 Aug 2015 04:15 Jake Luciani  wrote:

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

Re: [VOTE] Release Apache Cassandra 3.0.0-rc1

[Sam Tunnicliffe]

+1
On 19 Sep 2015 21:42, "Jake Luciani"  wrote:

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

Re: [VOTE] Release Apache Cassandra 3.1

[Sam Tunnicliffe]

+1
On 4 Dec 2015 22:07, "Jake Luciani"  wrote:

> I propose the following artifacts for release as 3.1.
>
> sha1: e092873728dc88aebc6ee10153b9bd3cd90cd858
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.1-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1093/org/apache/cassandra/apache-cassandra/3.1/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1093/
>
> 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/HET4Bi (CHANGES.txt)
> [2]:  http://goo.gl/LVqJJo (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 3.0.1

[Sam Tunnicliffe]

+1
I propose the following artifacts for release as 3.0.1.

sha1: cf567703db2cc6859731405322f19f55345b5c57
Git:
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.1-tentative
Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1092/org/apache/cassandra/apache-cassandra/3.0.1/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1092/

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/fJaAjI (CHANGES.txt)
[2]: http://goo.gl/DgSi87 (NEWS.txt)

Re: [VOTE] Release Apache Cassandra 3.2

[Sam Tunnicliffe]

+1

On Fri, Jan 8, 2016 at 9:12 PM, Jake Luciani  wrote:

> I propose the following artifacts for release as 3.2.
>
> sha1: 3c6dfa4aa0b9ffb0a48a02b949bff2a8406764e6
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1096/org/apache/cassandra/apache-cassandra/3.2/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1096/
>
> 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/T8geYN (CHANGES.txt)
> [2]: http://goo.gl/VDwYyf (NEWS.txt)
>

Re: [VOTE] Release Apache Cassandra 3.2.1

[Sam Tunnicliffe]

+1

On Fri, Jan 15, 2016 at 3:03 AM, Jake Luciani  wrote:

> I propose the following artifacts for release as 3.2.1.
>
> sha1: 2ac95bd6c5699a605e6f4256cb17b016c99e6dda
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.2.1-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1097/org/apache/cassandra/apache-cassandra/3.2.1/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1097/
>
> The artifacts as well as the debian package are also available here:
> http://people.apache.org/~jake
>
> The vote will be open for 24 hours (longer if needed).
>
> [1]: http://goo.gl/WG3TEx (CHANGES.txt)
> [2]: http://goo.gl/z7OsrE (NEWS.txt)
> [3]: https://goo.gl/MLo2Kg (DataStax Test Report)
>

Re: [VOTE] Release Apache Cassandra 2.1.13

[Sam Tunnicliffe]

+1

On Wed, Feb 3, 2016 at 1:44 PM, Jake Luciani  wrote:

> I propose the following artifacts for release as 2.1.13.
>
> sha1: d5b6d1b634f69709d2b3caa17cba52696ed2033d
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.1.13-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1098/org/apache/cassandra/apache-cassandra/2.1.13/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1098/
>
> 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/ldbtfT (CHANGES.txt)
> [2]: http://goo.gl/yToJdI (NEWS.txt)
> [3]: https://goo.gl/eWXZLZ (DataStax Test Report)
>

Re: [VOTE] Release Apache Cassandra 2.2.5

[Sam Tunnicliffe]

+1

On Wed, Feb 3, 2016 at 1:51 PM, Jake Luciani  wrote:

> I propose the following artifacts for release as 2.2.5.
>
> sha1: dd76858c7652541c7b137323f7b9e154686d6fba
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.5-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1099/org/apache/cassandra/apache-cassandra/2.2.5/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1099/
>
> 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/GVE9VN (CHANGES.txt)
> [2]: http://goo.gl/kbrReO (NEWS.txt)
> [3]: https://goo.gl/QCHBW3 (DataStax Test Report)
>

Re: [VOTE] Release Apache Cassandra 3.3

[Sam Tunnicliffe]

+1

On Sat, Feb 6, 2016 at 3:11 AM, Jake Luciani  wrote:

> I propose the following artifacts for release as 3.3.
>
> sha1: 5669c6967bbdd540f27aeebf5a2c258bc4defbe3
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.3-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1101/org/apache/cassandra/apache-cassandra/3.3/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1101/
>
> 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/1nZIdi (CHANGES.txt)
> [2]: http://goo.gl/a1UT2s (NEWS.txt)
> [3]: https://goo.gl/aYBtW1 (DataStax Test Report)
>

Re: Custom Java class for secondary index implementation

[Sam Tunnicliffe]

You might find o.a.c.i.StubIndex in the test source tree useful.
On 6 Mar 2016 19:24, "Henry Manasseh"  wrote:

> Hello,
> I was wondering if anyone is aware of a minimal reference implementation
> for a java class implementing a secondary index or some documentation of
> the interface(s) I would need to implement (I looked at the SASI 2i code
> but I am trying to find the bare bones test or sample class for a newbie if
> it exists).
>
> e.g. I am referring to the class you would use for
> 'path.to.the.IndexClass'.
>
> CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
> >
>
>
> I am trying to understand if it is possible to index a UDT collection based
> on only one field of the UDT and still use the cassandra index file
> management (I don't want to provide my own file storage). In other words, I
> am looking to see if the custom index class can serve as a transformation
> function to only index my subfield. This probably will need a tweak to the
> CQL to prevent a syntax error but not concerned about that at the moment.
>
> Thank you for any helps and tips,
> Henry
>

Re: TTL rows with 2i

[Sam Tunnicliffe]

The problem with row level ttls in this regard is that the scope of a
particular compaction may not include all versions of a given row. So just
because a primary key liveness denoting an expired row may be written to
the new SSTable, it doesn't necessarily mean that an index should purge its
entry/entries for that row. That said, it should probably be the
responsibility of the index implementation to manage that, but at the
moment the {{onPrimaryKeyLivenessInfo}} event during compaction doesn't
cause the registered indexes to be notified. I've opened
https://issues.apache.org/jira/browse/CASSANDRA-11329 for this.


On Wed, Mar 9, 2016 at 4:05 PM, Eduardo Alonso 
wrote:

> Hi,
>
> We have been investigating how to include in our 2i implementation the
> ability to index TTL expirable Cells in Cassandra 3.x.
>
> Reading comments in o.a.c.index.Index.Indexer.removeRows it seems that this
> method is called when a compaction detects that a cell has expired.
>
> I dont know if this is correct, so the question is:
>
> How does the non-columnFamily based 2i get notified when a row ttl has
> expired?
>
> I have checked the only two calls to Indexer.removeRows in
> o.a.c.index.SecondaryIndexManager.IndexGCTransaction.commit in the
> followings releases and it seems that has not changed at all.
>
> Sam Tunnicliffe, any ideas about this??
>
> Regards
>
>
> Eduardo Alonso
> Vía de las dos Castillas, 33, Ática 4, 3ª Planta
> 28224 Pozuelo de Alarcón, Madrid
> Tel: +34 91 828 6473 // www.stratio.com // *@stratiobd
> <https://twitter.com/StratioBD>*
>

Re: [VOTE] Release Apache Cassandra 3.0.6

[Sam Tunnicliffe]

+1

On Wed, May 11, 2016 at 9:51 AM, Aleksey Yeschenko 
wrote:

> +1
>
> --
> AY
>
> On 11 May 2016 at 02:55:11, Jake Luciani (j...@apache.org) wrote:
>
> I propose the following artifacts for release as 3.0.6.
>
> sha1: 52447873a361647a5e80c547adea9cf5ee85254a
> Git:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.6-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1110/org/apache/cassandra/apache-cassandra/3.0.6/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1110/
>
> 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/IiNyVb (CHANGES.txt)
> [2]: http://goo.gl/ZAr03L (NEWS.txt)
> [3]: https://goo.gl/2jPtss (DataStax QA Report)
>