Re: Audit logging to tables.

2019-03-04 Thread Jonathan Haddad
> > > Any insights would be helpful. > > > > Thanks! > > Sagar. > > > > On Sat, Mar 2, 2019 at 7:23 AM Jonathan Haddad > wrote: > > > > > Instead of logging to tables, putting a virtual table around the audit > / > > > query logs

Re: CASSANDRA-14482

2019-03-01 Thread Jonathan Haddad
; of Zstd compression levels. > > Dinesh > > > On Mar 1, 2019, at 6:41 PM, Jonathan Haddad wrote: > > > > Hey all, > > > > I finally got around to doing some testing. Nothing too crazy, I had it > > run on my laptop while I did other things around the

Re: CASSANDRA-14482

2019-03-01 Thread Jonathan Haddad
Hey all, I finally got around to doing some testing. Nothing too crazy, I had it run on my laptop while I did other things around the house. Test 1: Inserting Random Data in a K/V table, 10 million inserts LZ4 compression rate: 0.909857609644112 ZStd: 0.6136099401596449 Test 2: Inserting

Re: Audit logging to tables.

2019-03-01 Thread Jonathan Haddad
ose, side-channel file storage > > >> format for transient things like this (hints, batches, audit logs, > etc) > > >> could be useful as a first class citizen in the codebase? i.e. a world > > in > > >> which we refactored some of the hints-specific reader/

Re: Audit logging to tables.

2019-02-28 Thread Jonathan Haddad
Agreed with Dinesh and Josh. I would *never* put the audit log back in Cassandra. This is extendable, Sagar, so you're free to do as you want, but I'm very opposed to putting a ticking time bomb in Cassandra proper. Jon On Thu, Feb 28, 2019 at 8:38 AM Dinesh Joshi wrote: > I strongly echo

Re: CASSANDRA-14482

2019-02-15 Thread Jonathan Haddad
Seems low risk, potentially high reward. I can run some tests next week to get a rough idea of how compression ratios differ as well as if there's a difference in performance. I won't be testing correctness, just looking at the performance profile. Jon On Fri, Feb 15, 2019 at 9:56 AM Michael

Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-03 Thread Jonathan Haddad
I think having the discussion around EOL is pretty important, in order to set the right expectations for the community. Looking at the commits for 2.1, there's hardly any activity going on, meaning it's effectively been EOL'ed for a long time now. I think it's better that we be honest with folks

Re: [VOTE] Release Apache Cassandra 3.11.4

2019-02-03 Thread Jonathan Haddad
+1 On Sun, Feb 3, 2019 at 9:35 AM Nate McCall wrote: > On Sat, Feb 2, 2019 at 4:38 PM Michael Shuler > wrote: > > > > I propose the following artifacts for release as 3.11.4. > > > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > > Git: > > >

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-03 Thread Jonathan Haddad
+1 On Sun, Feb 3, 2019 at 9:44 AM Nate McCall wrote: > On Sat, Feb 2, 2019 at 4:32 PM Michael Shuler > wrote: > > > > I propose the following artifacts for release as 3.0.18. > > > > sha1: edd52cef50a6242609a20d0d84c8eb74c580035e > > Git: > > >

Re: SSTable exclusion from read path based on sstable metadata marked by custom compaction strategies

2019-01-31 Thread Jonathan Haddad
In addition to what Jeff mentioned, there was an optimization in 3.4 that can significantly reduce the number of sstables accessed when a LIMIT clause was used. This can be a pretty big win with TWCS.

Re: Warn about SASI usage and allow to disable them

2019-01-16 Thread Jonathan Haddad
I'm +1 on the warning for two reasons. > A cqlsh warning only applies to those that create the sasi via cqlsh. 1. When people are creating their schemas in development, this is usually the first step. You use the REPL to figure out what you need, then you copy your schema somewhere else. The

Re: [DISCUSS] releasing next 3.0 & 3.11

2019-01-16 Thread Jonathan Haddad
Ping on this. On Mon, Jan 7, 2019 at 5:58 PM Michael Shuler wrote: > No problem, thanks for asking :) > > Michael > > On 1/7/19 6:20 PM, Jonathan Haddad wrote: > > It's been 5 months and 30+ bug fixes to each branch. > > > > Here's the two changelogs: > >

Re: Warn about SASI usage and allow to disable them

