So, as the author of one of the disasters you mention (early re-open), I would prefer to learn from the mistake and not repeat it. Unfortunately we seem to be in the habit of repeating it, and that feature was a lot *lot* simpler.
Let’s not kid ourselves: MVs are by far and away the most complicated feature we have ever delivered. We do not fully understand it, even in theory, let alone can we be sure we have the implementation right. So, if we all agree our testing is ordinarily insufficient, can’t we agree it is probably *really* insufficient here? I don’t want to give the impression I’m shifting the goals. I’ve been against MV inclusion as they stand for some time, as were several others. I think in the new world order of project/community structure, they probably would have been rejected as they stand. I’ve consistently listed my own requirements for considering them production ready: extensive modelling and simulation of the algorithm’s properties (in lieu of formal proofs), *safe* default behaviour (rollback CASSANDRA-10230, or make it a per-table option, and default to fast only for existing tables to avoid surprise), tools for detecting and repairing inconsistencies, and more extensive testing. Many of these things were agreed as prerequisites for release of 3.0, but ultimately they were not delivered. I do, however, absolutely agree with Sylvain that we need to minimise surprise in a patch version. On 4 Oct 2017, at 08:58, Josh McKenzie <jmcken...@apache.org> wrote: >> and providing a feature we don't fully understand, have not fully > documented the caveats of, let alone discovered all the problems with nor > had that knowledge percolate fully into the wider community. > There appear to be varying levels of understanding of the implementation > details of MV's (that seem to directly correlate with faith in the > feature's correctness for the use-cases recommended) on this email thread > so while I respect a sense of general wariness about the state of > correctness testing with C*, I don't agree that the thoroughness of testing > of MV's is any different than any other feature we've added to the > code-base since the project's inception. > > That's not to say I think the current extent of our testing before GA on > features is adequate; I don't, but I don't think it makes sense to draw an > arbitrary line in the sand with already released features that are in use > in production clusters, flagging said features as experimental after the > fact, and thus eroding users' trust in our collective definition of done. > What's to stop us from flagging other, seemingly arbitrary features people > are relying on in production as experimental in the future? What does that > mean for their faith in the project and their job security? SASI? LWT? > Counters? Triggers? Repair and compaction due to (still arising) edge-cases > and defects in early re-open and incremental repair? All of these features > still have edge-cases due to the inherent complexity of the code-base and > problem domain in which we work. > > Right now there appear to be the two camps of 'I can't clearly articulate > what Good Enough is since it's Complicated, but I know we're not there' and > 'if people are relying on it in production without issue it's by definition > good enough for their use-case'. It's a compromise; nothing is ever perfect > (as we all know). I'm all for us saying 'We need better testing of features > going forward', 'We need better metrics for the coverage and branch testing > of things in C*', etc, and definitely in favor of us spending some time to > increase our coverage for existing features. > > I don't think MV's are any different than anything else in this code-base > in terms of how well vetted the features are, for better or for worse. > > On Wed, Oct 4, 2017 at 5:21 AM, kurt greaves <k...@instaclustr.com> wrote: > >>> >>> 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 would be all for a mv_enabled option, assuming it's enabled by default >> for all existing branches. I don't think saying that you are meant to read >> NEWS.txt before upgrading a patch is acceptable. Most people don't, and >> expecting them to is a bit insane. Also Assuming that if they read it >> they'd understand all implications is also a bit questionable. If deemed >> suitable to turn it off that can be done in the next major/minor, but I >> think that would be unlikely, as we should really require sufficient >> evidence that it's dangerous which I just don't think we have. I'm still of >> the opinion that MV in their current state are no worse off than a lot of >> other features, and marking them as experimental and disabling now would >> just be detrimental to their development and annoy users. Also if we give >> them that treatment then there a whole load of other defaults we should >> change and disable which is just not acceptable in a patch release. It's >> not really necessary anyway, we don't have anyone crying bloody murder on >> the mailing list about how everything went to hell because they used >> feature x. >> >> No one has really provided any counter evidence yet that MV's are in some >> awful state and they are going to shoot users. There are a few existing >> issues that I've brought up already, but they are really quite minor, >> nothing comparable to "lol you can't repair if you use vnodes, sorry". I >> think we really need some real examples/evidence before making calls like >> "lets disable this feature in a patch release and mark it experimental" >> >>> I personally believe it is better to offer the feature as experimental >>> until we iron out all of the problems >> >> What problems are you referring to, and how exactly will we know when all >> of them have been sufficiently ironed? If we mark it as experimental how >> exactly are we going to get people to use said feature to find issues? >> >>
