Re: Java8 compatibility broken in 4.0

2019-06-11 Thread Aleksey Yeshchenko
No, this is not intentional. At the very least for 4.0 we are going to keep compatibility with Java 8. > 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

Re: Acceptable for trunk? Committing the patch for "Customize cassandra log directory" (CASSANDRA-15090)

2019-05-26 Thread Aleksey Yeshchenko
Yeah. I wouldn’t even go and ask for a waiver for anything as trivial as this change. Common sense of a committer should be sufficient. > On 26 May 2019, at 09:31, Mick Semb Wever wrote: > > > The ticket CASSANDRA-15090 has a patch to introduce the variable > $CASSANDRA_LOG_DIR > >

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-13 Thread Aleksey Yeshchenko
some standardised workloads and test bed. >>> At the moment we’re benefiting from some large contributors doing their own >>> proprietary performance testing, which is super valuable and something >>> we’ve lacked before. But I’m also keen to see some more repr

Re: TLP tools for stress testing and building test clusters in AWS

2019-04-12 Thread Aleksey Yeshchenko
Hey Jon, This sounds exciting and pretty useful, thanks. Looking forward to using tlp-stress for validating 15066 performance. We should touch base some time next week to pick a comprehensive set of workloads and versions, perhaps? > On 12 Apr 2019, at 16:34, Jon Haddad wrote: > > I don't

Re: Jira: Author Field

2019-04-08 Thread Aleksey Yeshchenko
Some of it is just for clear attribution. Occasionally, you do get an extensive review that borders on authoring/coauthoring. Sometimes you get a large body of work co-created by several people in author capacity. Having a multi-user Authors field, in addition to the multi-user Reviewers

Re: [VOTE] Release Apache Cassandra 2.1.21

2019-02-04 Thread Aleksey Yeshchenko
Not sure we need another 2.1 release, this one included, but sure, +1 So long as the branch itself stays kinda open and most critical issues can have at least fixes for them committed, the interested parties can then keep building the artefacts manually. Once 4.0 is out we can freeze the

Re: [VOTE] Release Apache Cassandra 2.2.14

2019-02-04 Thread Aleksey Yeshchenko
+1 > On 3 Feb 2019, at 00:32, Michael Shuler wrote: > > I propose the following artifacts for release as 2.2.14. > > sha1: af91658353ba601fc8cd08627e8d36bac62e936a > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/2.2.14-tentative > Artifacts: >

Re: [VOTE] Release Apache Cassandra 3.0.18

2019-02-04 Thread Aleksey Yeshchenko
+1 > On 4 Feb 2019, at 00:39, Joseph Lynch wrote: > > 3.0.18-tentative unit and dtest run: > https://circleci.com/gh/jolynch/cassandra/tree/3.0.18-tentative > > unit tests: 0 failures > dtests: 1 failure > * test_closing_connections - thrift_hsha_test.TestThriftHSHA ( >

Re: [VOTE] Release Apache Cassandra 3.11.4

2019-02-04 Thread Aleksey Yeshchenko
+1 > On 3 Feb 2019, at 00:31, Michael Shuler wrote: > > I propose the following artifacts for release as 3.11.4. > > sha1: fd47391aae13bcf4ee995abcde1b0e180372d193 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.4-tentative > Artifacts: >

Re: [VOTE] Change Jira Workflow

2018-12-18 Thread Aleksey Yeshchenko
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,

Re: JIRA Workflow Proposals

2018-12-11 Thread Aleksey Yeshchenko
1. C, D, A, B, E 2. B, C, A 3. A 4. Meh > On 11 Dec 2018, at 16:28, Benedict Elliott Smith wrote: > > Just to re-summarise the questions for people: > > 1. (A) Only contributors may edit or transition issues; (B) Only contributors > may transition issues; (C) Only Jira-users may transition

Re: Using Cassandra as local db without cluster

