Re: Occasional Cassandra Status Wrapup

[Eric Evans]

On Sat, Sep 30, 2017 at 12:29 AM, Jeff Jirsa  wrote:
> It's been a long time since I've remembered to write what used to be the
> weekly cassandra wrapup, but I wanted to try to summarize some of the
> recent events (especially NGCC) for those that couldn't attend / didn't
> know it was happening / don't have time to follow every conversation in the
> community.

[ ... ]

I've missed these; Thanks Jeff!


-- 
Eric Evans
john.eric.ev...@gmail.com

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

[VOTE] Release Apache Cassandra 3.0.15

[Michael Shuler]

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:
https://repository.apache.org/content/repositories/orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1150/

The Debian packages are available here: http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) https://goo.gl/RyuPpw
[2]: (NEWS.txt) https://goo.gl/qxwUti

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

Re: Proposal to retroactively mark materialized views experimental

[Jeremiah D Jordan]

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 that adding a flags in the cassandra.yaml 
which prevents their use is the right way to go.  I would propose that we emit 
WARN from the native protocol mechanism when a user does an ALTER/CREATE what 
ever that tries to use an experiment feature, and probably in the system.log as 
well.  So someone who is starting new development using them will get a warning 
showing up in cqlsh “hey the thing you just used is experimental, proceed with 
caution” and also in their logs.

These things are live on clusters right now, and I would not want someone to 
upgrade their cluster to a new *patch* release and suddenly something that may 
have been working for them now does not function.  Anyway, we need to be 
careful about how this gets put into practice if we are going to do it 
retroactively.

-Jeremiah


> On Oct 1, 2017, at 5:36 PM, Josh McKenzie  wrote:
> 
>> 
>> I think committing 8099, or at the very least, parts of it, behind an
>> experimental flag would have been the right thing to do.
> 
> With a major refactor like that, it's a staggering amount of extra work to
> have a parallel re-write of core components of a storage engine accessible
> in parallel to the major based on an experimental flag in the same branch.
> I think the complexity in the code-base of having two such channels in
> parallel would be an altogether different kind of burden along with making
> the work take considerably longer. The argument of modularizing a change
> like that, however, is something I can get behind as a matter of general
> principle. As we discussed at NGCC, the amount of static state in the C*
> code-base makes this an aspirational goal rather than a reality all too
> often, unfortunately.
> 
> Not looking to get into the discussion of the appropriateness of 8099 and
> other major refactors like it (nio MessagingService for instance) - but
> there's a difference between building out new features and shielding the
> code-base and users from their complexity and reliability and refactoring
> core components of the code-base to keep it relevant.
> 
> On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius  wrote:
> 
>> triggers
>> 
>> 
>> On 10/01/2017 11:25 AM, Jeff Jirsa wrote:
>> 
>>> Historical examples are anything that you wouldn’t bet your job on for
>>> the first release:
>>> 
>>> Udf/uda in 2.2
>>> Incremental repair - would have yanked the flag following 9143
>>> SASI - probably still experimental
>>> Counters - all sorts of correctness issues originally, no longer true
>>> since the rewrite in 2.1
>>> Vnodes - or at least shuffle
>>> CDC - is the API going to change or is it good as-is?
>>> CQL - we’re on v3, what’s that say about v1?
>>> 
>>> Basically anything where we can’t definitively say “this feature is going
>>> to work for you, build your product on it” because companies around the
>>> world are trying to make that determination on their own, and they don’t
>>> have the same insight that the active committers have.
>>> 
>>> The transition out we could define as a fixed number of releases or a dev@
>>> vote, I don’t think you’ll find something that applies to all experimental
>>> features, so being flexible is probably the best bet there
>>> 
>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


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

Re: Proposal to retroactively mark materialized views experimental

[Blake Eggleston]

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 emitting a warning 
really reduces visibility where we need it: in the development process.

By only emitting warning, we're just protecting users that don't run even 
rudimentary tests before upgrading their clusters. If an operator is going to 
blindly deploy a database update to prod without testing, they’re going to poke 
their eye out on something anyway. Whether it’s an MV flag or something else. 
If we make this change clear in NEWS.txt, and the user@ list, I think that’s 
the best thing to do.


On October 2, 2017 at 10:18:52 AM, Jeremiah D Jordan 
(jeremiah.jor...@gmail.com) wrote:

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 that adding a flags in the cassandra.yaml 
which prevents their use is the right way to go. I would propose that we emit 
WARN from the native protocol mechanism when a user does an ALTER/CREATE what 
ever that tries to use an experiment feature, and probably in the system.log as 
well.  So someone who is starting new development using them will get a warning 
showing up in cqlsh “hey the thing you just used is experimental, proceed with 
caution” and also in their logs.  

These things are live on clusters right now, and I would not want someone to 
upgrade their cluster to a new *patch* release and suddenly something that may 
have been working for them now does not function. Anyway, we need to be careful 
about how this gets put into practice if we are going to do it retroactively.  

-Jeremiah  


> On Oct 1, 2017, at 5:36 PM, Josh McKenzie  wrote:  
>  
>>  
>> I think committing 8099, or at the very least, parts of it, behind an  
>> experimental flag would have been the right thing to do.  
>  
> With a major refactor like that, it's a staggering amount of extra work to  
> have a parallel re-write of core components of a storage engine accessible  
> in parallel to the major based on an experimental flag in the same branch.  
> I think the complexity in the code-base of having two such channels in  
> parallel would be an altogether different kind of burden along with making  
> the work take considerably longer. The argument of modularizing a change  
> like that, however, is something I can get behind as a matter of general  
> principle. As we discussed at NGCC, the amount of static state in the C*  
> code-base makes this an aspirational goal rather than a reality all too  
> often, unfortunately.  
>  
> Not looking to get into the discussion of the appropriateness of 8099 and  
> other major refactors like it (nio MessagingService for instance) - but  
> there's a difference between building out new features and shielding the  
> code-base and users from their complexity and reliability and refactoring  
> core components of the code-base to keep it relevant.  
>  
> On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius  wrote:  
>  
>> triggers  
>>  
>>  
>> On 10/01/2017 11:25 AM, Jeff Jirsa wrote:  
>>  
>>> Historical examples are anything that you wouldn’t bet your job on for  
>>> the first release:  
>>>  
>>> Udf/uda in 2.2  
>>> Incremental repair - would have yanked the flag following 9143  
>>> SASI - probably still experimental  
>>> Counters - all sorts of correctness issues originally, no longer true  
>>> since the rewrite in 2.1  
>>> Vnodes - or at least shuffle  
>>> CDC - is the API going to change or is it good as-is?  
>>> CQL - we’re on v3, what’s that say about v1?  
>>>  
>>> Basically anything where we can’t definitively say “this feature is going  
>>> to work for you, build your product on it” because companies around the  
>>> world are trying to make that determination on their own, and they don’t  
>>> have the same insight that the active committers have.  
>>>  
>>> The transition out we could define as a fixed number of releases or a dev@  
>>> vote, I don’t think you’ll find something that applies to all experimental  
>>> features, so being flexible is probably the best bet there  
>>>  
>>>  
>>>  
>>  
>> -  
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
>> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>>  
>>  


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

Re: Proposal to retroactively mark materialized views experimental

