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.ly...@gmail.com> 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 <zznat...@gmail.com> 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-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 > >
