Re: Proposal to retroactively mark materialized views experimental

At the risk of sounding redundant it sounds like for MVs at this point we want to preserve current functionality for existing users. We would have a flag in the yaml to disable it by default for new MV creation with an error message. In addition we want a warning in the log and in cqlsh upon

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 On Tue, Oct 3, 2017 at 6:18 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.0.15. > > sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.15-tentative >

Re: Proposal to retroactively mark materialized views experimental

On 3 October 2017 at 04:57, Aleksey Yeshchenko wrote: > 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 -

Re: Proposal to retroactively mark materialized views experimental

Experimental / feature flags in the yaml file is a far better choice for operators. Explicit opt-in for "dangerous" features would greatly help protect new users as well. Plenty of users ignore batch size warnings, tombstone warnings, etc. A soft warnings only approach would not achieve the goals

Re: Proposal to retroactively mark materialized views experimental

If a user (vs Cassandra dev) perspective is welcome - I'd recommend similarly identifying experimental features in the DESCRIBE / DESC cqlsh output as well. On Mon, Oct 2, 2017 at 4:21 PM, Jeremiah D Jordan wrote: > Blake, > We are not saying to just put something in

Re: Proposal to retroactively mark materialized views experimental

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

Yes, I understand what you're saying. The points I'm making about logs still apply. It's possible for drivers and object mappers to handle queries and schema changes, and have developers rarely open cqlsh. It's also not uncommon for schema changes to be done by a different group than the

Re: Proposal to retroactively mark materialized views experimental

Blake, We are not saying to just put something in logs, we are talking about the warn actually showing up in cqlsh. When you issue a native protocol warn cqlsh will print it out on the console in front of you in the results of the query. https://issues.apache.org/jira/browse/CASSANDRA-8930

Re: Proposal to retroactively mark materialized views experimental

It is different because it allows the operators to set those boundaries rather than rely on users doing the right thing. So ideally you’d have the flag (and given the state of MVs, both design and the implementation, I’d argue the default should be NOPE) - for the operators, and a warning in

Re: [VOTE] Release Apache Cassandra 3.11.1

Same boat as Jeff, +1 since it’s not a regression. > On Oct 2, 2017, at 2:04 PM, Steinmaurer, Thomas > wrote: > > Jeff of course, not Jon. Sorry :-) > > > -Original Message- > From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com] >

Re: Proposal to retroactively mark materialized views experimental

Developers are also not the only people that are able to make decisions. Keeping it in the YAML means an operator can disable it vs a developer *maybe* seeing the warning. Keep in mind not everyone creates tables through CQLSH. > On Oct 2, 2017, at 2:05 PM, Blake Eggleston

Re: Proposal to retroactively mark materialized views experimental

The message isn't materially different, but it will reach fewer people, later. People typically aren't as attentive to logs as they should be. Developers finding out about new warnings in the logs later than they could have, sometimes even after it's been deployed, is not uncommon. It's

RE: [VOTE] Release Apache Cassandra 3.11.1

Jeff of course, not Jon. Sorry :-) -Original Message- From: Steinmaurer, Thomas [mailto:thomas.steinmau...@dynatrace.com] Sent: Montag, 02. Oktober 2017 22:58 To: dev@cassandra.apache.org Subject: RE: [VOTE] Release Apache Cassandra 3.11.1 Jon, yes I also did see it with 3.11.0.

RE: [VOTE] Release Apache Cassandra 3.11.1

Jon, yes I also did see it with 3.11.0. Thomas -Original Message- From: Jeff Jirsa [mailto:jji...@gmail.com] Sent: Montag, 02. Oktober 2017 22:47 To: Cassandra DEV Subject: Re: [VOTE] Release Apache Cassandra 3.11.1 Thomas, did you see this on 3.11.0 as

Re: [VOTE] Release Apache Cassandra 3.11.1

Thanks for the reminder. +1 it is (but we should rush out 3.11.2 when we find/fix that leak). On Mon, Oct 2, 2017 at 1:51 PM, Jeremiah D Jordan wrote: > Jeff, > > TL;DR 3.11.0 shows it for them as well. See https://issues.apache.org/ > jira/browse/CASSANDRA-13900

Re: [VOTE] Release Apache Cassandra 3.11.1

Jeff, TL;DR 3.11.0 shows it for them as well. See https://issues.apache.org/jira/browse/CASSANDRA-13900 for the rest of the story. -Jeremiah > On Oct 2, 2017, at 4:47 PM, Jeff Jirsa wrote: > > Thomas, did you see

Re: [VOTE] Release Apache Cassandra 3.11.1