[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 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:

These things are live on clusters right now, and I would not want someone to 
upgrade their cluster to a new *patch* release and suddenly something that may 
have been working for them now does not function. Anyway, we need to be careful 
about how this gets put into practice if we are going to do it retroactively. 

Re: [VOTE] Release Apache Cassandra 3.0.15

[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:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.15-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1150/  

The Debian packages are available here: http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/RyuPpw  
[2]: (NEWS.txt) https://goo.gl/qxwUti  

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

[VOTE] Release Apache Cassandra 3.11.1

[Michael Shuler]

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:
https://repository.apache.org/content/repositories/orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
Staging repository:
https://repository.apache.org/content/repositories/orgapachecassandra-1151/

The Debian packages are available here: http://people.apache.org/~mshuler

The vote will be open for 72 hours (longer if needed).

[1]: (CHANGES.txt) https://goo.gl/dZCRk8
[2]: (NEWS.txt) https://goo.gl/rh24MX

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

Re: Proposal to retroactively mark materialized views experimental

[Jon Haddad]

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 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 
> emitting a warning really reduces visibility where we need it: in the 
> development process.
> 
> By only emitting warning, we're just protecting users that don't run even 
> rudimentary tests before upgrading their clusters. If an operator is going to 
> blindly deploy a database update to prod without testing, they’re going to 
> poke their eye out on something anyway. Whether it’s an MV flag or something 
> else. If we make this change clear in NEWS.txt, and the user@ list, I think 
> that’s the best thing to do.
> 
> 
> On October 2, 2017 at 10:18:52 AM, Jeremiah D Jordan 
> (jeremiah.jor...@gmail.com) wrote:
> 
> 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 that adding a flags in the cassandra.yaml 
> which prevents their use is the right way to go. I would propose that we emit 
> WARN from the native protocol mechanism when a user does an ALTER/CREATE what 
> ever that tries to use an experiment feature, and probably in the system.log 
> as well.  So someone who is starting new development using them will get a 
> warning showing up in cqlsh “hey the thing you just used is experimental, 
> proceed with caution” and also in their logs.  
> 
> These things are live on clusters right now, and I would not want someone to 
> upgrade their cluster to a new *patch* release and suddenly something that 
> may have been working for them now does not function. Anyway, we need to be 
> careful about how this gets put into practice if we are going to do it 
> retroactively.  
> 
> -Jeremiah  
> 
> 
>> On Oct 1, 2017, at 5:36 PM, Josh McKenzie  wrote:  
>> 
>>> 
>>> I think committing 8099, or at the very least, parts of it, behind an  
>>> experimental flag would have been the right thing to do.  
>> 
>> With a major refactor like that, it's a staggering amount of extra work to  
>> have a parallel re-write of core components of a storage engine accessible  
>> in parallel to the major based on an experimental flag in the same branch.  
>> I think the complexity in the code-base of having two such channels in  
>> parallel would be an altogether different kind of burden along with making  
>> the work take considerably longer. The argument of modularizing a change  
>> like that, however, is something I can get behind as a matter of general  
>> principle. As we discussed at NGCC, the amount of static state in the C*  
>> code-base makes this an aspirational goal rather than a reality all too  
>> often, unfortunately.  
>> 
>> Not looking to get into the discussion of the appropriateness of 8099 and  
>> other major refactors like it (nio MessagingService for instance) - but  
>> there's a difference between building out new features and shielding the  
>> code-base and users from their complexity and reliability and refactoring  
>> core components of the code-base to keep it relevant.  
>> 
>> On Sun, Oct 1, 2017 at 5:01 PM, Dave Brosius  wrote:  
>> 
>>> triggers  
>>> 
>>> 
>>> On 10/01/2017 11:25 AM, Jeff Jirsa wrote:  
>>> 
 Historical examples are anything that you wouldn’t bet your job on for  
 the first release:  
 
 Udf/uda in 2.2  
 Incremental repair - would have yanked the flag following 9143  
 SASI - probably still experimental  
 Counters - all sorts of correctness issues originally, no longer true  
 since the rewrite in 2.1  
 Vnodes - or at least shuffle  
 CDC - is the API going to change or is it good as-is?  
 CQL - we’re on v3, what’s that say about v1?  
 
 Basically anything where we can’t definitively say “this feature is going  
 to work for you, build your product on it” because companies around the  
 world are trying to make that determination on their own, and they don’t  
 have the same insight that the active committers have.  
 
 The transition out we could define as a fixed number of releases or a dev@ 
  
 vote, I don’t think you’ll find something that applies to all experimental 
  
 features, so being flexible is probably the best bet there  
 
 
 
>>> 
>>> -  
>>> To unsubscribe, e

Re: [VOTE] Release Apache Cassandra 3.0.15

[Brandon Williams]

+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:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.15-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1150/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RyuPpw
> [2]: (NEWS.txt) https://goo.gl/qxwUti
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.15

[Jon Haddad]

+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 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:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
>> Staging repository:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1150/
>> 
>> The Debian packages are available here: http://people.apache.org/~mshuler
>> 
>> The vote will be open for 72 hours (longer if needed).
>> 
>> [1]: (CHANGES.txt) https://goo.gl/RyuPpw
>> [2]: (NEWS.txt) https://goo.gl/qxwUti
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


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

Re: Proposal to retroactively mark materialized views experimental

[Blake Eggleston]

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 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 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
wrote:  

These things are live on clusters right now, and I would not want someone to 
upgrade their cluster to a new *patch* release and suddenly something that may 
have been working for them now does not function. Anyway, we need to be careful 
about how this gets put into practice if we are going to do it retroactively. 

Re: [VOTE] Release Apache Cassandra 3.11.1

[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:  
http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.1-tentative
  
Artifacts:  
https://repository.apache.org/content/repositories/orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
  
Staging repository:  
https://repository.apache.org/content/repositories/orgapachecassandra-1151/  

The Debian packages are available here: http://people.apache.org/~mshuler  

The vote will be open for 72 hours (longer if needed).  

[1]: (CHANGES.txt) https://goo.gl/dZCRk8  
[2]: (NEWS.txt) https://goo.gl/rh24MX  

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

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jason Brown]

+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:
>
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.1-tentative
> Artifacts:
>
> https://repository.apache.org/content/repositories/orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1151/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> [2]: (NEWS.txt) https://goo.gl/rh24MX
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.15

[Jason Brown]

+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 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:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.0.15-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1150/
> >>
> >> The Debian packages are available here:
> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/RyuPpw
> >> [2]: (NEWS.txt) https://goo.gl/qxwUti
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jeff Jirsa]

+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: 983c72a84ab6628e09a78ead9e20a0c323a005af
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.1-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> [2]: (NEWS.txt) https://goo.gl/rh24MX
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.0.15

[Jeff Jirsa]

+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=
> shortlog;h=refs/tags/3.0.15-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1150/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RyuPpw
> [2]: (NEWS.txt) https://goo.gl/qxwUti
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jon Haddad]

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, 2017, at 11:01 AM, 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:  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.11.1-tentative
>   
> Artifacts:  
> https://repository.apache.org/content/repositories/orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
>   
> Staging repository:  
> https://repository.apache.org/content/repositories/orgapachecassandra-1151/  
> 
> The Debian packages are available here: http://people.apache.org/~mshuler  
> 
> The vote will be open for 72 hours (longer if needed).  
> 
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8  
> [2]: (NEWS.txt) https://goo.gl/rh24MX  
> 
> -  
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
> 

Re: Proposal to retroactively mark materialized views experimental

[Jeremiah D Jordan]

> 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 experimental feature 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 that 
is using them currently, even with all the edge cases issues they have now.

-Jeremiah


> On Oct 2, 2017, at 2:01 PM, Blake Eggleston  wrote:
> 
> 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 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 18:18:52, Jeremiah D Jordan (jeremiah.jor...@gmail.com) 
> wrote:  
> 
> These things are live on clusters right now, and I would not want someone to 
> upgrade their cluster to a new *patch* release and suddenly something that 
> may have been working for them now does not function. Anyway, we need to be 
> careful about how this gets put into practice if we are going to do it 
> retroactively. 


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

