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
