I agree with Aleksey on all points here. Adding that we should update the docs with warnings about the potential issues with correctness. On Wed, Oct 4, 2017 at 8:25 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 > >