Re: Proposal to retroactively mark materialized views experimental

[DuyHai Doan]

"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 when do we start removing feature in a patch release ? (forbidding to
create new MV == removing the feature, defacto)

Even the Thrift protocol has gone through a long process of deprecation and
will be removed on 4.0

And if we start opening the Pandora box like this, what's next ? Forbidding
to create SASI index too ? Removing Vnodes ?




On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan  wrote:

> > 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 experimental feature 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 that is using them currently, even with all the edge cases issues
> they have now.
>
> -Jeremiah
>
>
> > On Oct 2, 2017, at 2:01 PM, Blake Eggleston 
> wrote:
> >
> > 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 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 18:18:52, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com) wrote:
> >
> > These things are live on clusters right now, and I would not want
> someone to upgrade their cluster to a new *patch* release and suddenly
> something that may have been working for them now does not function.
> Anyway, we need to be careful about how this gets put into practice if we
> are going to do it retroactively.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: [VOTE] Release Apache Cassandra 3.11.1

[Brandon Williams]

+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=
> shortlog;h=refs/tags/3.11.1-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> [2]: (NEWS.txt) https://goo.gl/rh24MX
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Proposal to retroactively mark materialized views experimental

[Jon Haddad]

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 explicit option 
because they really aren’t ready for general use.

Claiming disabling by default == removal is not helpful to the conversation and 
is very misleading.  

Let’s be practical here.  The people that are most likely to put MVs in 
production right now are people new to Cassandra that don’t know any better.  
The people that *should* be using MVs are the contributors to the project.  
People that actually wrote Cassandra code that can do a patch and push it into 
prod, and get it submitted upstream when they fix something.  Yes, a lot of 
this stuff requires production usage to shake out the bugs, that’s fine, but we 
shouldn’t lie to people and say “feature X is ready” when it’s not.  That’s a 
great way to get a reputation as “unstable” or “not fit for production."

Jon


> On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:
> 
> "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 when do we start removing feature in a patch release ? (forbidding to
> create new MV == removing the feature, defacto)
> 
> Even the Thrift protocol has gone through a long process of deprecation and
> will be removed on 4.0
> 
> And if we start opening the Pandora box like this, what's next ? Forbidding
> to create SASI index too ? Removing Vnodes ?
> 
> 
> 
> 
> On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan > wrote:
> 
>>> 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 experimental feature 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 that is using them currently, even with all the edge cases issues
>> they have now.
>> 
>> -Jeremiah
>> 
>> 
>>> On Oct 2, 2017, at 2:01 PM, Blake Eggleston 
>> wrote:
>>> 
>>> 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 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 18:18:52, Jeremiah D Jordan (
>> jeremiah.jor...@gmail.com) wrote:
>>> 
>>> These things are live on clusters right now, and I would not want
>> someone to upgrade their cluster to a new *patch* release and suddenly
>> something that may have been working for them now does not function.
>> Anyway, we need to be careful about how this gets put into practice if we
>> are going to do it retroactively.
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> 


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

Re: Proposal to retroactively mark materialized views experimental

[DuyHai Doan]

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 disabled, to enable it, turn on the flag  in
cassandra.yaml" so users don't spend 3h searching around


On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:

> 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
> explicit option because they really aren’t ready for general use.
>
> Claiming disabling by default == removal is not helpful to the
> conversation and is very misleading.
>
> Let’s be practical here.  The people that are most likely to put MVs in
> production right now are people new to Cassandra that don’t know any
> better.  The people that *should* be using MVs are the contributors to the
> project.  People that actually wrote Cassandra code that can do a patch and
> push it into prod, and get it submitted upstream when they fix something.
> Yes, a lot of this stuff requires production usage to shake out the bugs,
> that’s fine, but we shouldn’t lie to people and say “feature X is ready”
> when it’s not.  That’s a great way to get a reputation as “unstable” or
> “not fit for production."
>
> Jon
>
>
> > On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:
> >
> > "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 when do we start removing feature in a patch release ? (forbidding
> to
> > create new MV == removing the feature, defacto)
> >
> > Even the Thrift protocol has gone through a long process of deprecation
> and
> > will be removed on 4.0
> >
> > And if we start opening the Pandora box like this, what's next ?
> Forbidding
> > to create SASI index too ? Removing Vnodes ?
> >
> >
> >
> >
> > On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <
> jeremiah.jor...@gmail.com
> >> wrote:
> >
> >>> 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 experimental feature 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 that is using them currently, even with all the edge cases
> issues
> >> they have now.
> >>
> >> -Jeremiah
> >>
> >>
> >>> On Oct 2, 2017, at 2:01 PM, Blake Eggleston 
> >> wrote:
> >>>
> >>> 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 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 18:18:52, Jeremiah D Jordan (
> >> jeremiah.jor...@gmail.com) wrote:
> >>>
> >>> These things are live on clusters right now, and I would not want
> >> someone to upgrade their cluster to a new *patch* release and suddenly
> >> something that may have been working for them now does not function.
> >> Anyway, we need to be careful about how this gets put into practice if
> we
> >> are going to do it retroactively.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

RE: [VOTE] Release Apache Cassandra 3.11.1

[Steinmaurer, Thomas]

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 loadtest 
environment, in case this issue gets attention and a fix needs verification at 
constant load.

Thanks,
Thomas

-Original Message-
From: Jeff Jirsa [mailto:jji...@gmail.com]
Sent: Montag, 02. Oktober 2017 20:04
To: Cassandra DEV 
Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.11.1-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> Staging repository:
> https://repository.apache.org/content/repositories/
> orgapachecassandra-1151/
>
> The Debian packages are available here:
> http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> [2]: (NEWS.txt) https://goo.gl/rh24MX
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

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

RE: [VOTE] Release Apache Cassandra 3.11.1

[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 2017 at 20:54:38, Steinmaurer, Thomas 
(thomas.steinmau...@dynatrace.com) wrote:

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 loadtest 
environment, in case this issue gets attention and a fix needs verification at 
constant load.  

Thanks,  
Thomas  

-Original Message-  
From: Jeff Jirsa [mailto:jji...@gmail.com]  
Sent: Montag, 02. Oktober 2017 20:04  
To: Cassandra DEV   
Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af  
> Git:  
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=  
> shortlog;h=refs/tags/3.11.1-tentative  
> Artifacts:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/  
> Staging repository:  
> https://repository.apache.org/content/repositories/  
> orgapachecassandra-1151/  
>  
> The Debian packages are available here:  
> http://people.apache.org/~mshuler  
>  
> The vote will be open for 72 hours (longer if needed).  
>  
> [1]: (CHANGES.txt) https://goo.gl/dZCRk8  
> [2]: (NEWS.txt) https://goo.gl/rh24MX  
>  
> -  
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>  
>  
The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313  

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

Re: [VOTE] Release Apache Cassandra 3.0.15

[Josh McKenzie]

+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:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> > shortlog;h=refs/tags/3.0.15-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> > orgapachecassandra-1150/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/RyuPpw
> > [2]: (NEWS.txt) https://goo.gl/qxwUti
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jon Haddad]

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 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 2017 at 20:54:38, Steinmaurer, Thomas 
> (thomas.steinmau...@dynatrace.com) wrote:
> 
> 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 loadtest 
> environment, in case this issue gets attention and a fix needs verification 
> at constant load.  
> 
> Thanks,  
> Thomas  
> 
> -Original Message-  
> From: Jeff Jirsa [mailto:jji...@gmail.com]  
> Sent: Montag, 02. Oktober 2017 20:04  
> To: Cassandra DEV   
> Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af  
>> Git:  
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=  
>> shortlog;h=refs/tags/3.11.1-tentative  
>> Artifacts:  
>> https://repository.apache.org/content/repositories/  
>> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/  
>> Staging repository:  
>> https://repository.apache.org/content/repositories/  
>> orgapachecassandra-1151/  
>> 
>> The Debian packages are available here:  
>> http://people.apache.org/~mshuler  
>> 
>> The vote will be open for 72 hours (longer if needed).  
>> 
>> [1]: (CHANGES.txt) https://goo.gl/dZCRk8  
>> [2]: (NEWS.txt) https://goo.gl/rh24MX  
>> 
>> -  
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
>> For additional commands, e-mail: dev-h...@cassandra.apache.org  
>> 
>> 
> The contents of this e-mail are intended for the named addressee only. It 
> contains information that may be confidential. Unless you are the named 
> addressee or an authorized designee, you may not copy or use it, or disclose 
> it to anyone else. If you received it in error please notify us immediately 
> and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) 
> is a company registered in Linz whose registered office is at 4040 Linz, 
> Austria, Freistädterstraße 313  
> 
> -  
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org  
> For additional commands, e-mail: dev-h...@cassandra.apache.org  
> 


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

Re: Proposal to retroactively mark materialized views experimental

[Josh McKenzie]

"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 than barfing a
warning on someone's screen during the dev process when they use the DDL
for MV's. At the end of the day, it's just a question of how forceful you
want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT
READY' in big bold letters, that's not going to miscommunicate to a user
that 'feature X is ready' when it's not.

Much like w/SASI, this is something that's in the code-base that for
certain use-cases apparently works just fine. Might be worth considering
the approach of making boundaries around those use-cases more rigid instead
of throwing the baby out with the bathwater.

On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:

> 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 disabled, to enable it, turn on the flag  in
> cassandra.yaml" so users don't spend 3h searching around
>
>
> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:
>
> > 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
> > explicit option because they really aren’t ready for general use.
> >
> > Claiming disabling by default == removal is not helpful to the
> > conversation and is very misleading.
> >
> > Let’s be practical here.  The people that are most likely to put MVs in
> > production right now are people new to Cassandra that don’t know any
> > better.  The people that *should* be using MVs are the contributors to
> the
> > project.  People that actually wrote Cassandra code that can do a patch
> and
> > push it into prod, and get it submitted upstream when they fix something.
> > Yes, a lot of this stuff requires production usage to shake out the bugs,
> > that’s fine, but we shouldn’t lie to people and say “feature X is ready”
> > when it’s not.  That’s a great way to get a reputation as “unstable” or
> > “not fit for production."
> >
> > Jon
> >
> >
> > > On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:
> > >
> > > "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 when do we start removing feature in a patch release ?
> (forbidding
> > to
> > > create new MV == removing the feature, defacto)
> > >
> > > Even the Thrift protocol has gone through a long process of deprecation
> > and
> > > will be removed on 4.0
> > >
> > > And if we start opening the Pandora box like this, what's next ?
> > Forbidding
> > > to create SASI index too ? Removing Vnodes ?
> > >
> > >
> > >
> > >
> > > On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <
> > jeremiah.jor...@gmail.com
> > >> wrote:
> > >
> > >>> 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 experimental feature 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 that is using them currently, even with all the edge cases
> > issues
> > >> they have now.
> > >>
> > >> -Jeremiah
> > >>
> > >>
> > >>> On Oct 2, 2017, at 2:01 PM, Blake Eggleston 
> > >> wrote:
> > >>>
> > >>> 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 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 18:18:52, Jeremiah D Jordan (
> > >> jeremiah.jor...@gmail.com) wrote:
> > >>>

RE: [VOTE] Release Apache Cassandra 3.11.1

[Steinmaurer, Thomas]

Jon,

please see my latest comment + attached screen from our monitoring here: 
https://issues.apache.org/jira/browse/CASSANDRA-13754?focusedCommentId=16188758&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16188758

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: dev@cassandra.apache.org
Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas 
> (thomas.steinmau...@dynatrace.com) wrote:
>
> 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 loadtest 
> environment, in case this issue gets attention and a fix needs verification 
> at constant load.
>
> Thanks,
> Thomas
>
> -Original Message-
> From: Jeff Jirsa [mailto:jji...@gmail.com]
> Sent: Montag, 02. Oktober 2017 20:04
> To: Cassandra DEV 
> Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
>> Git:
>> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
>> shortlog;h=refs/tags/3.11.1-tentative
>> Artifacts:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
>> Staging repository:
>> https://repository.apache.org/content/repositories/
>> orgapachecassandra-1151/
>>
>> The Debian packages are available here:
>> http://people.apache.org/~mshuler
>>
>> The vote will be open for 72 hours (longer if needed).
>>
>> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
>> [2]: (NEWS.txt) https://goo.gl/rh24MX
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>
>>
> The contents of this e-mail are intended for the named addressee only. It 
> contains information that may be confidential. Unless you are the named 
> addressee or an authorized designee, you may not copy or use it, or disclose 
> it to anyone else. If you received it in error please notify us immediately 
> and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) 
> is a company registered in Linz whose registered office is at 4040 Linz, 
> Austria, Freistädterstraße 313
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>


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

The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose it 
to anyone else. If you received it in error please notify us immediately and 
then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a 
company registered in Linz whose registered office is at 4040 Linz, Austria, 
Freistädterstraße 313

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jeff Jirsa]

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 is a regression, I'll flip my vote to -1.



On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas <
thomas.steinmau...@dynatrace.com> wrote:

> Jon,
>
> please see my latest comment + attached screen from our monitoring here:
> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> focusedCommentId=16188758&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>
> 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: dev@cassandra.apache.org
> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
> thomas.steinmau...@dynatrace.com) wrote:
> >
> > 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 loadtest
> environment, in case this issue gets attention and a fix needs verification
> at constant load.
> >
> > Thanks,
> > Thomas
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: Montag, 02. Oktober 2017 20:04
> > To: Cassandra DEV 
> > Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
> >> Git:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.11.1-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/
> >>
> >> The Debian packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> >> [2]: (NEWS.txt) https://goo.gl/rh24MX
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it. Dynatrace Austria GmbH (registration
> number FN 91482h) is a company registered in Linz whose registered office
> is at 4040 Linz, Austria, Freistädterstraße 313
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
> disclose it to anyone else. If you received it in error please notify us
> immediately and then destroy it. Dynatrace Austria GmbH (registration
> number FN 91482h) is a company registered in Linz whose registered office
> is at 4040 Linz, Austria, Freistädterstraße 313
>

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jeremiah D Jordan]

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 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 is a regression, I'll flip my vote to -1.
> 
> 
> 
> On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas <
> thomas.steinmau...@dynatrace.com> wrote:
> 
>> Jon,
>> 
>> please see my latest comment + attached screen from our monitoring here:
>> https://issues.apache.org/jira/browse/CASSANDRA-13754?
>> focusedCommentId=16188758&page=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>> 
>> 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: dev@cassandra.apache.org
>> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
>> thomas.steinmau...@dynatrace.com) wrote:
>>> 
>>> 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 loadtest
>> environment, in case this issue gets attention and a fix needs verification
>> at constant load.
>>> 
>>> Thanks,
>>> Thomas
>>> 
>>> -Original Message-
>>> From: Jeff Jirsa [mailto:jji...@gmail.com]
>>> Sent: Montag, 02. Oktober 2017 20:04
>>> To: Cassandra DEV 
>>> Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
 Git:
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
 shortlog;h=refs/tags/3.11.1-tentative
 Artifacts:
 https://repository.apache.org/content/repositories/
 orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
 Staging repository:
 https://repository.apache.org/content/repositories/
 orgapachecassandra-1151/
 
 The Debian packages are available here:
 http://people.apache.org/~mshuler
 
 The vote will be open for 72 hours (longer if needed).
 
 [1]: (CHANGES.txt) https://goo.gl/dZCRk8
 [2]: (NEWS.txt) https://goo.gl/rh24MX
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> The contents of this e-mail are intended for the named addressee only.
>> It contains information that may be confidential. Unless you are the named
>> addressee or an authorized designee, you may not copy or use it, or
>> disclose it to anyone else. If you received it in error please notify us
>> immediately and then destroy it. Dynatrace Austria GmbH (registration
>> number FN 91482h) is a company registered in Linz whose registered office
>> is at 4040 Linz, Austria, Freistädterstraße 313
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>> 
>> The contents of this e-mail are intended for the named addressee only. It
>> contains information that may be confidential. Unless you are the named
>> addressee or an authorized designee, you may not copy or use it, or
>> disclose it to anyone else. If you received it in error please notify us
>> immediately and then destroy it. Dynatrace Austria GmbH (registratio

Re: [VOTE] Release Apache Cassandra 3.11.1

[Jeff Jirsa]

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  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 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 is a regression, I'll flip my vote to -1.
> >
> >
> >
> > On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas <
> > thomas.steinmau...@dynatrace.com> wrote:
> >
> >> Jon,
> >>
> >> please see my latest comment + attached screen from our monitoring here:
> >> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> >> focusedCommentId=16188758&page=com.atlassian.jira.
> >> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
> >>
> >> 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: dev@cassandra.apache.org
> >> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
> >> thomas.steinmau...@dynatrace.com) wrote:
> >>>
> >>> 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 loadtest
> >> environment, in case this issue gets attention and a fix needs
> verification
> >> at constant load.
> >>>
> >>> Thanks,
> >>> Thomas
> >>>
> >>> -Original Message-
> >>> From: Jeff Jirsa [mailto:jji...@gmail.com]
> >>> Sent: Montag, 02. Oktober 2017 20:04
> >>> To: Cassandra DEV 
> >>> Subject: 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 <
> mich...@pbandjelly.org>
> >>> 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=
>  shortlog;h=refs/tags/3.11.1-tentative
>  Artifacts:
>  https://repository.apache.org/content/repositories/
>  orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.1/
>  Staging repository:
>  https://repository.apache.org/content/repositories/
>  orgapachecassandra-1151/
> 
>  The Debian packages are available here:
>  http://people.apache.org/~mshuler
> 
>  The vote will be open for 72 hours (longer if needed).
> 
>  [1]: (CHANGES.txt) https://goo.gl/dZCRk8
>  [2]: (NEWS.txt) https://goo.gl/rh24MX
> 
>  -
>  To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>  For additional commands, e-mail: dev-h...@cassandra.apache.org
> 
> 
> >>> The contents of this e-mail are intended for the named addressee only.
> >> It contains information that may be confidential. Unless you are the
> named
> >> addressee or an authorized designee, you may not copy or use it, or
> >> disclose it to anyone else. If you received it in error please notify us
> >> immediately and then destroy it. Dynatrace Austria GmbH (registration
> >> number FN 91482h) is a company registered in Linz whose registered
> office
> >> is at 4040 Linz, Austria, Freistädterstraße 313
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional

RE: [VOTE] Release Apache Cassandra 3.11.1

[Steinmaurer, Thomas]

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 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 is a regression, I'll flip my vote to -1.



On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
thomas.steinmau...@dynatrace.com> wrote:

> Jon,
>
> please see my latest comment + attached screen from our monitoring here:
> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> focusedCommentId=16188758&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>
> 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: dev@cassandra.apache.org
> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
> thomas.steinmau...@dynatrace.com) wrote:
> >
> > 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 loadtest
> environment, in case this issue gets attention and a fix needs
> verification at constant load.
> >
> > Thanks,
> > Thomas
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: Montag, 02. Oktober 2017 20:04
> > To: Cassandra DEV 
> > Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
> >> Git:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.11.1-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
> >> 1/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/
> >>
> >> The Debian packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> >> [2]: (NEWS.txt) https://goo.gl/rh24MX
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it. Dynatrace Austria GmbH
> (registration number FN 91482h) is a company registered in Linz whose
> registered office is at 4040 Linz, Austria, Freistädterstraße 313
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it. Dynatrace Austria GmbH
> (registration number FN 91482h) is a company registered in Linz whose
> registered office is at 4040 Linz, Aust

RE: [VOTE] Release Apache Cassandra 3.11.1

[Steinmaurer, Thomas]

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.

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 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 is a regression, I'll flip my vote to -1.



On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
thomas.steinmau...@dynatrace.com> wrote:

> Jon,
>
> please see my latest comment + attached screen from our monitoring here:
> https://issues.apache.org/jira/browse/CASSANDRA-13754?
> focusedCommentId=16188758&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>
> 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: dev@cassandra.apache.org
> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
> thomas.steinmau...@dynatrace.com) wrote:
> >
> > 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 loadtest
> environment, in case this issue gets attention and a fix needs
> verification at constant load.
> >
> > Thanks,
> > Thomas
> >
> > -Original Message-
> > From: Jeff Jirsa [mailto:jji...@gmail.com]
> > Sent: Montag, 02. Oktober 2017 20:04
> > To: Cassandra DEV 
> > Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
> >> Git:
> >> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> >> shortlog;h=refs/tags/3.11.1-tentative
> >> Artifacts:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
> >> 1/
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/
> >> orgapachecassandra-1151/
> >>
> >> The Debian packages are available here:
> >> http://people.apache.org/~mshuler
> >>
> >> The vote will be open for 72 hours (longer if needed).
> >>
> >> [1]: (CHANGES.txt) https://goo.gl/dZCRk8
> >> [2]: (NEWS.txt) https://goo.gl/rh24MX
> >>
> >> ---
> >> -- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
> > The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it,
> or disclose it to anyone else. If you received it in error please
> notify us immediately and then destroy it. Dynatrace Austria GmbH
> (registration number FN 91482h) is a company registered in Linz whose
> registered office is at 4040 Linz, Austria, Freistädterstraße 313
> >
> > 
> > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> The contents of this e-mail are intended for the named addressee only.
> It contains information that may be confidential. Unless you are the
> named addressee or an authorized designee, you may not copy or use it

Re: Proposal to retroactively mark materialized views experimental

[Blake Eggleston]

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 happened to me. 
Requiring a flag will reach everyone trying to use MVs as soon as they start 
developing against MVs. Logging a warning will reach a subset of users at some 
point, hopefully. The only downside I can think of for the flag is that it's 
not as polite.

On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org) wrote:

"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 than barfing a  
warning on someone's screen during the dev process when they use the DDL  
for MV's. At the end of the day, it's just a question of how forceful you  
want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT  
READY' in big bold letters, that's not going to miscommunicate to a user  
that 'feature X is ready' when it's not.  

Much like w/SASI, this is something that's in the code-base that for  
certain use-cases apparently works just fine. Might be worth considering  
the approach of making boundaries around those use-cases more rigid instead  
of throwing the baby out with the bathwater.  

On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:  