2018-10-18 Thread Aleksey Yeshchenko
I agree with Jeff here. Furthermore, Cassandra should generally be your solution of last resort - if nothing else works out. In your case I’d try sqlite or leveldb (or rocksdb). > On 18 Oct 2018, at 11:46, Jeff Jirsa wrote: > > I can’t think of a situation where I’d choose Cassandra as a

Re: Moving tickets out of 4.0 post freeze

2018-09-24 Thread Aleksey Yeshchenko
We could continue as 4.0.x, 5.0.x, 6.0.x, 7.0.x, 8.0.x, 9.0.x, with minor forever fixed to 0. But I’m also struggling with how to justify the existence of that unused digit. We have never really done semantic versioning, we’ve arbitrarily flipped the major whenever we felt like “it was the

Re: Side Car New Repo vs not

2018-08-21 Thread Aleksey Yeshchenko
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 wrote: > FWIW I’m strongly -1 on in-tree approach, and would much prefer a separate > repo,

Re: Side Car New Repo vs not

2018-08-21 Thread Aleksey Yeshchenko
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

Re: GitHub PR ticket spam

2018-08-06 Thread Aleksey Yeshchenko
Nice indeed. I assume it also doesn’t spam commits@ when done this way, in which case double +1 from me. — AY On 6 August 2018 at 17:18:36, Jeremiah D Jordan (jeremiah.jor...@gmail.com) wrote: Oh nice. I like the idea of keeping it but moving it to the worklog tab. +1 on that from me. >

Re: [VOTE] Branching Change for 4.0 Freeze

2018-07-11 Thread Aleksey Yeshchenko
+1 — AY On 11 July 2018 at 22:47:03, sankalp kohli (kohlisank...@gmail.com) wrote: Hi, As discussed in the thread[1], we are proposing that we will not branch on 1st September but will only allow following merges into trunk. a. Bug and Perf fixes to 4.0. b. Critical bugs in any version

Re: Testing 4.0 Post-Freeze

2018-07-10 Thread Aleksey Yeshchenko
+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

Re: Testing 4.0 Post-Freeze

2018-07-04 Thread Aleksey Yeshchenko
nch off 4.0, and keep trunk > > technically active. > > These are two very different statements. :) Which is it? > > On Tue, Jul 3, 2018 at 5:57 PM Aleksey Yeshchenko > wrote: > > > If we want to have a stable, usable 4.0.0 release out in the next 6-12

Re: Testing 4.0 Post-Freeze

2018-07-03 Thread Aleksey Yeshchenko
If we want to have a stable, usable 4.0.0 release out in the next 6-12 months, there needs to be a focused effort on getting it out - or else it’ll just never happen. This is more of a call to action and announcement of intent than an attempt to enforce policy; we can and probably will branch

Re: Which approach should we use for exposing metrics through Virtual tables?

2018-06-25 Thread Aleksey Yeshchenko
I don’t think it’s really necessary. Or at least I’m not seeing why having individual, specialised virtual tables is not sufficient. Nor do I think that we should expose everything that nodetool does, so IMO we shouldn’t aim for that. Even if the goal were to eventually deprecate and remove

Re: Roadmap for 4.0

2018-04-05 Thread Aleksey Yeshchenko
So long as non-user-visible improvements, including big ones, can still go in 4.0 at that stage, I’m all for it. — AY On 5 April 2018 at 21:14:03, Nate McCall (zznat...@gmail.com) wrote: >>> My understanding, from Nate's summary, was June 1 is the freeze date for >>> features. I expect we

Re: Roadmap for 4.0

2018-04-05 Thread Aleksey Yeshchenko
June feels a bit too early to me as well. I personally would go prefer end of August / beginning of September. +1 to the idea of having a fixed date, though, just not this one. — AY On 5 April 2018 at 19:20:12, Stefan Podkowinski (s...@apache.org) wrote: June is too early. On 05.04.18

Re: Roadmap for 4.0

