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
