If "disabling a feature" is just about preventing some CQL from execution along with a warning log message, I'm fine with that. But if that's being the case, I don't really understand why making this change in a minor version would be a problem, since existing MVs wouldn't be affected anyways and should just work as before, even with the enabled flag set to false.
On 04.10.17 17:24, Aleksey Yeshchenko 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
