incrementally acquiring tokens

I've been thinking a bit about the problem of fat nodes (say, 20gb per node). My understanding is that the amount of overhead of adding a new node into the ring is massive with fat nodes due to the fact that you have to stream in 20TB which takes forever. In a scenario where a given node only

Re: 3.0 and the Cassandra release process

If every other release is a bug fix release, would the versioning go: 3.1.0 -- feature release 3.1.1 -- bug fix release Eventually it seems like it might be possible to be able to push out a bug fix release more frequently than once a month? On Wed, Mar 18, 2015 at 7:59 AM Josh McKenzie

Re: 3.0 and the Cassandra release process

In this tick tock cycle, is there still a long term release that's maintained, meant for production? Will bug fixes be back ported to 3.0 (stable) with new stuff going forward to 3.x? On Thu, Mar 26, 2015 at 6:50 AM Aleksey Yeschenko alek...@apache.org wrote: Hey Jason. I think pretty much

Re: DateTieredCompactionStrategy and static columns

it be to have a separate memtable/sstable for static columns? Begin forwarded message: *From: *Jonathan Haddad j...@jonhaddad.com *Subject: **Re: DateTieredCompactionStrategy and static columns* *Date: *April 30, 2015 at 3:55:46 PM CDT *To: *u...@cassandra.apache.org *Reply-To: *u

Re: DateTieredCompactionStrategy and static columns

That said, in every interaction I’ve had with static columns, they seem to be an odd duck (e.g. adding or complicating range slices), perhaps worthy of their own code path and sstables. Just food for thought. On Apr 30, 2015, at 7:13 PM, Jonathan Haddad j...@jonhaddad.com wrote: If you want

Re: NewBie Question

Maybe some brave soul will document the 3.0 on disk format as part of https://issues.apache.org/jira/browse/CASSANDRA-8700. On Wed, Jun 15, 2016 at 7:02 AM Christopher Bradford wrote: > Consider taking a look at Aaron Morton's dive into the C* 3.0 storage > engine. > > >

Re: NewBie Question

ld be in > user > > level docs. Let's keep it in the wiki for contributors. > >> On Jun 15, 2016 7:04 PM, "Jonathan Haddad" <j...@jonhaddad.com> wrote: > >> > >> Definitely required reading for anyone getting into it, plus Aaron's > post. > >>

Re: [Proposal] Mandatory comments

I've been discouraged from contributing to the codebase due to it's lack of comments, so I +1 this big time. Some people argue against comments by saying "the code should be self describing", but that misses the point. The comments should describe the *intent* of the code, the problem it's mean

Re: A proposal to move away from Jira-centric development

I don't know about everyone else, but a big deterrent in contributing code to Cassandra for me (over the last 4 years or so) is the massive amount of ramp up that needs to happen in order to get started working on something meaningful. This comes in a variety of forms - understanding how test

Re: A proposal to move away from Jira-centric development

(non binding) +1 On Mon, Aug 15, 2016 at 7:23 AM Jonathan Ellis wrote: > A long time ago, I was a proponent of keeping most development discussions > on Jira, where tickets can be self contained and the threadless nature > helps keep discussions from getting sidetracked. > >

Re: Performance issue in 3.0.9

Also, if you have been tracking your performance metrics in graph form (before and after the upgrade), that would be extremely helpful. On Thu, Feb 2, 2017 at 5:29 AM Romain Hardouin wrote: > Yes you should provide more context."Lots of timeouts": read? write? >

Re: Any idea when 3.0.11 will be released?

You can't go by the DSE version. Datastax backports patches all the time. It's possible they shipped whatever is in trunk, or backported something that hasn't been released yet. Or did a fix that's not even in OSS yet. On Thu, Jan 26, 2017 at 5:49 AM Matija Gobec wrote: >

Re: New committers announcement

Congratulations! Definitely a lot of great contributions from everyone on the list. On Tue, Feb 14, 2017 at 1:31 PM Jason Brown wrote: > Hello all, > > It's raining new committers here in Apache Cassandra! I'd like to announce > the following individuals are now committers

Re: Proposal - 3.5.1

. The follow up to 3.4 (3.5) should have been 3.4.1, following semver, so people know it's bug fixes only to 3.4. Jon On Wed, Sep 14, 2016 at 10:37 PM Jonathan Haddad <j...@jonhaddad.com> wrote: > In this particular case, I'd say adding a bug fix release for every > version that's af