> 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 disabled, to enable it, turn on the flag  in  
> cassandra.yaml" so users don't spend 3h searching around  
>  
>  
> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:  
>  
> > 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  
> > explicit option because they really aren’t ready for general use.  
> >  
> > Claiming disabling by default == removal is not helpful to the  
> > conversation and is very misleading.  
> >  
> > Let’s be practical here. The people that are most likely to put MVs in  
> > production right now are people new to Cassandra that don’t know any  
> > better. The people that *should* be using MVs are the contributors to  
> the  
> > project. People that actually wrote Cassandra code that can do a patch  
> and  
> > push it into prod, and get it submitted upstream when they fix something.  
> > Yes, a lot of this stuff requires production usage to shake out the bugs,  
> > that’s fine, but we shouldn’t lie to people and say “feature X is ready”  
> > when it’s not. That’s a great way to get a reputation as “unstable” or  
> > “not fit for production."  
> >  
> > Jon  
> >  
> >  
> > > On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:  
> > >  
> > > "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 when do we start removing feature in a patch release ?  
> (forbidding  
> > to  
> > > create new MV == removing the feature, defacto)  
> > >  
> > > Even the Thrift protocol has gone through a long process of deprecation  
> > and  
> > > will be removed on 4.0  
> > >  
> > > And if we start opening the Pandora box like this, what's next ?  
> > Forbidding  
> > > to create SASI index too ? Removing Vnodes ?  
> > >  
> > >  
> > >  
> > >  
> > > On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <  
> > jeremiah.jor...@gmail.com  
> > >> wrote:  
> > >  
> > >>> 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 experimental feature 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 that is using them currently, even with all th

Re: Proposal to retroactively mark materialized views experimental

[Jon Haddad]

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  wrote:
> 
> 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 happened 
> to me. Requiring a flag will reach everyone trying to use MVs as soon as they 
> start developing against MVs. Logging a warning will reach a subset of users 
> at some point, hopefully. The only downside I can think of for the flag is 
> that it's not as polite.
> 
> On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org) wrote:
> 
> "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 than barfing a  
> warning on someone's screen during the dev process when they use the DDL  
> for MV's. At the end of the day, it's just a question of how forceful you  
> want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT  
> READY' in big bold letters, that's not going to miscommunicate to a user  
> that 'feature X is ready' when it's not.  
> 
> Much like w/SASI, this is something that's in the code-base that for  
> certain use-cases apparently works just fine. Might be worth considering  
> the approach of making boundaries around those use-cases more rigid instead  
> of throwing the baby out with the bathwater.  
> 
> On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:  
> 
>> 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 disabled, to enable it, turn on the flag  in  
>> cassandra.yaml" so users don't spend 3h searching around  
>> 
>> 
>> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:  
>> 
>>> 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  
>>> explicit option because they really aren’t ready for general use.  
>>> 
>>> Claiming disabling by default == removal is not helpful to the  
>>> conversation and is very misleading.  
>>> 
>>> Let’s be practical here. The people that are most likely to put MVs in  
>>> production right now are people new to Cassandra that don’t know any  
>>> better. The people that *should* be using MVs are the contributors to  
>> the  
>>> project. People that actually wrote Cassandra code that can do a patch  
>> and  
>>> push it into prod, and get it submitted upstream when they fix something.  
>>> Yes, a lot of this stuff requires production usage to shake out the bugs,  
>>> that’s fine, but we shouldn’t lie to people and say “feature X is ready”  
>>> when it’s not. That’s a great way to get a reputation as “unstable” or  
>>> “not fit for production."  
>>> 
>>> Jon  
>>> 
>>> 
 On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:  
 
 "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 when do we start removing feature in a patch release ?  
>> (forbidding  
>>> to  
 create new MV == removing the feature, defacto)  
 
 Even the Thrift protocol has gone through a long process of deprecation  
>>> and  
 will be removed on 4.0  
 
 And if we start opening the Pandora box like this, what's next ?  
>>> Forbidding  
 to create SASI index too ? Removing Vnodes ?  
 
 
 
 
 On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <  
>>> jeremiah.jor...@gmail.com  
> wrote:  
 
>> 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

[Jon Haddad]

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]
> 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.
> 
> 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 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 is a regression, I'll flip my vote to -1.
> 
> 
> 
> On Mon, Oct 2, 2017 at 1:29 PM, Steinmaurer, Thomas < 
> thomas.steinmau...@dynatrace.com> wrote:
> 
>> Jon,
>> 
>> please see my latest comment + attached screen from our monitoring here:
>> https://issues.apache.org/jira/browse/CASSANDRA-13754?
>> focusedCommentId=16188758&page=com.atlassian.jira.
>> plugin.system.issuetabpanels:comment-tabpanel#comment-16188758
>> 
>> 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: dev@cassandra.apache.org
>> Subject: 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 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 2017 at 20:54:38, Steinmaurer, Thomas (
>> thomas.steinmau...@dynatrace.com) wrote:
>>> 
>>> 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 loadtest
>> environment, in case this issue gets attention and a fix needs
>> verification at constant load.
>>> 
>>> Thanks,
>>> Thomas
>>> 
>>> -Original Message-
>>> From: Jeff Jirsa [mailto:jji...@gmail.com]
>>> Sent: Montag, 02. Oktober 2017 20:04
>>> To: Cassandra DEV 
>>> Subject: 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: 983c72a84ab6628e09a78ead9e20a0c323a005af
 Git:
 http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
 shortlog;h=refs/tags/3.11.1-tentative
 Artifacts:
 https://repository.apache.org/content/repositories/
 orgapachecassandra-1151/org/apache/cassandra/apache-cassandra/3.11.
 1/
 Staging repository:
 https://repository.apache.org/content/repositories/
 orgapachecassandra-1151/
 
 The Debian packages are available here:
 http://people.apache.org/~mshuler
 
 The vote will be open for 72 hours (longer if needed).
 
 [1]: (CHANGES.txt) https://goo.gl/dZCRk8
 [2]: (NEWS.txt) https://goo.gl/rh24MX
 
 ---
 -- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
 For additional commands, e-mail: dev-h...@cassandra.apache.org
 
 
>>> The contents of this e-mail are intended for the named addressee only.
>> It contains information that may be confidential. Unless you are the
>> named addressee or an authorized designee, you may not copy or use it,
>> or disclose it to anyone else. If you received it in error please
>> notify us immediately and then destroy it. Dynatrace Austria GmbH
>> (registration number FN 91482h) is a company registered in Linz whose
>> registered office is at 4040 Linz, Austria, Freistädterstraße 313
>>> 
>>> 
>>> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
>> For additional comma

Re: Proposal to retroactively mark materialized views experimental

[Aleksey Yeshchenko]

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 cqlsh - for the developers.

And no, we aren’t talking about throwing them out. But if we don’t manage to 
address its issues in a couple releases, then we should at least consider it 
eventually? At least https://issues.apache.org/jira/browse/CASSANDRA-10346 
needs to be addressed IMO.

—
AY

On 2 October 2017 at 21:16:17, Josh McKenzie (jmcken...@apache.org) wrote:

"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 than barfing a  
warning on someone's screen during the dev process when they use the DDL  
for MV's. At the end of the day, it's just a question of how forceful you  
want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT  
READY' in big bold letters, that's not going to miscommunicate to a user  
that 'feature X is ready' when it's not.  

Much like w/SASI, this is something that's in the code-base that for  
certain use-cases apparently works just fine. Might be worth considering  
the approach of making boundaries around those use-cases more rigid instead  
of throwing the baby out with the bathwater.  

On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:  

