> > Where I think there becomes a grey area is on refactoring ISTM we have two types of refactors: 1) Improving logic, tracking, state machines, etc (behavior, invasive) 2) Should be opaque to end user with zero change to behavior (hygiene, code organization)
Feature flag on #1 as it's kind of a new feature / new way of operating, deferred to major on #2 as we have a complex code-base where refactors often have side-effects that should be more thoroughly vetted like a major? Take as a loose set of ideas; potentially bad ones. ~Josh On Mon, Sep 13, 2021 at 10:28 AM Ekaterina Dimitrova <e.dimitr...@gmail.com> wrote: > I don’t think we can or we should cover every particular case but this is a > good baseline/guideline and we should encourage people to hit the mailing > list when there is uncertainty. > My understanding is that this document will support also the initially > mentioned one where I saw something that probably partially addresses > David’s concerns but it is said as something tbd as far as I understand: > https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle > > “Compatibility between major versions - Content we have so far based on the > feedback - Developer community will try not to make any backwards > incompatible changes as much as possible, except in extreme cases like to > ensure correctness. Introducing a backward incompatibility change needs dev > community approval via voting [voting open for 48 hours].” > > On Fri, 10 Sep 2021 at 14:29, David Capwell <dcapw...@apple.com.invalid> > wrote: > > > > 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. > > >>>> > > >>> > > >> > > > > >