2018-04-04 Thread Aleksey Yeshchenko
3.0 will be the most popular release for probably at least another couple years - I see no good reason to cap its support window. We aren’t Oracle. — AY On 3 April 2018 at 22:29:29, Michael Shuler (mich...@pbandjelly.org) wrote: Apache Cassandra 3.0 is supported until 6 months after 4.0

Re: Paying off tech debt and correctly naming things

2018-03-22 Thread Aleksey Yeshchenko
Poor and out-of-date naming of things is probably the least serious part of our technical debt. Bad factoring, and straight-up poorly written components is where it’s really at. Doing a big rename for rename sake alone does more harm than it is good, sometimes. Some of us have big patches in

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

2018-02-13 Thread Aleksey Yeshchenko
+1 — AY On 13 February 2018 at 03:41:09, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.11.2. sha1: 8a5e88f635fdb984505a99a553b5799cedccd06d Git:

Re: [VOTE] Release Apache Cassandra 2.1.20

2018-02-13 Thread Aleksey Yeshchenko
+1 — AY On 12 February 2018 at 20:30:58, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.1.20. sha1: b2949439ec62077128103540e42570238520f4ee Git:

Re: [VOTE] Release Apache Cassandra 3.0.16

2018-02-13 Thread Aleksey Yeshchenko
+1 — AY On 12 February 2018 at 20:31:23, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.0.16. sha1: 91e83c72de109521074b14a8eeae1309c3b1f215 Git:

Re: [VOTE] Release Apache Cassandra 2.2.12

2018-02-13 Thread Aleksey Yeshchenko
+1 — AY On 12 February 2018 at 20:31:06, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.2.12. sha1: 1602e606348959aead18531cb8027afb15f276e7 Git:

Re: Approximate 4.0 timeframe

2018-01-23 Thread Aleksey Yeshchenko
There isn’t, or at least not that I know of. Some time this year most likely. I don’t think anybody is in a rush for 4.0, either. — AY On 23 January 2018 at 15:40:36, Jakub Janco (jja...@redhat.com) wrote: Hello, is here any update? I can't find any new information. Thanks. -- Best

Re: CASSANDRA-8527

2018-01-09 Thread Aleksey Yeshchenko
ows" or something similar would make more sense then? Le ven. 5 janv. 2018 à 20:24, Aleksey Yeshchenko <alek...@apple.com> a écrit : > Counting the number of range tombstones - sure, that is reasonable. > > Counting cells/rows shadowed by range tombstones toward the

Re: CASSANDRA-8527

2018-01-05 Thread Aleksey Yeshchenko
redRowIterator interface to include the tombstones/rows/cells stats > as this is what is returned from the lower levels of the read path. > Is there any easier way to achieve this that you can think of, as that > interface is used in many parts of the code ? > > On Wed, Dec 2

Re: CASSANDRA-8527

2017-12-27 Thread Aleksey Yeshchenko
As Jeff says, the number of actual tombstones is no less relevant than the number of cells and rows shadowed by them. And the way row and cell tombstones affect a read query can be very different from the way a big range tombstone might: you potentially have to retain every (regular) tombstone

Re: Proposal to retroactively mark materialized views experimental

2017-10-04 Thread Aleksey Yeshchenko
Strongly disagree with MV’s being isolated part. You can feel the touch of the MVs in the read path, write path, metadata handling, whether you use them or not. And comparing any of those before/after MVs were introduced makes me sad every time I face any of it. It made our codebase

Re: Proposal to retroactively mark materialized views experimental

2017-10-04 Thread Aleksey Yeshchenko
Yep. Almost! Changing the default in a minor version might break some scripts/tooling that manipulate schema and potentially create new MVs (as dangerous as it currently is - manipulating schema in that way), and that would still not be very nice. Introducing a flag and leaving it at false in

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Aleksey Yeshchenko
Indeed. Paulo and Zhao did a lot of good work to make the situation less bad. You did some as well. Even I retouched small parts of it - metadata related. I’m sorry if I came off as disrespectful - I didn’t mean to. I’ve seen and I appreciate every commit that went into it. It is however my

