OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DISCUSS] changing default token behavior for 4.0


Sounds good to me. I'm going to play around with the algorithm and actually
record some numbers/evidence over the next week to help us decide.

On Tue, 25 Sep 2018 at 05:38, Joseph Lynch <joe.e.lynch@xxxxxxxxx> wrote:

> I am a big fan of lowering the default number of tokens for many
> reasons (availability, repair, etc...). I also agree there are some
> usability blockers to "just lowering the number today", but I very
> much agree that the current default of 256 random tokens is a huge bug
> I hope we fix by 4.0 release.
>
> It sounds like Kurt and Jon have done a lot of work already on this
> problem, and internally I've worked on this as well (Netflix's
> internal token allocation as well as evaluating vnodes that resulted
> in the paper I sent out) so I would be excited to help fix this for
> 4.0. Maybe the three of us (plus any others that are interested) can
> put together a short proposal over the next few days including the
> following:
>
> 1. What precisely should we change the defaults to
> 2. Given the new defaults how would a user bootstrap a new cluster
> 3. Given the new defaults how would a user add capacity to an existing
> cluster
> 4. Concrete jiras that would implement #1 with minimal possible scope
>
> Then we could send the proposal to the dev list for feedback and if
> there is consensus that the scope is not too large/dangerous and a
> committer (Jon perhaps) can commit to reviewing/merging, we can work
> on them and be accountable to merge them before the 4.0 release?
>
> -Joey
> On Sun, Sep 23, 2018 at 1:42 PM Nate McCall <zznate.m@xxxxxxxxx> wrote:
> >
> > Let's pick a default setup that works for most people (IME clusters <
> > 30 nodes, but TLP and Instaclustr peeps probably have the most insight
> > here).
> >
> > Then we just explain the heck out of it in the comments. I would also
> > like to see this include some details add/remove a DC to change the
> > values (perhaps we sub-task a doc creation for that?).
> >
> > Good discussion though - thanks folks.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> > For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
> For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx
>
>