Thomas, did you see this on 3.11.0 as well, or have you not tried 3.11.0 (I know you probably want fixes from 3.11.1, but let's just clarify that this is or is not a regression). If it's not a regression, we should ship this and then hopefully we'll spin a 3.11.2 as soon as this is fixed. If it

RE: [VOTE] Release Apache Cassandra 3.11.1

Jon, please see my latest comment + attached screen from our monitoring here: https://issues.apache.org/jira/browse/CASSANDRA-13754?focusedCommentId=16188758=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16188758 Thanks, Thomas -Original Message- From: Jon

Re: Proposal to retroactively mark materialized views experimental

"Nobody is talking about removing MVs." Not precisely true for this email thread: "but should there be some point in the future where we consider removing them from the code base unless they have gotten significant improvement as well?" IMO a .yaml change requirement isn't materially different

Re: [VOTE] Release Apache Cassandra 3.11.1

You’re saying the same memory leak happens under 3.11? > On Oct 2, 2017, at 1:04 PM, Aleksey Yeshchenko wrote: > > 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

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 On Mon, Oct 2, 2017 at 2:04 PM, Jeff Jirsa wrote: > +1 > > > On Mon, Oct 2, 2017 at 10:18 AM, Michael Shuler > wrote: > > > I propose the following artifacts for release as 3.0.15. > > > > sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 > > Git: > >

RE: [VOTE] Release Apache Cassandra 3.11.1

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

Jeff, even if it is not a strict regression, this currently forces us to do a rolling restart every ~ 72hrs to be on the safe-side with -Xmx8G. Luckily this is just a loadtest environment. We don't have 3.11 in production yet. I can offer to immediately deploy a snapshot build into our

Re: Proposal to retroactively mark materialized views experimental

Ok so IF there is a flag to enable MV (à-la UDA/UDF in cassandra.yaml) then I'm fine with it. I initially understood that we wanted to disable it definitively. Maybe we should then add an explicit error message when MV is disabled and someone tries to use it, something like: "MV has been

Re: Proposal to retroactively mark materialized views experimental

There’s a big difference between removal of a protocol that every single C* user had to use and disabling a feature which is objectively broken and almost nobody is using. Nobody is talking about removing MVs. If you want to use them you can enable them very trivially, but it should be an

Re: [VOTE] Release Apache Cassandra 3.11.1

+1 On Mon, Oct 2, 2017 at 12:58 PM, Michael Shuler wrote: > I propose the following artifacts for release as 3.11.1. > > sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >

Re: Proposal to retroactively mark materialized views experimental

"I would (in a patch release) disable MV CREATE statements, and emit warnings for ALTER statements and on schema load if they’re not explicitly enabled" --> I find this pretty extreme. Now we have an existing feature sitting there in the base code but forbidden from version xxx onward. Since

Re: Proposal to retroactively mark materialized views experimental

> Only emitting a warning really reduces visibility where we need it: in the > development process. How does emitting a native protocol warning reduce visibility during the development process? If you run CREATE MV and cqlsh then prints out a giant warning statement about how it is an

Re: [VOTE] Release Apache Cassandra 3.11.1

The comment at the end of CASSANDRA-13754 is a bit concerning, as it was from yesterday and the user is seeing heap issues. It would be unfortunate to have to pull the release if it’s suffering from a major memory leak. > On Oct 2,

Re: [VOTE] Release Apache Cassandra 3.11.1

+1 ( Somewhat concerned that https://issues.apache.org/jira/browse/CASSANDRA-13754 may not be fixed, but it's not a strict regression ? ) On Mon, Oct 2, 2017 at 10:58 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.11.1. > > sha1:

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 On Mon, Oct 2, 2017 at 10:18 AM, Michael Shuler wrote: > I propose the following artifacts for release as 3.0.15. > > sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 > Git: > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a= >

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 On Mon, Oct 2, 2017 at 11:00 Jon Haddad wrote: > +1 > > > On Oct 2, 2017, at 11:00 AM, Brandon Williams wrote: > > > > +1 > > > > On Oct 2, 2017 12:58 PM, "Aleksey Yeshchenko" wrote: > > > >> +1 > >> > >> — > >> AY > >> > >> On 2

Re: [VOTE] Release Apache Cassandra 3.11.1

+1 On Mon, Oct 2, 2017 at 11:01 Aleksey Yeshchenko wrote: > +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.11.1

+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: Proposal to retroactively mark materialized views experimental

Yeah, I'm not proposing that we disable MVs in existing clusters. On October 2, 2017 at 10:58:11 AM, Aleksey Yeshchenko (alek...@apple.com) wrote: The idea is to check the flag in CreateViewStatement, so creation of new MVs doesn’t succeed without that flag flipped. Obviously, just

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 > On Oct 2, 2017, at 11:00 AM, Brandon Williams wrote: > > +1 > > On Oct 2, 2017 12:58 PM, "Aleksey Yeshchenko" wrote: > >> +1 >> >> — >> AY >> >> On 2 October 2017 at 18:18:26, Michael Shuler (mich...@pbandjelly.org) >> wrote: >> >> I propose the

Re: [VOTE] Release Apache Cassandra 3.0.15

+1 On Oct 2, 2017 12:58 PM, "Aleksey Yeshchenko" wrote: > +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

Having now helped a few folks that have put MVs into prod without realizing what they got themselves into, I’m +1 on a flag disabling the feature by default. A WARN message would not have helped them. > On Oct 2, 2017, at 10:56 AM, Blake Eggleston wrote: > > Yeah I’m

[VOTE] Release Apache Cassandra 3.11.1

I propose the following artifacts for release as 3.11.1. sha1: 983c72a84ab6628e09a78ead9e20a0c323a005af Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.1-tentative Artifacts:

Re: [VOTE] Release Apache Cassandra 3.0.15

+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

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: Proposal to retroactively mark materialized views experimental

Yeah I’m not sure that just emitting a warning is enough. The point is to be super explicit that bad things will happen if you use MVs. I would (in a patch release) disable MV CREATE statements, and emit warnings for ALTER statements and on schema load if they’re not explicitly enabled. Only

Re: Proposal to retroactively mark materialized views experimental

Hindsight is 20/20. For 8099 this is the reason we cut the 2.2 release before 8099 got merged. But moving forward with where we are now, if we are going to start adding some experimental flags to things, then I would definitely put SASI on this list as well. For both SASI and MV I don’t know

[VOTE] Release Apache Cassandra 3.0.15

I propose the following artifacts for release as 3.0.15. sha1: b32a9e6452c78e6ad08e371314bf1ab7492d0773 Git: http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.15-tentative Artifacts: