> > So you’d rather continue to lie to users about the stability of the > feature rather than admitting it was merged in prematurely?
Much like w/SASI, this is something that's in the code-base that for > certain use-cases apparently works just fine. I don't know of any outstanding issues with the feature, There appear to be varying levels of understanding of the implementation > details of MV's (that seem to directly correlate with faith in the > feature's correctness for the use-cases recommended) We have users in the wild relying on MV's with apparent success (same holds > true of all the other punching bags that have come up in this thread) You're right, Jon. That's clearly exactly what I'm saying. On Wed, Oct 4, 2017 at 2:39 PM, Jon Haddad <j...@jonhaddad.com> wrote: > So you’d rather continue to lie to users about the stability of the > feature rather than admitting it was merged in prematurely? I’d rather > come clean and avoid future problems, and give people the opportunity to > stop using MVs rather than let them keep taking risks they’re unaware of. > This is incredibly irresponsible in my opinion. > > > On Oct 4, 2017, at 11:26 AM, Josh McKenzie <jmcken...@apache.org> wrote: > > > >> > >> Oh, come on. You're being disingenuous. > > > > Not my intent. MV's (and SASI, for example) are fairly well isolated; we > > have a history of other changes that are much more broadly and higher > > impact risk-wise across the code-base. > > > > If I were an operator and built a critical part of my business on a > > released feature that developers then decided to default-disable as > > 'experimental' post-hoc, I'd think long and hard about using any new > > features in that project in the future (and revisit my confidence in all > > other features I relied on, and the software as a whole). We have users > in > > the wild relying on MV's with apparent success (same holds true of all > the > > other punching bags that have come up in this thread) and I'd hate to see > > us alienate them by being over-aggressive in the way we handle this. > > > > I'd much rather we continue to aggressively improve and continue to > analyze > > MV's stability before a 4.0 release and then use the experimental flag in > > the future, if at all possible. > > > > On Wed, Oct 4, 2017 at 2:01 PM, Benedict Elliott Smith <_@ > belliottsmith.com> > > wrote: > > > >> Can't we promote these behavioural flags to keyspace properties (with > >> suitable permissions to edit necessary)? > >> > >> I agree that enabling/disabling features shouldn't require a rolling > >> restart, and nor should switching their consistency safety level. > >> > >> I think this would be the most suitable equivalent to ALLOW FILTERING > for > >> MVs. > >> > >> > >> > >>> On 4 Oct 2017, at 12:31, Jeremy Hanna <jeremy.hanna1...@gmail.com> > >> wrote: > >>> > >>> Not to detract from the discussion about whether or not to classify X > or > >> Y as experimental but https://issues.apache.org/ > jira/browse/CASSANDRA-8303 > >> <https://issues.apache.org/jira/browse/CASSANDRA-8303> was originally > >> about operators preventing users from abusing features (e.g. allow > >> filtering). Could that concept be extended to features like MVs or > SASI or > >> anything else? On the one hand it is nice to be able to set those > things > >> dynamically without a rolling restart as well as by user. On the other > >> it’s less clear about defaults. There could be a property file or just > in > >> the yaml, the operator could specify the default features that are > enabled > >> for users and then it could be overridden within that framework. > >>> > >>>> On Oct 4, 2017, at 10:24 AM, Aleksey Yeshchenko <alek...@apple.com> > >> wrote: > >>>> > >>>> We already have those for UDFs and CDC. > >>>> > >>>> We should have more: for triggers, SASI, and MVs, at least. Operators > >> need a way to disable features they haven’t validated. > >>>> > >>>> We already have sufficient consensus to introduce the flags, and we > >> should. There also seems to be sufficient consensus on emitting > warnings. > >>>> > >>>> The debate is now on their defaults for MVs in 3.0, 3.11, and 4.0. I > >> agree with Sylvain that flipping the default in a minor would be > invasive. > >> We shouldn’t do that. > >>>> > >>>> For trunk, though, I think we should default to off. When it comes to > >> releasing 4.0 we can collectively decide if there is sufficient trust in > >> MVs at the time to warrant flipping the default to true. Ultimately we > can > >> decide this in a PMC vote. If I misread the consensus regarding the > default > >> for 4.0, then we might as well vote on that. What I see is sufficient > >> distrust coming from core committers, including the author of the v1 > >> design, to warrant opt-in for MVs. > >>>> > >>>> If we don’t trust in them as developers, we shouldn’t be cavalier with > >> the users, either. Not until that trust is gained/regained. > >>>> > >>>> — > >>>> AY > >>>> > >>>> On 4 October 2017 at 13:26:10, Stefan Podkowinski (s...@apache.org) > >> wrote: > >>>> > >>>> Introducing feature flags for enabling or disabling different code > paths > >>>> is not sustainable in the long run. It's hard enough to keep up with > >>>> integration testing with the couple of Jenkins jobs that we have. > >>>> Running jobs for all permutations of flags that we keep around, would > >>>> turn out impractical. But if we don't, I'm pretty sure something will > >>>> fall off the radar and it won't take long until someone reports that > >>>> enabling feature X after the latest upgrade will simply not work > >> anymore. > >>>> > >>>> There may also be some more subtle assumptions and cross dependencies > >>>> between features that may cause side effects by disabling a feature > (or > >>>> parts of it), even if it's just e.g. a metric value that suddenly > won't > >>>> get updated anymore, but is used somewhere else. We'll also have to > >>>> consider migration paths for turning a feature on and off again > without > >>>> causing any downtime. If I was to turn on e.g. MVs on a single node in > >>>> my cluster, then this should not cause any issues on the other nodes > >>>> that still have MV code paths disabled. Again, this would need to be > >> tested. > >>>> > >>>> So to be clear, my point is that any flags should be implemented in a > >>>> really non-invasive way on the user facing side only, e.g. by > emitting a > >>>> log message or cqlsh error. At this point, I'm not really sure if it > >>>> would be a good idea to add them to cassandra.yaml, as I'm pretty sure > >>>> that eventually they will be used to change the behaviour of our code, > >>>> beside printing a log message. > >>>> > >>>> > >>>> On 04.10.17 10:03, Mick Semb Wever wrote: > >>>>>>> CDC sounds like it is in the same basket, but it already has the > >>>>>>> `cdc_enabled` yaml flag which defaults false. > >>>>>> I went this route because I was incredibly wary of changing the CL > >>>>>> code and wanted to shield non-CDC users from any and all risk I > >>>>>> reasonably could. > >>>>> > >>>>> This approach so far is my favourite. (Thanks Josh.) > >>>>> > >>>>> The flag name `cdc_enabled` is simple and, without adjectives, does > not > >>>>> imply "experimental" or "beta" or anything like that. > >>>>> It does make life easier for both operators and the C* developers. > >>>>> > >>>>> I'm also fond of how Apache projects often vote both on the release > as > >> well > >>>>> as its stability flag: Alpha|Beta|GA (General Availability). > >>>>> https://httpd.apache.org/dev/release.html > >>>>> http://www.apache.org/legal/release-policy.html#release-types > >>>>> > >>>>> Given the importance of The Database, i'd be keen to see attached > such > >>>>> community-agreed quality references. And going further, not just to > the > >>>>> releases but also to substantial new features (those yet to reach > GA). > >> Then > >>>>> the downloads page could provide a table something like > >>>>> https://paste.apache.org/FzrQ > >>>>> > >>>>> It's just one idea to throw out there, and while it hijacks the > thread > >> a > >>>>> bit, it could even with just the quality tag on releases go a long > way > >> with > >>>>> user trust. Especially if we really are humble about it and use GA > >>>>> appropriately. For example I'm perfectly happy using a beta in > >> production > >>>>> if I see the community otherwise has good processes in place and > >> there's > >>>>> strong testing and staging resources to take advantage of. And as > Kurt > >> has > >>>>> implied many users are indeed smart and wise enough to know how to > >> safely > >>>>> test and cautiously use even alpha features in production. > >>>>> > >>>>> Anyway, with or without the above idea, yaml flag names that don't > >>>>> use adjectives could address Kurt's concerns about pulling the rug > from > >>>>> under the feet of existing users. Such a flag is but a small > >> improvement > >>>>> suitable for a minor release (you must read the NEWS.txt before even > a > >>>>> patch upgrade), and the documentation is only making explicit what > >> should > >>>>> have been all along. Users shouldn't feel that we're returning > features > >>>>> into "alpha|beta" mode when what we're actually doing is improving > the > >>>>> community's quality assurance documentation. > >>>>> > >>>>> Mick > >>>>> > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> 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 > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
