Regarding the dynamic snitch improvements, it's gone through several rounds
of review already and there's been significant testing of it.  Regarding
the token change, switching a number from 256 -> 16 isn't so invasive that
we shouldn't do it.  There's a little extra work that needs to be done
there ideally to ensure safety, but it's again small enough where it
shouldn't be too big of a problem imo.  Both current implementations (256
tokens + our insanely over memory allocating dynamic snitch) limit the
ability of people to run large clusters, harming both availability and
performance.  It's been extremely harmful for Cassandra's reputation and
I'd really like it if we could ship something where I don't have to
constantly apologize to people I'm trying to help for the land mine
defaults we put out there.

To your point, I agree as a community we're lacking in an open, well
documented and up to date plan, and it needs to be addressed.  I think the
virtual meetings idea held at a regular might help a bit with that, I
intend on participating there.


On Wed, Aug 28, 2019 at 9:52 AM Joshua McKenzie <jmcken...@apache.org>
wrote:

> >
> > dynamic snitch improvements, fixing token counts
>
>
>
> > they're small enough
>
>
> By what axis of measurement out of curiosity? Risk to re-test and validate
> a final artifact? Do we have a more clear understanding of what testing has
> taken place across the community?
>
> The last I saw, our documented test plan
> <
> https://cwiki.apache.org/confluence/display/CASSANDRA/4.0+Quality%3A+Components+and+Test+Plans
> >
> hasn't
> been maintained or kept up to date
> <
> https://issues.apache.org/jira/browse/CASSANDRA-14862?jql=project%20%3D%20CASSANDRA%20AND%20%20labels%20%3D%204.0-QA
> >.
> Is there another artifact reflecting what testing people have in flight to
> better reflect what risk of needing to re-test we have from these (and
> other) post-freeze changes?
>
>
>
> On Wed, Aug 28, 2019 at 11:52 AM Jon Haddad <j...@jonhaddad.com> wrote:
>
> > Hey folks,
> >
> > I think it's time we cut a 4.0 alpha release.  Before I put up a vote
> > thread, is there a reason not to have a 4.0 alpha before ApacheCon /
> > Cassandra Summit?
> >
> > There's a handful of small issues that I should be done for 4.0 (client
> > list in virtual tables, dynamic snitch improvements, fixing token
> counts),
> > I'm not trying to suggest we don't include them, but they're small
> enough I
> > think it's OK to merge them in following the first alpha.
> >
> > Jon
> >
>

Reply via email to