2019-01-14 Thread Jonathan Haddad
I'm very much in favor of a warning, and I lean towards disabling them (and MVs, while we're at it) by default as well. I've seen both features be the death of clusters, and are a major risk for teams that are brand new to Cassandra. On Mon, Jan 14, 2019 at 11:19 AM Andrés de la Peña wrote:

[DISCUSS] releasing next 3.0 & 3.11

2019-01-07 Thread Jonathan Haddad
It's been 5 months and 30+ bug fixes to each branch. Here's the two changelogs: https://github.com/apache/cassandra/blob/cassandra-3.0/CHANGES.txt https://github.com/apache/cassandra/blob/cassandra-3.11/CHANGES.txt How's everyone feel about getting a release out this week / early next week?

Re: Who should be in our distribution KEYS file?

2019-01-07 Thread Jonathan Haddad
changes, users need to modify their trust > on every node, importing new key(s), in order for packages to > install/upgrade with apt or yum. > > I don't understand how adding keys changes release frequency. Did > someone request a release to be made or are we on some assumed date > inter

Re: Who should be in our distribution KEYS file?

2019-01-07 Thread Jonathan Haddad
That's a good point. Looking at the ASF docs I had assumed the release manager was per-project, but on closer inspection it appears to be per-release. You're right, it does say that it can be any committer. http://www.apache.org/dev/release-publishing.html#release_manager We definitely need

Re: Who should be in our distribution KEYS file?

2019-01-07 Thread Jonathan Haddad
I agree with Stefan, if someone isn't a release manager there's no reason to add them, and it just increases the surface area for potential attack or issue. On Mon, Jan 7, 2019 at 11:35 AM Stefan Podkowinski wrote: > I don't see any reason to have any keys in there, except from release >

Re: Git Repo Migration

2019-01-04 Thread Jonathan Haddad
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/ > >

Re: Git Repo Migration

2019-01-04 Thread Jonathan Haddad
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

Re: Git Repo Migration

2019-01-04 Thread Jonathan Haddad
+1 On Fri, Jan 4, 2019 at 8:13 AM Ariel Weisberg wrote: > +1 > > On Fri, Jan 4, 2019, at 5: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

Re: [VOTE] Change Jira Workflow

2018-12-17 Thread Jonathan Haddad
+1 On Mon, Dec 17, 2018 at 9:50 AM Blake Eggleston wrote: > +1 > > > On Dec 17, 2018, at 9:31 AM, jay.zhu...@yahoo.com.INVALID wrote: > > > > +1 > > > >On Monday, December 17, 2018, 9:10:55 AM PST, Jason Brown < > jasedbr...@gmail.com> wrote: > > > > +1. > > > > On Mon, Dec 17, 2018 at 7:36

Re: JIRA Workflow Proposals

2018-12-05 Thread Jonathan Haddad
My personal preference is to remove labels, but I don't see it as a huge issue if they stay. 1. A 2. prefer to remove (I suppose I'm a -.1?) 3. +1 4. +1 5. No preference 6. +1 On Wed, Dec 5, 2018 at 11:43 AM jay.zhu...@yahoo.com.INVALID wrote: > 1: Component. (A) Multi-select > 2: Labels:

Re: Implicit Casts for Arithmetic Operators

2018-11-21 Thread Jonathan Haddad
-- > > Sylvain > > > > > >> I will make this more explicit for the vote, but just to clarify the > >> intention so that we are all discussing the same thing. > >> > >> > >>> On 20 Nov 2018, at 14:18, Ariel Weisberg wrote: > >&g

Re: Request to review feature-freeze proposed tickets

2018-11-20 Thread Jonathan Haddad
If nobody has any objections to CASSANDRA-14303 (default RF) being merged in I can take care of it. It's a significant usability improvement, looks well tested and will prevent a number of headaches. I'll try to get to it tomorrow. Thanks for bringing these up, Vinay. Jon On Tue, Nov 20, 2018

Re: Cassandra 3.11.x and Java 11

2018-11-19 Thread Jonathan Haddad
Correct. On Mon, Nov 19, 2018 at 1:02 PM Steinmaurer, Thomas < thomas.steinmau...@dynatrace.com> wrote: > Hello, > > am I right that Java 11 support will only be in Cassandra 4.0 and not in > future releases of the 3.11.x series? Just want to be sure. > > Thanks, > Thomas > > The contents of

Re: Implicit Casts for Arithmetic Operators

