inline > On Jun 16, 2020, at 11:01 AM, Joshua McKenzie <jmcken...@apache.org> wrote: > >> >> CASSANDRA-15299 - this should be a blocker for v5, > > Could you explain a little more about this? I'm missing context.
V5 added checksumming but had 2 main issues; lack of header checksum, and checksum was on the decompressed stream rather than the compressed stream; the second issue being the bigger issue since it was shown to cause Cassandra to crash (see CASSANDRA-15556) and return incorrect results (see CASSANDRA-15313, this fails frequently showing even more streams where Cassandra returns bad results). I added a patch to make sure we don’t crash anymore, but we still produce incorrect results as shown by CASSANDRA-15313; this is a correctness issue, so must be a blocker for v5 protocol. > > punting these features don’t really get 4.0.0 released any faster. > > GA, no. Beta, where we have a large call to arms to get broad user testing > and adoption in QA and dev environments, however, I'd contend yes. I think you and I see this very differently; why should users push to QA if we have not tested yet? Maybe I missed a lot, I have been ignoring dev@ and JIRA for a while now since I am mostly dealing with corruption issues and performance issues upgrading from 2.x to 3.x; forgive me if I missed any conversations. Is there a reason we want users to start testing before we start the testing effort? Do we expect users to detect correctness issues, or looking for crash reports only; shouldn’t we at least have a baseline of longevity/upgrade testing done before we ask our users to do that for us? > The > sooner we can get this into the hands of the community to test it, the > better in terms of the stability of the final release IMO. > > > > On Tue, Jun 16, 2020 at 1:21 PM David Capwell <dcapw...@apple.com.invalid> > wrote: > >> CASSANDRA-15146 and CASSANDRA-14825 both can be rolled out and be >> backwards compatible, so 4.0 vs 4.1 is fine to me >> CASSANDRA-15299 - this should be a blocker for v5, so if this was punted >> out of 4.0 for any reason, we should also disable v5 protocol. About it >> being a blocker for beta, since this would break the API, it has to be done >> pre-beta. Anything which relies on v5 should also be disabled and removed >> from user facing docs. Given this, I am more in favor of keeping it in 4.0 >> >>> The top 5 >>> drivers alone see tens of thousands of aggregate downloads a day; getting >>> all 5 of those in parity w/the new featureset and to be tested during the >>> GA phase is going to be very difficult with driver impacting, significant >>> protocol changes this late in the alpha cycle (this would argue for them >>> being pushed to 4.1; including here just to point out the ambivalent PoV >>> here) >> >> For 14825 it would expose a way for clients to learn the schema without >> needing to know how we store the schema, which should make it less brittle >> the next time the implementation changes; given that this would be optional >> to clients, I don’t see why clients can’t migrate to this at their own rate. >> 15299 is an interface breaking change, but for a new interface that has >> not yet been released; given the fact v4 is still supported, clients can >> migrate over time. >> >> Clients have a decoupled life cycle from Apache Cassandra, and the >> features in question are optional for clients, so I find it reasonable that >> clients migrate at their own rate. As long as we don’t break the existing >> APIs, I don’t see why client implementations must be a blocker for Apache >> Cassandra to release. >> >>> That >>> said, trying to put myself in the shoes of an end user that hasn't seen a >>> material functionality upgrade in 3+ years and could be testing out and >>> using zero-copy streaming, audit logging, the new messaging service code, >>> and the hundreds of bugfixes and almost 300 improvements already in 4.0 >> - I >>> think the value in getting this release in my hands would outweigh the >>> value in getting these three particular features in 4.0 vs. 4.1. >> >> The biggest body of work I know of is testing and the fact we are missing >> a lot of tests currently. Given this, the biggest effort remaining is >> working down this and resolving issues found; so punting these features >> don’t really get 4.0.0 released any faster. If we want 4.0.0 out faster, >> the biggest gains would be to get the test plans written up and get more >> people working on automated testing. >> >> >>> On Jun 16, 2020, at 9:13 AM, Joshua McKenzie <jmcken...@apache.org> >> wrote: >>> >>> I wanted to open up a discussion about optionality of a few tickets for >>> 4.0. The three I'm specifically thinking of here are: >>> 1) CASSANDRA-15146: Transition TLS server configuration options are >> overly >>> complex >>> 2) CASSANDRA-14825: Expose table schema for drivers >>> 3) CASSANDRA-15299: CASSANDRA-13304 follow-up: improve checksumming and >>> compression in protocol v5-beta >>> >>> I am *personally* of the opinion that each of these three should be >>> considered optional for 4.0 and not blockers to cut beta. My reasoning: >>> 1) it's been 4 years, 7 months, 11 days since the release of 3.0.0 >>> 2) Alternatively, it's been 3 years, 4 months, 13 days since the release >> of >>> 3.10.0 (the last time we added new features to the DB) >>> 3) 2 of the 3 tickets involve non-trivial changes to the drivers. The >> top 5 >>> drivers alone see tens of thousands of aggregate downloads a day; getting >>> all 5 of those in parity w/the new featureset and to be tested during the >>> GA phase is going to be very difficult with driver impacting, significant >>> protocol changes this late in the alpha cycle (this would argue for them >>> being pushed to 4.1; including here just to point out the ambivalent PoV >>> here) >>> 4) If we plan on releasing 4.1 six months after the release of 4.0 (i.e. >>> calender scope vs. feature scope - not yet agreed upon but an option), we >>> would be looking at a relatively trivial delay of the addition of >>> "nice-to-have" features relative to broader infrastructure adoption >> cycles. >>> >>> I know this is a controversial topic, and I've spoken with many of you >> that >>> are working on or reviewing the above tickets - your points of view and >>> arguments in favor of keeping them in 4.0 definitely resonate with me. >> That >>> said, trying to put myself in the shoes of an end user that hasn't seen a >>> material functionality upgrade in 3+ years and could be testing out and >>> using zero-copy streaming, audit logging, the new messaging service code, >>> and the hundreds of bugfixes and almost 300 improvements already in 4.0 >> - I >>> think the value in getting this release in my hands would outweigh the >>> value in getting these three particular features in 4.0 vs. 4.1. >>> >>> Also, to reiterate, I would personally advocate for these three tickets >>> being *optional*, meaning if we merge the 1 awaiting review and 5 in >>> review, then we push them to 4.1. >>> >>> So - what does everyone else think? >>> >>> ~Josh >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
