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 <voytek.jar...@gmail.com> 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 <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 < > > 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 <beggles...@apple.com> > > 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 <doanduy...@gmail.com> > > 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 xxxx in > > >> cassandra.yaml" so users don't spend 3h searching around > > >> > > >> > > >> On Mon, Oct 2, 2017 at 9:07 PM, Jon Haddad <j...@jonhaddad.com> 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 <doanduy...@gmail.com> > > 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 <beggles...@apple.com > > > > >>>>> 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 > > >>> > > >>> > > >> > > > > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Reliability at Scale Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