Re: [VOTE] Release Apache Cassandra 3.11.1

2017-10-03 Thread Aleksey Yeshchenko
gt;> > >> Thanks, > >> Thomas > >> > >> -Original Message- > >> From: Jon Haddad [mailto:jonathan.had...@gmail.com] On Behalf Of Jon > >> Haddad > >> Sent: Montag, 02. Oktober 2017 22:09 > >> To: d

Re: Proposal to retroactively mark materialized views experimental

2017-10-03 Thread Aleksey Yeshchenko
There are a couple compromise options here: a) Introduce the flag (enalbe_experimental_features, or maybe one per experimental feature), set it to ‘false’ in the yaml, but have the default be ‘true’. So that if you are upgrading from a previous minor to the next without updating the yaml, you

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Aleksey Yeshchenko
Yep. And that would be nice to have in addition to the opt-in flag in the yaml for the operators that’s stricter than a warning. — AY On 2 October 2017 at 22:21:33, Jeremiah D Jordan (jerem...@datastax.com) wrote: We are not saying to just put something in logs, we are talking about the warn

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Aleksey Yeshchenko
ture I > think > > >> that is pretty visible during development? > > >> > > >> I guess I can see just blocking new ones without a flag set, but we > need > > >> to be careful here. We need to make sure we don’t cause a problem for > > >> someone tha

RE: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Aleksey Yeshchenko
Thomas, I would maybe agree with waiting for a while because of it, if we had a proper fix at least under review - or in progress by someone. But this is not a regression, and there’s been a lot of fixes accumulated and not released yet. Arguable worse to hold them back :\ — AY On 2 October

Re: [VOTE] Release Apache Cassandra 3.11.1

2017-10-02 Thread Aleksey Yeshchenko
+1 — AY On 2 October 2017 at 18:58:57, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.11.1. sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af Git:

Re: [VOTE] Release Apache Cassandra 3.0.15

2017-10-02 Thread Aleksey Yeshchenko
+1 — AY On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 3.0.15. sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 Git:

Re: Proposal to retroactively mark materialized views experimental

2017-10-02 Thread Aleksey Yeshchenko
The idea is to check the flag in CreateViewStatement, so creation of new MVs doesn’t succeed without that flag flipped. Obviously, just disabling existing MVs working in a minor would be silly. As for the warning - yes, that should also be emitted. Unconditionally. — AY On 2 October 2017 at

Re: Expected release date for 3.11.1?

2017-09-30 Thread Aleksey Yeshchenko
> I appreciate the update! > > -- > Michael > > On 09/28/2017 10:50 AM, Aleksey Yeshchenko wrote: > > FWIW, none of the remaining issues are strictly speaking regressions > from previous versions. > > > > So if we felt strongly about st

Re: [VOTE] Release Apache Cassandra 2.1.19

2017-09-28 Thread Aleksey Yeshchenko
+1 — AY On 28 September 2017 at 19:12:19, Michael Shuler (mich...@pbandjelly.org) wrote: I propose the following artifacts for release as 2.1.19. sha1: 428eaa3e37cab7227c81fdf124d29dfc1db4257c Git:

Re: Compact Storage and SuperColumn Tables in 4.0/trunk

2017-09-19 Thread Aleksey Yeshchenko
4.0 should also fail startup (very early) if it still sees any non-migrated tables, probably. — AY On 19 September 2017 at 18:35:11, J. D. Jordan (jeremiah.jor...@gmail.com) wrote: Thanks for the clarification. +1 for adding a "DROP COMPACT STORAGE" option in 3.x and then not allowing it to

Re: Hints replay incompatible between 2.x and 3.x

2017-08-30 Thread Aleksey Yeshchenko
It doesn’t work between any two majors (1.2 and 2.0, 2.0 and 2.1, 2.1 and 3.0). The reason is that hint delivery doesn’t proceed between two nodes unless they have the same schema version, and in every recent major release we made changes that made schema calculation differ even without any DDL