Proposal - 3.5.1

Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported to 3.5 as well, and it makes Cassandra effectively unusable if someone is using any of the 4 types affected in any of their schema. I have cherry picked & merged the patch back to here and will put it in a JIRA as well

Re: Proposal - 3.5.1

- Jeff > > > > > > > > > On 9/15/16, 10:31 AM, "dave_les...@apple.com on behalf of Dave > Lester" < > > > dave_les...@apple.com> wrote: > > > > > > >How would cutting a 3.5.1 release possibly confuse users of the > > so

Re: Proposal - 3.5.1

If the releases can be tagged as alpha / beta so that people don't accidentally put it in prod (or at least, will do so less), that would be totally reasonable. On Thu, Sep 15, 2016 at 12:27 PM Tyler Hobbs wrote: > On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith < >

Re: cassandra-3.9 (and 3.8) release

(non-binding) -1 on releasing 2 versions with the same version number. Everything that's been communicated to the world has been that there would be a feature release, then a bug fix release a month later. This breaks that promise. On Fri, Sep 23, 2016 at 4:23 PM Michael Shuler

Re: Proposal - 3.5.1

> > On 09/14/2016 08:30 PM, Jonathan Haddad wrote: > > Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back ported to > > 3.5 as well, and it makes Cassandra effectively unusable if someone is > > using any of the 4 types affected in any of their schema. > >

Re: Proposal - 3.5.1

@Sylvain - I see what you're saying now on the branches. I suppose a branching strategy like that does give some flexibility to have multiple things in the pipeline so it does give some additional flexibility there. On Mon, Sep 19, 2016 at 9:06 AM Eric Evans wrote:

Re: Proposal - 3.5.1

I've worked on a few projects where we've had a branch that new stuff went in before merging to master / trunk. What you've described reminds me a lot of git-flow (http://nvie.com/posts/a-successful-git-branching-model/) although not quite the same. I'll be verbose in this email to minimize the

Re: Proposal - 3.5.1

of the project will increase - which was the original goal of Tick Tock. Jon On Fri, Sep 16, 2016 at 9:04 AM Sylvain Lebresne <sylv...@datastax.com> wrote: > On Fri, Sep 16, 2016 at 5:18 PM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > > > This is a different

Re: Proposal - 3.5.1

Jonathan Ellis <jbel...@gmail.com> wrote: > On Fri, Sep 16, 2016 at 11:36 AM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > What I was trying to suggest is that the *goal* of trunk should always be > > releasable, and the alpha releases would be the means o

Re: Github pull requests