2018-11-16 Thread Jonathan Haddad
Sounds good to me. On Fri, Nov 16, 2018 at 5:09 AM Benedict Elliott Smith wrote: > So, this thread somewhat petered out. > > There are still a number of unresolved issues, but to make progress I > wonder if it would first be helpful to have a vote on ensuring we are ANSI > SQL 92 compliant for

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-29 Thread Jonathan Haddad
this point > > > > -0: > > Sylvaine Lebresne > > > > -.5: > > Jeff Jirsa > > > > This > > ( > https://github.com/aweisberg/cassandra/commit/a9ae85daa3ede092b9a1cf84879fb1a9f25b9dce) > > > is a rough cut of the change for the representat

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jonathan Haddad
and we never were really explicit that those sort of optimizations would be excluded after our feature freeze. I don't think they should necessarily be excluded at this time, but it depends on the size and risk of the patch. On Sat, Oct 20, 2018 at 8:38 AM Jonathan Haddad wrote: > I think we sho

Re: CASSANDRA-13241 lower default chunk_length_in_kb

2018-10-19 Thread Jonathan Haddad
I think we should try to do the right thing for the most people that we can. The number of folks impacted by 64KB is huge. I've worked on a lot of clusters created by a lot of different teams, going from brand new to pretty damn knowledgeable. I can't think of a single time over the last 2

cluster launching tool for dev work

2018-10-11 Thread Jonathan Haddad
Recently I reached an inflection point where my annoyance of launching clusters finally overcame my laziness. I wanted something similar to CCM, so I wrote it. The tool was designed for our usage at TLP, which usually means quickly firing up clusters for running tests. It started out as some

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Jonathan Haddad
Thanks for bringing this up, it definitely needs to be discussed. Last surprise is difficult here, since all major databases have their own way of doing things and people will just assume that their way is the right way. On that note, some people will be surprised no matter what we do. I'd

Re: [DISCUSS] changing default token behavior for 4.0

2018-09-22 Thread Jonathan Haddad
have created CASSANDRA-14784 to track this. > > > > > > Dinesh > > > > > >> On Sep 21, 2018, at 9:18 PM, Sankalp Kohli > > wrote: > > >> > > >> Putting it on JIRA is to make sure someone is assigned to it and it is > > tr

Re: [DISCUSS] changing default token behavior for 4.0

2018-09-21 Thread Jonathan Haddad
ff Jirsa > > > > > > > On Sep 21, 2018, at 8:24 PM, Jeremy Hanna > > wrote: > > > > > > I agree that it should be lowered. What I’ve seen debated a bit in the > > past is the number but I don’t think anyone thinks that it should remain > > 256. >

[DISCUSS] changing default token behavior for 4.0

2018-09-21 Thread Jonathan Haddad
One thing that's really, really bothered me for a while is how we default to 256 tokens still. There's no experienced operator that leaves it as is at this point, meaning the only people using 256 are the poor folks that just got started using C*. I've worked with over a hundred clusters in the

Re: QA signup

2018-09-20 Thread Jonathan Haddad
Sure - I'm not disagreeing with you that pre-built packages would be nice to have. That said, if someone's gone through the trouble of building an entire testing infrastructure and has hundreds of machines available, running `docker-compose up build-deb` is likely not a major issue. If I'm

Re: QA signup

2018-09-19 Thread Jonathan Haddad
It seems to me that improving / simplifying the process of building the packages might solve this problem better. For example, in the tests you linked to, they were using a custom build that hadn't been rolled into trunk. I expect we're going to see a lot of that. If we make building a deb

Re: Proposing an Apache Cassandra Management process

2018-09-13 Thread Jonathan Haddad
at was addressed by Jeff Jirsa and > deserves a separate thread as it is not directly related to this thread. > 3. Does the project need a side car. > > From Jonathan Haddad > 4. Are people doing +1 willing to contribute > > From Jonathan Ellis > 5. List of feature set, m

Re: [VOTE] Development Approach for Apache Cassandra Management process

2018-09-12 Thread Jonathan Haddad
This voting process feels a bit rushed and frankly not well thought out. In addition to Sylvain's valid points, which you (Sankalp) didn't address at all, the discussion in the other threads seemed to be ongoing. The last email you wrote on one of them was asking for additional feedback, that

Re: [VOTE] Accept GoCQL driver donation and begin incubation process

2018-09-12 Thread Jonathan Haddad
I'm +0, and I share the same concerns as Sylvain. For those of you that have +1'ed, are you planning on contributing to the driver? Docs, code, QA? It's easy to throw a +1 down to make the driver the responsibility of the project if you're asking others to do the work. I vote this way because I

Re: Proposing an Apache Cassandra Management process

2018-09-09 Thread Jonathan Haddad
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: Proposing an Apache Cassandra Management process

2018-09-07 Thread Jonathan Haddad
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: QA signup

2018-09-07 Thread Jonathan Haddad
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: QA signup

2018-09-06 Thread Jonathan Haddad
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: QA signup

2018-09-06 Thread Jonathan Haddad
@%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

2018-09-06 Thread Jonathan Haddad
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: NGCC 2018?

2018-09-05 Thread Jonathan Haddad
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: [Discuss] Accept GoCQL driver donation

2018-08-31 Thread Jonathan Haddad
Definitely does not belong in the same repo. I’m all for folding drivers in / writing our own, just needs active committers. On Fri, Aug 31, 2018 at 7:45 AM Michael Shuler wrote: > On 08/31/2018 09:34 AM, Jay Zhuang wrote: > > That's great. Could that be in the same repo as Cassandra or a > >

Re: Java 11 Z garbage collector

2018-08-30 Thread Jonathan Haddad
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: Yet another repair solution

2018-08-28 Thread Jonathan Haddad
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

2018-08-27 Thread Jonathan Haddad
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

2018-08-27 Thread Jonathan Haddad
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

2018-08-21 Thread Jonathan Haddad
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: Proposing an Apache Cassandra Management process

2018-08-17 Thread Jonathan Haddad
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: upgrade guava on trunk before 9/1?

2018-08-16 Thread Jonathan Haddad
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

G1GC is now default

2018-08-08 Thread Jonathan Haddad
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: GitHub PR ticket spam

2018-08-06 Thread Jonathan Haddad
+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: NGCC 2018?

2018-07-27 Thread Jonathan Haddad
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 2.2.13

2018-07-25 Thread Jonathan Haddad
+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: > >

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

2018-07-25 Thread Jonathan Haddad
+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)

