> I believe that always having a feature flag for every new feature might be > too complicated in practice for different reasons. > Some new features might be low impact like new nodetool commands or new > virtual tables and adding flags for those might simply be extra > complication for the developers and users. > For some other features it might be simply too hard to hide them behind > feature flags. > > Feature flag basically means "experimental" so it would be good when a > feature flag is introduced to also have a clear plan on when and how the > flag will be removed. > > I would personally limit the feature flag to significant new features. As > those types of features now require a CEP, we could make the feature fag > discussion part of the CEP discussion. > > What do you think?
Personally I run with the idea we should default to “you need a feature flag” and special case places which do not need; if we start with “significant new feature” every feature will be argued that it isn’t “significant enough” or that offering one would be “too complex”. I would argue tables/nodetool act more like a feature flag so these examples shouldn’t cause us to weaken the notation of a feature flag, as they do not impact you unless you opt-into them…. which is what a feature flag does. > For some other features it might be simply too hard to hide them behind > feature flags. In my experience these types of features get a feature flag after the fact or warned to operators/users not to use them… While working on CASSANDRA-16850 it was really annoying to support flags as I need to keep track of state both at the coordinator and the replica to support this, and at each check’s level (we also do not have a notion of a query context or what actor is doing the action… which makes this even more painful to do); this drastically increased my testing scope. This was still important to do as after it is deployed it could cause a negative impact to operators or users, so being able to act without code changes is important. Where I think there becomes a grey area is on refactoring… for example I have put in a lot of work refactoring repair coordination and I plan to do a lot more… do I support falling back to old logic or old behavior? In CASSANDRA-16909 I document a lot of places which are buggy and have shown to cause production issues… is the “fix” actually a “new feature” (fun example that happens on prod from time to time… we drop the merkle tree and hang forever… we could make this recoverable but is that a feature or a bug fix)? Should this go into a prior release? > On Sep 10, 2021, at 9:25 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > > I put together a gdoc documenting what was in this thread - should be open > to comment for everyone: > https://docs.google.com/document/d/1LhCNcbuhtqTkv_aKx1TQUgWEcq022fsAZs1C_oOxEJw/edit > > I'll let this thread sit to early next week and assuming no major concerns > we'll get that into either the wiki or the site or both. > > Thanks everyone for the feedback! > > ~Josh > > On Thu, Sep 2, 2021 at 9:57 AM Joshua McKenzie <jmcken...@apache.org> wrote: > >> Feature flag basically means "experimental" >> >> I'm thinking of feature flags more as giving the power to operators to >> decide what they do and don't allow users of the database access to. Even >> if a feature is very stable and non-experimental, it can have negative >> effects on other use-cases on a shared cluster, be incompatible with the >> underlying execution environment, be outside compliance policies of an >> organization, require greater expertise to use correctly, etc. >> >> That said, I 100% agree w/you on the "limit it to significant new >> features". I don't think feature flagging nodetool commands makes a lot of >> sense. :) >> >> Adding it to the CEP template as something to yes/no on would be a simple >> clarification for this. +1 >> >> ~Josh >> >> >> On Thu, Sep 2, 2021 at 3:14 AM Benjamin Lerer <ble...@apache.org> wrote: >> >>>> >>>> - New features, always with feature flag (added; happy to drop if >>>> controversial) >>> >>> >>> I believe that always having a feature flag for every new feature might be >>> too complicated in practice for different reasons. >>> Some new features might be low impact like new nodetool commands or new >>> virtual tables and adding flags for those might simply be extra >>> complication for the developers and users. >>> For some other features it might be simply too hard to hide them behind >>> feature flags. >>> >>> Feature flag basically means "experimental" so it would be good when a >>> feature flag is introduced to also have a clear plan on when and how the >>> flag will be removed. >>> >>> I would personally limit the feature flag to significant new features. As >>> those types of features now require a CEP, we could make the feature fag >>> discussion part of the CEP discussion. >>> >>> What do you think? >>> >>> >>> >>> Le jeu. 2 sept. 2021 à 08:41, Mick Semb Wever <m...@apache.org> a écrit : >>> >>>>> >>>>> >>>>> There's certainly a lot of complexity in a lot of the systems here, no >>>>> denying that, so maybe we treat the topic of API changes as "here's >>> loose >>>>> guidelines (destructive vs. additive w/sane defaults, etc) but plan to >>>> take >>>>> it case-by-case" and be a bit more prescriptive on the "where do bug >>>> fixes >>>>> vs. improvements vs. new features go and why"? >>>>> >>>> >>>> >>>> Agree. >>>> >>> >>
