Yep agreed with that. Count me in.
On Sun., 23 Sep. 2018, 00:33 Benedict Elliott Smith,
wrote:
> Thanks Kurt. I think the goal would be to get JIRA into a state where it
> can hold all the information we want, and for it to be easy to get all the
> information correct when filing.
>
> My
Only that it makes it easier to spin up a cluster.
I'm for removing it entirely as well, however I think we should keep it
around at least until the next major just as a safety precaution until the
algorithm is properly battle tested.
This is not a strongly held opinion though, I'm just
Is there a use case for random allocation? How does it help with testing? I
can’t see a reason to keep it around.
On Sat, Sep 22, 2018 at 3:06 AM kurt greaves wrote:
> +1. I've been making a case for this for some time now, and was actually a
> focus of my talk last week. I'd be very happy to
This is not part of core database and a separate repo and so my impression is
that this can continue to make progress. Also we can always make progress and
not merge it till freeze is lifted.
Open to ideas/suggestions if someone thinks otherwise.
> On Sep 22, 2018, at 03:13, kurt greaves
Thanks Kurt. I think the goal would be to get JIRA into a state where it can
hold all the information we want, and for it to be easy to get all the
information correct when filing.
My feeling is that it would be easiest to do this with a small group, so we can
make rapid progress on an
I'm interested. Better defining the components and labels we use in our
docs would be a good start and LHF. I'd prefer if we kept all the
information within JIRA through the use of fields/labels though, and
generated reports off those tags. Keeping all the information in one place
is much better
Is this something we're moving ahead with despite the feature freeze?
On Sat, 22 Sep 2018 at 08:32, dinesh.jo...@yahoo.com.INVALID
wrote:
> I have created a sub-task - CASSANDRA-14783. Could we get some feedback
> before we begin implementing anything?
>
> Dinesh
>
> On Thursday, September
+1. I've been making a case for this for some time now, and was actually a
focus of my talk last week. I'd be very happy to get this into 4.0.
We've tested various num_tokens with the algorithm on various sized
clusters and we've found that typically 16 works best. With lower numbers
we found
There already have been some discussions on this here:
https://issues.apache.org/jira/browse/CASSANDRA-13701
The mentioned blocker there on the token allocation shouldn't exist
anymore. Although it would be good to get more feedback on it, in case
we want to enable it by default, along with new