2018-07-25 Thread Jonathan Haddad
+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] Branching Change for 4.0 Freeze

2018-07-13 Thread Jonathan Haddad
+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

Re: Scratch an itch

2018-07-12 Thread Jonathan Haddad
> > 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

2018-07-10 Thread Jonathan Haddad
ion to need it - besides > discouraging a new contributor who, let’s be honest, was going to have their > patch languish for a few months while somebody found time to review it > anyway. At least this way we can give them a decent excuse! > > > > > On 10 Jul 2018, at 10:43

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Jonathan Haddad
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

2018-07-10 Thread Jonathan Haddad
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: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
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

2018-07-09 Thread Jonathan Haddad
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: Testing 4.0 Post-Freeze

2018-07-09 Thread Jonathan Haddad
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

2018-07-09 Thread Jonathan Haddad
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

2018-07-03 Thread Jonathan Haddad
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: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

2018-06-01 Thread Jonathan Haddad
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: Planning to port cqlsh to Python 3 (CASSANDRA-10190)

2018-06-01 Thread Jonathan Haddad
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)

2018-06-01 Thread Jonathan Haddad
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: [DISCUSS] Cassandra and future Java

2018-05-25 Thread Jonathan Haddad
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: Evolving the client protocol

2018-04-24 Thread Jonathan Haddad
DataStax invested millions of dollars into Cassandra, tens of thousands of man hours, hosted hundreds of events and has been a major factor in the success of the project. ScyllaDB wants us to change the C* protocol in order to improve features in a competing database which contributes nothing

Re: Evolving the client protocol

2018-04-23 Thread Jonathan Haddad
>From where I stand it looks like you've got only two options for any feature that involves updating the protocol: 1. Don't built the feature 2. Built it in Cassanda & scylladb, update the drivers accordingly I don't think you have a third option, which is built it only in ScyllaDB, because that

Re: Evolving the client protocol

2018-04-18 Thread Jonathan Haddad
Avi, if this is something that matters to you, you're more than welcome to submit a patch to both this project and to the different drivers. Getting the first 2 optimizations into 4.0 would be nice, I'm sure someone would be happy to work with you on it. The third, I can't see why we'd need that

Re: Roadmap for 4.0