> 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 disabled, to enable it, turn on the flag  in  
> cassandra.yaml" so users don't spend 3h searching around  
>  
>  
> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:  
>  
> > 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  
> > explicit option because they really aren’t ready for general use.  
> >  
> > Claiming disabling by default == removal is not helpful to the  
> > conversation and is very misleading.  
> >  
> > Let’s be practical here. The people that are most likely to put MVs in  
> > production right now are people new to Cassandra that don’t know any  
> > better. The people that *should* be using MVs are the contributors to  
> the  
> > project. People that actually wrote Cassandra code that can do a patch  
> and  
> > push it into prod, and get it submitted upstream when they fix something.  
> > Yes, a lot of this stuff requires production usage to shake out the bugs,  
> > that’s fine, but we shouldn’t lie to people and say “feature X is ready”  
> > when it’s not. That’s a great way to get a reputation as “unstable” or  
> > “not fit for production."  
> >  
> > Jon  
> >  
> >  
> > > On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:  
> > >  
> > > "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 when do we start removing feature in a patch release ?  
> (forbidding  
> > to  
> > > create new MV == removing the feature, defacto)  
> > >  
> > > Even the Thrift protocol has gone through a long process of deprecation  
> > and  
> > > will be removed on 4.0  
> > >  
> > > And if we start opening the Pandora box like this, what's next ?  
> > Forbidding  
> > > to create SASI index too ? Removing Vnodes ?  
> > >  
> > >  
> > >  
> > >  
> > > On Mon, Oct 2, 2017 at 8:16 PM, Jeremiah D Jordan <  
> > jeremiah.jor...@gmail.com  
> > >> wrote:  
> > >  
> > >>> 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 experimental feature 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 that is using the

Re: Proposal to retroactively mark materialized views experimental

[Jeremiah D Jordan]

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 


For example for SASI it would look something like:


cqlsh:ks> CREATE CUSTOM INDEX ON sasi_table (c) USING 
'org.apache.cassandra.index.sasi.SASIIndex';

Warnings :
A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental, take 
extra caution when using it in production.

cqlsh:ks>

-Jeremiah

> On Oct 2, 2017, at 5:05 PM, Blake Eggleston  wrote:
> 
> 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 happened 
> to me. Requiring a flag will reach everyone trying to use MVs as soon as they 
> start developing against MVs. Logging a warning will reach a subset of users 
> at some point, hopefully. The only downside I can think of for the flag is 
> that it's not as polite.
> 
> On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org) wrote:
> 
> "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 than barfing a  
> warning on someone's screen during the dev process when they use the DDL  
> for MV's. At the end of the day, it's just a question of how forceful you  
> want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT  
> READY' in big bold letters, that's not going to miscommunicate to a user  
> that 'feature X is ready' when it's not.  
> 
> Much like w/SASI, this is something that's in the code-base that for  
> certain use-cases apparently works just fine. Might be worth considering  
> the approach of making boundaries around those use-cases more rigid instead  
> of throwing the baby out with the bathwater.  
> 
> On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:  
> 
>> 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 disabled, to enable it, turn on the flag  in  
>> cassandra.yaml" so users don't spend 3h searching around  
>> 
>> 
>> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:  
>> 
>>> 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  
>>> explicit option because they really aren’t ready for general use.  
>>> 
>>> Claiming disabling by default == removal is not helpful to the  
>>> conversation and is very misleading.  
>>> 
>>> Let’s be practical here. The people that are most likely to put MVs in  
>>> production right now are people new to Cassandra that don’t know any  
>>> better. The people that *should* be using MVs are the contributors to  
>> the  
>>> project. People that actually wrote Cassandra code that can do a patch  
>> and  
>>> push it into prod, and get it submitted upstream when they fix something.  
>>> Yes, a lot of this stuff requires production usage to shake out the bugs,  
>>> that’s fine, but we shouldn’t lie to people and say “feature X is ready”  
>>> when it’s not. That’s a great way to get a reputation as “unstable” or  
>>> “not fit for production."  
>>> 
>>> Jon  
>>> 
>>> 
 On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:  
 
 "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 when do we start removing feature in a patch release ?  
>> (forbidding  
>>> to  
 create new MV == removing the feature, defacto)  
 
 Even the Thrift protocol has gone through a long process of deprecation  
>>> and  
 will be removed on 4.0  
 
 And if we start opening the Pandora box like this, what's next ?  
>>> Forbidding  
 to create SASI index too ? Removing Vnodes ?  
 
 
 
 
 On Mon, Oct 2, 20

Re: Proposal to retroactively mark materialized views experimental

[Blake Eggleston]

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 developers writing 
the application.

On October 2, 2017 at 2:21:38 PM, Jeremiah D Jordan (jerem...@datastax.com) 
wrote:

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 
  

For example for SASI it would look something like:  


cqlsh:ks> CREATE CUSTOM INDEX ON sasi_table (c) USING 
'org.apache.cassandra.index.sasi.SASIIndex';  

Warnings :  
A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental, take 
extra caution when using it in production.  

cqlsh:ks>  

-Jeremiah  

> On Oct 2, 2017, at 5:05 PM, Blake Eggleston  wrote:  
>  
> 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 happened 
> to me. Requiring a flag will reach everyone trying to use MVs as soon as they 
> start developing against MVs. Logging a warning will reach a subset of users 
> at some point, hopefully. The only downside I can think of for the flag is 
> that it's not as polite.  
>  
> On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org) wrote: 
>  
>  
> "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 than barfing a  
> warning on someone's screen during the dev process when they use the DDL  
> for MV's. At the end of the day, it's just a question of how forceful you  
> want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS NOT  
> READY' in big bold letters, that's not going to miscommunicate to a user  
> that 'feature X is ready' when it's not.  
>  
> Much like w/SASI, this is something that's in the code-base that for  
> certain use-cases apparently works just fine. Might be worth considering  
> the approach of making boundaries around those use-cases more rigid instead  
> of throwing the baby out with the bathwater.  
>  
> On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan  wrote:  
>  
>> 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 disabled, to enable it, turn on the flag  in  
>> cassandra.yaml" so users don't spend 3h searching around  
>>  
>>  
>> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:  
>>  
>>> 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  
>>> explicit option because they really aren’t ready for general use.  
>>>  
>>> Claiming disabling by default == removal is not helpful to the  
>>> conversation and is very misleading.  
>>>  
>>> Let’s be practical here. The people that are most likely to put MVs in  
>>> production right now are people new to Cassandra that don’t know any  
>>> better. The people that *should* be using MVs are the contributors to  
>> the  
>>> project. People that actually wrote Cassandra code that can do a patch  
>> and  
>>> push it into prod, and get it submitted upstream when they fix something.  
>>> Yes, a lot of this stuff requires production usage to shake out the bugs,  
>>> that’s fine, but we shouldn’t lie to people and say “feature X is ready”  
>>> when it’s not. That’s a great way to get a reputation as “unstable” or  
>>> “not fit for production."  
>>>  
>>> Jon  
>>>  
>>>  
 On Oct 2, 2017, at 11:54 AM, DuyHai Doan  wrote:  
  
 "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.  
  
>>>

Re: Proposal to retroactively mark materialized views experimental

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

Re: Proposal to retroactively mark materialized views experimental