+1 to officially supporting GitHub PRs. On Fri, Aug 26, 2016 at 11:07 AM Jason Brown wrote: > It seems to me we might get more contributions if we can lower the barrier > to participation. (see Jeff Beck's statement above) > > +1 to Aleksey's sentiment about the Docs

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

roject = CASSANDRA AND created >= -24h ORDER BY createdDate DESC > > When viewing your filter, go to Details > New Subscription and set it up to > run once a day and you're set! > > Hope it helps, > > Russ > > On Mon, Aug 29, 2016 at 10:45 AM, Jonathan Haddad <j...@jonh

Re: Proposal: create a mailing list for just the newly created Jira ticket notifications

A daily digest of new issues would be incredible. A non-binding +1 from this guy. On Mon, Aug 29, 2016 at 8:58 AM Jeremy Hanna wrote: > Currently we have a mailing list (commits@) that includes commit messages > as well as all updates to Jira tickets. However for

Re: Rough roadmap for 4.0

epaxos would be nice, it's been about 2 years since it was started, and Blake asked for a first review well over a year ago. the benchmarks and thorough test suite look like a huge improvement over the current situation. https://issues.apache.org/jira/browse/CASSANDRA-6246 On Fri, Nov 4, 2016

Re: Moderation

I took a look at https://www.apache.org/dev/pmc.html, and it doesn't seem to give any guidelines on who should be on the PMC. My assumption has always been the most active committers become PMC members, but it sounds like that's not the case on other projects. Is the process to be added to the

Re: Moderation

I agree with Paul. Same boat, not a PMC / Datastax, just someone that cares a lot about this community. On Sat, Nov 5, 2016 at 3:04 PM paul cannon wrote: > I'm not a stakeholder here- I don't know Russell, I don't work for > Datastax, and I'm not a member of the ASF. > > For

Re: Low hanging fruit crew

ith > > >> >> > > >> >> 1. Efficiency. Is there a quadratic loop that will blow up when > the > > >> number > > >> >> of nodes in a cluster gets large? Is there a linear amount of > memory > > >> used > > >

Re: Proposal - 3.5.1

And +1 to ditching the "tick tock" alternating release thing nobody understands it anyway. On Thu, Oct 20, 2016 at 3:38 PM Jonathan Haddad <j...@jonhaddad.com> wrote: > From a community perspective a supported release every 6 months would be > much more attractive than yea

Re: Proposal - 3.5.1

>From a community perspective a supported release every 6 months would be much more attractive than yearly, as having to wait ~9-10 months for something like SASI is kind of frustrating. Monthly dev releases is awesome. On Thu, Oct 20, 2016 at 3:18 PM Nate McCall wrote: > >

Re: Low hanging fruit crew

Shouldn't the tests test the code for correctness? On Wed, Oct 19, 2016 at 8:34 AM Jonathan Ellis wrote: > On Wed, Oct 19, 2016 at 8:27 AM, Benjamin Lerer < > benjamin.le...@datastax.com > > wrote: > > > Having the test passing does not mean that a patch is fine. Which is why

Re: [VOTE] Release Apache Cassandra 3.10 (Take 3)

-1 (non-binding) for the failing tests as well. On Fri, Nov 25, 2016 at 10:35 AM Sam Tunnicliffe wrote: > I'll register another (non-binding) -1 due to the failing tests. In > particular, CASSANDRA-12651 is due to a legit bug with potential corruption > and data loss (albeit in

Re: Proposals for releases - 4.0 and beyond

+1 as well On Mon, Nov 21, 2016 at 10:59 AM kurt Greaves wrote: > yep +1 to this. The LTS release solves my previous concern >

Re: Failed Dtest will block cutting releases

+1. Kind of silly to put advise people to put something in prod which is known to be broken in obvious ways On Mon, Nov 21, 2016 at 11:31 AM sankalp kohli wrote: > Hi, > We should not cut a releases if Dtest are not passing. I won't block > 3.10 on this since we are

Re: Rough roadmap for 4.0

I think it might be worth considering adopting the release strategy before 4.0 release. Are any PMC members putting tick tock in prod? Does anyone even trust it? What's the downside of changing the release cycle independently from 4.0? On Thu, Nov 17, 2016 at 9:03 AM Jason Brown

Re: Bootstrapping data from Cassandra 2.2.5 datacenter to 3.0.8 datacenter fails because of streaming errors

You can't stream between major versions. Don't tear down your first data center, upgrade it instead. On Mon, Oct 10, 2016 at 4:35 PM Abhishek Verma wrote: > Hi Cassandra users, > > We are trying to upgrade our Cassandra version from 2.2.5 to 3.0.8 > (running on Mesos, but that's

Re: Collecting slow queries

Love the slow query log, very nice that got done. I've created some follow up JIRAs I intend to contribute: CASSANDRA-13000 - slow query log analysis (basically mysqldumpslow) CASSANDRA-13001 - pluggable slow query handling CASSANDRA-13002 - per table slow query threshold Jon On Tue, Dec 6,

Re: Wrapping up tick-tock

ocusing to stabilize > 3.x > > > first? Who knows how long that would take, even if everyone would > > > exclusively work on bug fixing (which I think should happen). > > > > > > On Tue, Jan 10, 2017 at 4:29 PM, Jonathan Haddad <j...@jonhaddad.com> >

Re: [VOTE] 3.X branch feature freeze

+1 (non binding) to feature freeze. I also like the idea of stabilizing MVs. Ben, you've probably been the most vocal about the issues, have you made any progress towards making them work any better during bootstrap / etc? Any idea of fixing them is a major undertaking? Jon On Fri, Jan 13,

Re: Rollback procedure for Cassandra Upgrade.

There's no downgrade procedure. You either upgrade or you go back to a snapshot from the previous version. On Mon, Jan 9, 2017 at 8:13 PM Prakash Chauhan wrote: > Hi All , > > Do we have an official procedure to rollback the upgrade of C* from 2.0.x > to 2.1.x ? > >

Re: Wrapping up tick-tock

I don't see why it has to be one extreme (yearly) or another (monthly). When you had originally proposed Tick Tock, you wrote: "The primary goal is to improve release quality. Our current major “dot zero” releases require another five or six months to make them stable enough for production.

splitting CQL parser & spec into separate repo

I created CASSANDRA-13284 a few days ago with the intent of starting a discussion around the topic of breaking the CQL parser out into a separate project. I see a few benefits to doing it and was wondering what the folks here thought as well. First off, the Java CQL parser would obviously

Re: [VOTE] self-assignment of jira tickets

Non binding +1 On Wed, Mar 29, 2017 at 7:22 AM Jeff Jirsa wrote: > +1 > > -- > Jeff Jirsa > > > > On Mar 29, 2017, at 6:21 AM, Jason Brown wrote: > > > > Hey all, > > > > Following up my thread from a week or two ago ( > > >

Re: Can we kill the wiki?

possible, we should at > least > > put a note on there saying it is deprecated and point people to the new > > docs. > > > > On 18 March 2017 at 08:09, Jonathan Haddad <j...@jonhaddad.com > > <javascript:;>> wrote: > > > > > +1 to killing th

Re: Can we kill the wiki?

+1 to killing the wiki. On Fri, Mar 17, 2017 at 2:08 PM Blake Eggleston wrote: > With CASSANDRA-8700, docs were moved in tree, with the intention that they > would replace the wiki. However, it looks like we’re still getting regular > requests to edit the wiki. It seems

Re: Code quality, principles and rules

I'd like to think that if someone refactors existing code, making it more testable (with tests, of course) it should be acceptable on it's own merit. In fact, in my opinion it sometimes makes more sense to do these types of refactorings for the sole purpose of improving stability and testability

Re: [VOTE] Ask Infra to move github notification emails to commits@

+1 On Mon, Mar 20, 2017 at 3:02 PM Brandon Williams wrote: > +1, we've had to explain this a thousand times here. > > On Mon, Mar 20, 2017 at 5:00 PM, Jeff Jirsa wrote: > > > There's no reason for the dev list to get spammed everytime there's a > > github

Re: [VOTE] Ask Infra to move github notification emails to pr@

+1 On Mon, Mar 20, 2017 at 6:33 PM Jason Brown wrote: > +1 > On Mon, Mar 20, 2017 at 18:21 Anthony Grasso > wrote: > > > +1 > > > > On 21 March 2017 at 09:32, Jeff Jirsa wrote: > > > > > There's no reason for the dev list to get

Re: Testing and jira tickets

e all know if you're gonna make a typo, > > it's going to be in the commit, and it's probably going to be the ticket > > number.) > > > > On Thu, Mar 9, 2017 at 1:00 PM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > > > > If you don't mind, I

Re: Testing and jira tickets

If you don't mind, I'd like to broaden the discussion a little bit to also discuss performance related patches. For instance, CASSANDRA-13271 was a performance / optimization related patch that included *zero* information on if there was any perf improvement or a regression as a result of the

committing performance patches without performance numbers

I'd like to discuss what I consider to be a pretty important matter - patches which are written for the sole purpose of improving performance without including a single performance benchmark in the JIRA. My original email was in "Testing and Jira Tickets", i'll copy it here for posterity: If you

Re: committing performance patches without performance numbers

/dtest workflow for ALL > > patches so we could quickly spot regressions, but that gets pretty > > expensive in terms of running long enough tests to actually see most > > common > > code paths. > > > > > > On Thu, Mar 9, 2017 at 12:00 PM, Jonathan Hadd

Re: Contribute to the Cassandra wiki

Ugh... Let's put a few facts out in the open before we start pushing to move back to the wiki. First off, take a look at CASSANDRA-8700. There's plenty of reasoning for why the docs are now located in tree. The TL;DR is: 1. Nobody used the wiki. Like, ever. A handful of edits per year. 2.

Re: Integrating vendor-specific code and developing plugins

There's a handful of issues I can think of with shipping everything in-tree. I'll try to brain dump them here. * What's included when shipped in tree? Does every idea get merged in? Do we need 30 different Seed providers? Who judges what's valuable enough to add? Who maintains it when it

rebuilding cassandra.apache.org docs

Looks like the docs haven't been rebuilt in a while. There's a handful of useful merges recently that I'm aware of that would be great to see on there. How do they get rebuilt? Who can trigger it? Jon

Re: Integrating vendor-specific code and developing plugins

In accordance with the idea that the codebase should be better tested, it seems to me like things shouldn't be added that aren't testable. If there's a million unit tests that are insanely comprehensive but for some reason can never be run, they serve exactly the same value as no tests. It may

Re: NGCC Proposal (Was Re: NGCC?)

Agreed with Jeff & Jason. On Tue, Jun 13, 2017 at 11:45 AM Jeff Jirsa wrote: > Looks great to me - especially the venue. Date wise, Tuesday (19th) lets > people fly in on Monday instead of costing a weekend, so selfishly that > seems better to me. > > > > On Mon, Jun 12, 2017

Re: Guidelines on testing

+1 On Tue, Apr 25, 2017 at 2:21 AM Stefan Podkowinski wrote: > I don't see any reasons not to make this part of our guidelines. The > idea of having a list of what should be tested in each kind of test > makes sense. I also like the examples how to improve tests dealing with >

Re: NGCC?

+1. Are there guidelines for how to set something like this up or is it tribal knowledge? On Wed, May 31, 2017 at 3:05 PM Gary Dusbabek wrote: > +1. I'm happy to help with logistics. > > Mid-to-late September is good, but so is October. > > Gary. > > On Wed, May 31, 2017

Re: Apache cassandra wiki access

The wiki isn't really used anymore. You can submit patches to improve the docs in tree now. Fee free to tag me as a reviewer and I'll get to it this week. On Sat, Sep 16, 2017 at 10:26 AM Vusal Ahmadoglu wrote: > Hello, > > Could you please give access me to the apache

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

After an upgrade I recommend running upgrade sstables no matter what the version change is. If it's not needed, nothing will happen. On Fri, Oct 13, 2017 at 4:30 AM Steinmaurer, Thomas < thomas.steinmau...@dynatrace.com> wrote: > And extremely useful/important in the field not being a strict

Re: [VOTE] Release Apache Cassandra 2.1.19

+1 On Thu, Sep 28, 2017 at 1:46 PM Nate McCall wrote: > +1 > > On Sep 29, 2017 7:12 AM, "Michael Shuler" wrote: > > I propose the following artifacts for release as 2.1.19. > > sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c > Git: >

Re: [DISCUSS] Cassandra and future Java

Personally I don’t mind dropping support for previsous java versions. On Fri, May 25, 2018 at 6:33 AM J. D. Jordan wrote: > +1 for “Option 3: both 8 + 11” it shouldn’t be too hard to maintain code > wise, and leaves people’s options open. > > -Jeremiah > > > On May

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

Supporting both as a next step is logical, removing support for 2 in the next year or two seems reasonable enough. Gotta rip the band aid off at some point. On Fri, Jun 1, 2018 at 2:34 AM Michael Burman wrote: > Hi, > > Deprecating in this context does not mean removing it or it being >

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

e. I > think it will be more than 2 years before people begin asking what > Python 2 was. > > > On 06/01/2018 10:10 AM, Jonathan Haddad wrote: > > Supporting both as a next step is logical, removing support for 2 in the > > next year or two seems reasonable enough. Gotta

Re: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

lead of the OS vendors that people will be deploying > Cassandra on top of. And those will not be dropping Python 2 at the end of > the year. > > -Jeremiah > > > On Jun 1, 2018, at 12:37 PM, Jonathan Haddad wrote: > > > > Both can work. I did a lot of the work on t

Re: Testing 4.0 Post-Freeze

I agree with Josh. I don’t see how changing the convention around trunk will improve the process, seems like it’ll only introduce a handful of rollback commits when people forget. Other than that, it all makes sense to me. I’ve been working on a workload centric stress tool on and off for a

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

+1 On Mon, Feb 12, 2018 at 9:51 PM mck wrote: > > > > I propose the following artifacts for release as 3.11.2. > > > Thanks Michael for the recut, very much appreciated. > > +1 > > > - > To unsubscribe, e-mail:

Re: Expensive metrics?

Hey Micke, very cool you're looking to improve C*'s performance, we would absolutely benefit from it. Have you done any other benchmarks beside the micro one to determine the total effect of these metrics on the system overall? Microbenchmarks are a great way to tune small sections of code but

Re: Why isn't there a separate JVM per table?

There's an incredible amount of work that would need to be done in order to make any of this happen. Basically a full rewrite of the entire codebase. Years of effort. The codebase would have to move to a shared-nothing actor & message based communication mechanism before any of this is possible.

Re: NGCC 2018?

My interpretation of Nate's statement was that since there would be a bunch of us at Lynn's event, we might as well do NGCC at the same time. On Thu, Jul 26, 2018 at 9:03 PM Ben Bromhead wrote: > It sounds like there may be an appetite for something, but the NGCC in its > current format is

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

+1 On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote: > +1 > > On Wed, Jul 25, 2018 at 12:16 AM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.11.3. > > > > sha1: 31d5d870f9f5b56391db46ba6cdf9e0882d8a5c0 > > Git: > >

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

+1 On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote: > +1 > > On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.0.17. > > > > sha1: d52c7b8c595cc0d06fc3607bf16e3f595f016bb6 > > Git: > >

Re: [VOTE] Release Apache Cassandra 2.2.13

+1 On Wed, Jul 25, 2018 at 11:35 AM Jeff Jirsa wrote: > +1 > > On Wed, Jul 25, 2018 at 12:17 AM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 2.2.13. > > > > sha1: 3482370df5672c9337a16a8a52baba53b70a4fe8 > > Git: > >

G1GC is now default

I fired up trunk to check something, and noticed this: INFO [Service Thread] 2018-08-08 15:01:36,723 GCInspector.java:290 - G1 Young Generation GC in 339ms. G1 Eden Space: 4634705920 -> 0; G1 Old Gen: 1190138352 -> 1435504616; G1 Survivor Space: 406847488 -> 301989888; which I thought was a

Re: upgrade guava on trunk before 9/1?

Pushing it back means it’s a bigger risk later on. I’m +.5 on upgrading now On Wed, Aug 15, 2018 at 11:46 PM dinesh.jo...@yahoo.com.INVALID wrote: > Jason, > Given that we're so close to the 9/1 date, I would err on the side of > caution especially given the low value prop. If someone does run

Re: GitHub PR ticket spam

+1 to worklog On Mon, Aug 6, 2018 at 9:44 AM Ariel Weisberg wrote: > Hi, > > Great idea. +1 to moving it to the work log. > > Thanks, > Ariel > > On Mon, Aug 6, 2018, at 12:40 PM, Aleksey Yeshchenko wrote: > > Nice indeed. I assume it also doesn’t spam commits@ when done this way, > > in which

Re: Proposing an Apache Cassandra Management process

Speaking from experience (Reaper), I can say that developing a sidecar admin / repair tool out of tree that's compatible with multiple versions really isn't that big of a problem. We've been doing it for a while now. https://github.com/thelastpickle/cassandra-reaper/blob/master/.travis.yml On

Re: Yet another repair solution

I'm also very interested. On Tue, Aug 28, 2018 at 8:47 AM Dinesh Joshi wrote: > > On Aug 28, 2018, at 6:33 AM, Marcus Olsson > wrote: > > > > Hi, > > > > With the risk of stirring the repair/side-car topic even further I'd > just like to mention that we have recently gotten approval to

Re: Reaper as cassandra-admin

finishing up the rework of the code to run it as a sidecar. On Mon, Aug 27, 2018 at 6:02 PM Jeff Jirsa wrote: > Can you get all of the contributors cleared? > What’s the architecture? Is it centralized? Is there a sidecar? > > > > On Aug 27, 2018, at 5:36 PM, Jonathan Haddad wrote:

Reaper as cassandra-admin

Hey folks, Mick brought this up in the sidecar thread, but I wanted to have a clear / separate discussion about what we're thinking with regard to contributing Reaper to the C* project. In my mind, starting with Reaper is a great way of having an admin right now, that we know works well at the

Re: Side Car New Repo vs not

Strongly agree with Blake. In my mind supporting multiple versions is mandatory. As I've stated before, we already do it with Reaper, I'd consider it a major misstep if we couldn't support multiple with the project - provided admin tool. It's the same reason dtests are separate - they work with

Re: Java 11 Z garbage collector

Advertised, yes, but so far I haven't found it to be any better than ParNew + CMS or G1 in the performance tests I did when writing http://thelastpickle.com/blog/2018/08/16/java11.html. That said, I didn't try it with a huge heap (i think it was 16 or 24GB), so maybe it'll do better if I throw 50

Re: NGCC 2018?

year? We > may > > also be able to provide space in bay area and help to organize it. > (Please > > let us know, so we could get final approval for that). > > > > On Fri, Jul 27, 2018 at 10:05 AM Jonathan Haddad > > wrote: > > > > > My interpretatio

Re: QA signup

Test plans and results could be posted to said > JIRAs, to be closed once a given test passes. Any bugs found can also then > be related back to such a ticket for tracking them as well. > > -Jeremiah > > > On Sep 6, 2018, at 12:27 PM, Jonathan Haddad wrote: > > > &g

Re: Proposing an Apache Cassandra Management process

It's interesting to me that someone would consider features of Reaper as "technical debt"... an odd way to word it. When we had proposed donating Reaper to the project, I had made the assumption people would realize the benefit of folding in a successful project. A working codebase with a large

Re: QA signup

@%3Cdev.cassandra.apache.org%3E On Thu, Sep 6, 2018 at 10:35 AM Jordan West wrote: > Thanks for staring this thread Jon! > > On Thu, Sep 6, 2018 at 5:51 AM Jonathan Haddad wrote: > > > For 4.0, I'm thinking it would be a good idea to put together a list of > the > > things that need testing an

QA signup

For 4.0, I'm thinking it would be a good idea to put together a list of the things that need testing and see if people are willing to help test / break those things. My goal here is to get as much coverage as possible, and let folks focus on really hammering on specific things rather than just

Re: QA signup

oks like most testing is done by doing > an operation or running a load and seeing if it "worked" and no errors in > logs. > > Another important thing will be to fix bugs asap ahead of testing, as > fixes can lead to more bugs :) > > On Thu, Sep 6, 2018 at 7:52 AM Jonat

Re: Proposing an Apache Cassandra Management process

We haven’t even defined any requirements for an admin tool. It’s hard to make a case for anything without agreement on what we’re trying to build. On Fri, Sep 7, 2018 at 7:17 PM Jeff Jirsa wrote: > How can we continue moving this forward? > > Mick/Jon/TLP folks, is there a path here where we

Re: Testing 4.0 Post-Freeze

3 PM, sankalp kohli > > wrote: > > > > > > How is this preventing someone from working and collaborating on an > > Apache > > > Project? You can still collaborate on making 4.0 more stable. > > > > > > Why will these committers

Re: Testing 4.0 Post-Freeze

he community's prevailing > rules around commit, and that you’re competent to do so. > > If the community wants to change those rules you’re trusted to follow, how > does this modify your right, or the trust emplaced in you? > > > > > > > On 10 Jul 2018

Re: Testing 4.0 Post-Freeze

I guess I look at the initial voting in of committers as the process by which people are trusted to merge things in. This proposed process revokes that trust. If Jonathan Ellis or Dave Brosius (arbitrarily picked) wants to merge a new feature into trunk during the freeze, now they're not allowed?

Re: Scratch an itch

> > Deferring huge amount of commits gives rebase/redo hell. That's the > biggest impact and the order in which these deferred commits are then > actually committed can make it more painful or less painful depending on > the commit. And that in turn will have to then wait for each contributor > to

Re: Testing 4.0 Post-Freeze

t; >>> > > > >>> This is more of a call to action and announcement of intent than an > > > >>> attempt to enforce policy; we can and probably will branch off 4.0, > > > and > > > >>> keep trunk technically active. But so long as there

Re: Testing 4.0 Post-Freeze

l these > features be used? > > On Mon, Jul 9, 2018 at 10:03 AM Jonathan Haddad wrote: > > > I don't see how changing the process and banning feature commits is > > going to be any help to the project. There may be a couple committers > > who are interested in commi

Re: Testing 4.0 Post-Freeze

e things here. So if you are -1 on this, please help > us propose something else to get these tests pass? > > And thanks for giving your feedback. > > On Mon, Jul 9, 2018 at 10:50 AM Jonathan Haddad wrote: > > > Not everyone wants to work and collaborate the way you do. It seems &g

Re: [VOTE] Branching Change for 4.0 Freeze

+1, I've come around on this, I think the long and short term benefits will be worth it. On Fri, Jul 13, 2018 at 11:17 AM Vinay Chella wrote: > > +1 nb > > Regards, > Vinay Chella > > > On Fri, Jul 13, 2018 at 11:15 AM Michael Shuler > wrote: > > > +0 > > > > There are pros and cons. I do hope

  1   2   >