2018-04-09 Thread Jonathan Haddad
There's always more stuff to try to shoehorn in. We've done big releases with all the things, it never was stable. We tried the opposite end of the spectrum, release every month, that really wasn't great either. Personally I'd be OK with stopping new features by the end of this month and aiming

Re: Repair scheduling tools

2018-04-05 Thread Jonathan Haddad
Off the top of my head I can remember clusters with 600 or 700 nodes with 256 tokens. Not the best situation, but it’s real. 256 has been the default for better or worse. On Thu, Apr 5, 2018 at 7:41 PM Joseph Lynch wrote: > > > > We see this in larger clusters regularly.

Re: Roadmap for 4.0

2018-04-05 Thread Jonathan Haddad
That’s exactly what I was thinking too. There’s also nothing preventing features from being merged into trunk after we create the 4.0 branch, which in my opinion is a better approach than trying to jam everything in right before the release. On Thu, Apr 5, 2018 at 12:06 PM Jason Brown

Re: Repair scheduling tools

2018-04-05 Thread Jonathan Haddad
To be fair, reaper in 2016 only worked with 2.0 and was just sitting around, more or less. Since then we've had 401 commits changing tens of thousands of lines of code, dealing with fault tolerance, repair retries, scalability, etc. We've had 1 reaper node managing repairs across dozens of

Re: Paying off tech debt and correctly naming things

2018-03-28 Thread Jonathan Haddad
As requested, I'm alerting the ML that I've got the first patch of several to come. This one only addresses the ColumnFamilyStore class - and only changes the name. There's follow up tickets to change method and variable names. As we agreed, I'm doing this incrementally, so please let's keep

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

2018-03-23 Thread Jonathan Haddad
se with a runtime that's > likely EOL shortly after? > > On Fri, Mar 23, 2018 at 11:52 AM, Jonathan Haddad <j...@jonhaddad.com> > wrote: > > Java 8 was marked as EOL in the middle of last year, I hope we wouldn't > > require it for Cassandra 4. At this point I feel like we

Re: [DISCUSS] java 9 and the future of cassandra on the jdk

2018-03-23 Thread Jonathan Haddad
Java 8 was marked as EOL in the middle of last year, I hope we wouldn't require it for Cassandra 4. At this point I feel like we should already be targeting Java 10 at a minimum. Personally I'd prefer not to tie our releases to any vendor / product / package's release schedule. On Fri, Mar 23,

Re: Making RF4 useful aka primary and secondary ranges

2018-03-14 Thread Jonathan Haddad
You could use a load balancing policy at the driver level to do what you want, mixed with the existing consistency levels as Jeff suggested. On Wed, Mar 14, 2018 at 3:47 PM Carl Mueller wrote: > But we COULD have CL2 write (for RF4) > > The extension to this idea

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

2018-02-22 Thread Jonathan Haddad
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: Expensive metrics?

2018-02-22 Thread Jonathan Haddad
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: [VOTE] (Take 2) Release Apache Cassandra 3.11.2

2018-02-12 Thread Jonathan Haddad
+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: Getting partition min/max timestamp

2018-01-13 Thread Jonathan Haddad
Do you need to support TTLs? That might be a bit of an issue. On Sat, Jan 13, 2018 at 12:41 PM Arthur Kushka wrote: > Hi folks, > > Currently, I working on custom CQL operator that should return the max > timestamp for some partition. > > I don't think that scanning of

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

2017-10-13 Thread Jonathan Haddad
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

2017-09-28 Thread Jonathan Haddad
+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: Apache cassandra wiki access

2017-09-16 Thread Jonathan Haddad
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: NGCC Proposal (Was Re: NGCC?)

2017-06-13 Thread Jonathan Haddad
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: NGCC?

2017-05-31 Thread Jonathan Haddad
+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

rebuilding cassandra.apache.org docs

2017-05-15 Thread Jonathan Haddad
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

2017-05-15 Thread Jonathan Haddad
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

Re: Integrating vendor-specific code and developing plugins

2017-05-13 Thread Jonathan Haddad
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: Guidelines on testing

2017-05-04 Thread Jonathan Haddad
+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: [VOTE] self-assignment of jira tickets

2017-03-29 Thread Jonathan Haddad
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 ( > > >

splitting CQL parser & spec into separate repo

2017-03-21 Thread Jonathan Haddad
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

  1   2   >