[Voytek Jarnot]

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 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 <
> https://issues.apache.org/jira/browse/CASSANDRA-8930>
>
> For example for SASI it would look something like:
>
>
> cqlsh:ks> CREATE CUSTOM INDEX ON sasi_table (c) USING
> 'org.apache.cassandra.index.sasi.SASIIndex';
>
> Warnings :
> A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental,
> take extra caution when using it in production.
>
> cqlsh:ks>
>
> -Jeremiah
>
> > On Oct 2, 2017, at 5:05 PM, Blake Eggleston 
> wrote:
> >
> > 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
> happened to me. Requiring a flag will reach everyone trying to use MVs as
> soon as they start developing against MVs. Logging a warning will reach a
> subset of users at some point, hopefully. The only downside I can think of
> for the flag is that it's not as polite.
> >
> > On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org)
> wrote:
> >
> > "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 than barfing a
> > warning on someone's screen during the dev process when they use the DDL
> > for MV's. At the end of the day, it's just a question of how forceful you
> > want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS
> NOT
> > READY' in big bold letters, that's not going to miscommunicate to a user
> > that 'feature X is ready' when it's not.
> >
> > Much like w/SASI, this is something that's in the code-base that for
> > certain use-cases apparently works just fine. Might be worth considering
> > the approach of making boundaries around those use-cases more rigid
> instead
> > of throwing the baby out with the bathwater.
> >
> > On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan 
> wrote:
> >
> >> 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 disabled, to enable it, turn on the flag  in
> >> cassandra.yaml" so users don't spend 3h searching around
> >>
> >>
> >> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:
> >>
> >>> 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
> >>> explicit option because they really aren’t ready for general use.
> >>>
> >>> Claiming disabling by default == removal is not helpful to the
> >>> conversation and is very misleading.
> >>>
> >>> Let’s be practical here. The people that are most likely to put MVs in
> >>> production right now are people new to Cassandra that don’t know any
> >>> better. The people that *should* be using MVs are the contributors to
> >> the
> >>> project. People that actually wrote Cassandra code that can do a patch
> >> and
> >>> push it into prod, and get it submitted upstream when they fix
> something.
> >>> Yes, a lot of this stuff requires production usage to shake out the
> bugs,
> >>> that’s fine, but we shouldn’t lie to people and say “feature X is
> ready”
> >>> when it’s not. That’s a great way to get a reputation as “unstable” or
> >>> “not fit for production."
> >>>
> >>> Jon
> >>>
> >>>
>  On Oct 2, 2017, at 11:54 AM, DuyHai Doan 
> wrote:
> 
>  "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 when do we start removing feature in a patch release ?
> >> (forbidding
> >>> to
>  create new MV == removing the feature, defacto)
> 
>  Even th

Re: Proposal to retroactively mark materialized views experimental

[Ben Bromhead]

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 of
the original proposal.


On Mon, 2 Oct 2017 at 15:25 Voytek Jarnot  wrote:

> 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 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 <
> > https://issues.apache.org/jira/browse/CASSANDRA-8930>
> >
> > For example for SASI it would look something like:
> >
> >
> > cqlsh:ks> CREATE CUSTOM INDEX ON sasi_table (c) USING
> > 'org.apache.cassandra.index.sasi.SASIIndex';
> >
> > Warnings :
> > A SASI index was enabled for ‘ks.sasi_table'. SASI is still experimental,
> > take extra caution when using it in production.
> >
> > cqlsh:ks>
> >
> > -Jeremiah
> >
> > > On Oct 2, 2017, at 5:05 PM, Blake Eggleston 
> > wrote:
> > >
> > > 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
> > happened to me. Requiring a flag will reach everyone trying to use MVs as
> > soon as they start developing against MVs. Logging a warning will reach a
> > subset of users at some point, hopefully. The only downside I can think
> of
> > for the flag is that it's not as polite.
> > >
> > > On October 2, 2017 at 1:16:10 PM, Josh McKenzie (jmcken...@apache.org)
> > wrote:
> > >
> > > "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 than barfing
> a
> > > warning on someone's screen during the dev process when they use the
> DDL
> > > for MV's. At the end of the day, it's just a question of how forceful
> you
> > > want that messaging to be. If the cqlsh client prints 'THIS FEATURE IS
> > NOT
> > > READY' in big bold letters, that's not going to miscommunicate to a
> user
> > > that 'feature X is ready' when it's not.
> > >
> > > Much like w/SASI, this is something that's in the code-base that for
> > > certain use-cases apparently works just fine. Might be worth
> considering
> > > the approach of making boundaries around those use-cases more rigid
> > instead
> > > of throwing the baby out with the bathwater.
> > >
> > > On Mon, Oct 2, 2017 at 3:32 PM, DuyHai Doan 
> > wrote:
> > >
> > >> 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 disabled, to enable it, turn on the flag  in
> > >> cassandra.yaml" so users don't spend 3h searching around
> > >>
> > >>
> > >> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad  wrote:
> > >>
> > >>> 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
> > >>> explicit option because they really aren’t ready for general use.
> > >>>
> > >>> Claiming disabling by default == removal is not helpful to the
> > >>> conversation and is very misleading.
> > >>>
> > >>> Let’s be practical here. The people that are most likely to put MVs
> in
> > >>> production right now are people new to Cassandra that don’t know any
> > >>> better. The people that *should* be using MVs are the contributors to
> > >> the
> > >>> project. People that actually wrote Cassandra code that can do a
> patch
> > >> and
> > >>> push it into prod, and get it submitted upstream when they fix
> > something.
> > >>> Yes, a lot of this stuff requires production usage to shake out the
> > bugs,
> > >>> that’s fine, but we shouldn’t lie to people and say “feature X is
> > ready”
> > >>> when it’s not. That’s a great way to get a reputation as “unstable”
> or
> > >>> “not fit for produc

Re: Proposal to retroactively mark materialized views experimental

[Mick Semb Wever]

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 - yes, that should also be emitted. Unconditionally.
>


Thanks Aleksey, this was the best read in this thread imo of what should be
done with MVs.
(With these warnings being emitted in both logs and cqlsh).

Hopefully similar "creation flags" and log+cqlsh warnings can be added to:
triggers, SASI, and incremental repair (<4.0).

CDC sounds like it is in the same basket, but it already has the
`cdc_enabled` yaml flag which defaults false.

Mick

Re: [VOTE] Release Apache Cassandra 3.0.15

[Nate McCall]

+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
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1150/org/apache/cassandra/apache-cassandra/3.0.15/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1150/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/RyuPpw
> [2]: (NEWS.txt) https://goo.gl/qxwUti
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>

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

Re: Proposal to retroactively mark materialized views experimental

[Jeremy Hanna]

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 creation and usage even 
with it enabled.  We could be very explicit with a message to the user list and 
a clear NEWS item and upgrade note.

For SASI, it seems like a similar pattern could be used.

For either or both of these features, a Jira epic could be created to make a 
path to making it a full-fledged non-experimental feature.  That could include 
a ticket for realistic testing within the boundaries of the target use cases - 
that way people can point to what testing has been done and what the target use 
cases were.  An epic and test ticket would give people a pathway to make it no 
longer experimental so it isn’t lingering halfway in the codebase indefinitely 
and for interested parties something to contribute towards.  Granted if issues 
are found, they’d need to be added to the epic.

>> On Oct 2, 2017, at 6:16 PM, Mick Semb Wever  wrote:
>> 
>> 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 - yes, that should also be emitted. Unconditionally.
> 
> 
> Thanks Aleksey, this was the best read in this thread imo of what should be
> done with MVs.
> (With these warnings being emitted in both logs and cqlsh).
> 
> Hopefully similar "creation flags" and log+cqlsh warnings can be added to:
> triggers, SASI, and incremental repair (<4.0).
> 
> CDC sounds like it is in the same basket, but it already has the
> `cdc_enabled` yaml flag which defaults false.
> 
> Mick

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