Re: Moving tickets out of 4.0 post freeze

[kurt greaves]

My JIRA experience tells me it would be better to do a blanket update and
then go back and fix anything that shouldn't have been updated. Shouldn't
be hard that way either because everyones inbox will be flooded with
emails, so as long as we all sanity check what got changed we should catch
most of the tickets. Alternatively we could go through and tag all the ones
that should go to 4.0 beforehand so we can use the tag to filter them out
when we do the bulk change. But the former seems easier to crowdsource to
me.

On Tue, 25 Sep 2018 at 21:19, Jason Brown  wrote:

> Before we blanket update all of these, let's make sure they are not
> relevant for 4.0 - because some of them actually are. Some are docs, some
> are parent tickets, some are testing.
>
> Naively, here are some that are still 4.0:
> CASSANDRA-14746 
> CASSANDRA-13254 
> CASSANDRA-14606 
>
> Thanks,
>
> -Jason
>
> On Tue, Sep 25, 2018 at 4:05 AM, Benedict Elliott Smith <
> bened...@apache.org
> > wrote:
>
> > Do we want to manage more versions than we do now?  Why don’t we simply
> > align these things to majors, like we’ve typically tried to anyway?
> >
> > I think it’s anyway better to decide on a strategy and find a versioning
> > scheme that matches it, rather than to look for a strategy that matches
> our
> > current versioning scheme.
> >
> >
> >
> >
> > > On 25 Sep 2018, at 03:07, Mick Semb Wever  wrote:
> > >
> > >
> > >
> > >
> > >> I'm totally spitballing here on possible uses of meaningful minors.
> > >
> > > Continuing the splitballing…
> > >
> > > What about aligning native protocol or sstable format changes with the
> > minor version?
> > >
> > >
> > >> Regardless, the OP's statement that new features and improvements
> > should go to 4.0.x seems wrong
> > >
> > > Yeah, I instinctively thought features and improvements would be moved
> > to either 4.x or 5.x (not to any subsequent patch version 4.0.x).
> > >
> > > -
> > > 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
> >
> >
>

Re: [DISCUSS] changing default token behavior for 4.0

[kurt greaves]

This was exactly the kind of problem I was foreseeing. I don't see any
simple way of fixing it without introducing some shuffle-like nightmare
that does a whole bunch of token movements though. On the other hand we
could just document best practice, and also make it so that by default you
have to choose between random and the algorithm for allocation initially,
essentially the way I mentioned before. At least this way people are aware
of the advantages and disadvantages from the start, rather than everyone
just ending up with random allocation because that's what they were given.
Anyway, this isn't a simple problem so we could probably come up with
something better than that with a bit more thought

On Tue, 25 Sep 2018 at 05:43, Benedict Elliott Smith 
wrote:

> This sounds worthy of a bug report!  We should at least document any such
> inadequacy, and come up with a plan to fix it.  It would be great if you
> could file a ticket with a detailed example of the problem.
>
> > On 24 Sep 2018, at 14:57, Tom van der Woerdt <
> tom.vanderwoe...@booking.com> wrote:
> >
> > Late comment, but I'll write it anyway.
> >
> > The main advantage of random allocation over the new allocation strategy
> is
> > that it seems to be significantly better when dealing with node
> *removals*,
> > when the order of removal is not the inverse of the order of addition.
> This
> > can lead to severely unbalanced clusters when the new strategy is
> enabled.
> >
> > I tend to go with the random allocation for this reason: you can freely
> > add/remove nodes when needed, and the data distribution will remain "good
> > enough". It's only when the data density becomes high enough that the new
> > token allocation strategy really matters, imho.
> >
> > Hope that helps!
> >
> > Tom van der Woerdt
> > Site Reliability Engineer
> >
> > Booking.com B.V.
> > Vijzelstraat 66-80 Amsterdam 1017HL Netherlands
> > [image: Booking.com] 
> > The world's #1 accommodation site
> > 43 languages, 198+ offices worldwide, 120,000+ global destinations,
> > 1,550,000+ room nights booked every day
> > No booking fees, best price always guaranteed
> > Subsidiary of Booking Holdings Inc. (NASDAQ: BKNG)
> >
> >
> > On Sat, Sep 22, 2018 at 8:12 PM Jonathan Haddad 
> wrote:
> >
> >> 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 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 that balance is good initially but as a cluster gets larger
> you
> >>> have some problems. E.g We saw that on a 60 node cluster with 8 tokens
> >> per
> >>> node we were seeing a difference of 22% in token ownership, but on a
> <=12
> >>> node cluster a difference of only 12%. 16 tokens on the other hand
> wasn't
> >>> perfect but generally gave a better balance regardless of cluster size
> at
> >>> least up to 100 nodes. TBH we should probably do some proper testing
> and
> >>> record all the results for this before we pick a default (I'm happy to
> do
> >>> this - think we can use the original testing script for this).
> >>>
> >>> But anyway, I'd say Jon is on the right track. Personally how I'd like
> to
> >>> see it is that we:
> >>>
> >>>   1. Change allocate_tokens_for_keyspace to allocate_tokens_for_rf in
> >> the
> >>>   same way that DSE does it. Allowing a user to specify a RF to
> allocate
> >>>   from, and allowing multiple DC's.
> >>>   2. Add a new boolean property random_token_allocation, defaults to
> >>> false.
> >>>   3. Make allocate_tokens_for_rf default to *unset**.
> >>>   4. Make allocate_tokens_for_rf *required*** if num_tokens > 1 and
> >>>   random_token_allocation != true.
> >>>   5. Default num_tokens to 16 (or whatever we find appropriate)
> >>>
> >>> * I think setting a default is asking for trouble. When people are
> going
> >> to
> >>> add new DC's/nodes we don't want to risk them adding a node with the
> >> wrong
> >>> RF. I think it's safe to say that a user should have to think about
> this
> >>> before they spin up their cluster.
> >>> ** Following above, it should be required to be set so that we don't
> have
> >>> people accidentally using random allocation. I think we should really
> be
> >>> aiming to get rid of random allocation completely, but provide a new
> >>> property to enable it for backwards compatibility (also for testing).
> >>>
> >>> It's worth noting that a smaller number of tokens *theoretically*
> >> decreases
> >>> the time for replacement/rebuild, so if we're considering QUORUM
> >>> availability with vnodes there's an argument against having a very low
> >>> num_tokens. I 

Re: [DISCUSS] changing default token behavior for 4.0

[kurt greaves]

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  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  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
>
>

Re: Moving tickets out of 4.0 post freeze

[Jason Brown]

Before we blanket update all of these, let's make sure they are not
relevant for 4.0 - because some of them actually are. Some are docs, some
are parent tickets, some are testing.

Naively, here are some that are still 4.0:
CASSANDRA-14746 
CASSANDRA-13254 
CASSANDRA-14606 

Thanks,

-Jason

On Tue, Sep 25, 2018 at 4:05 AM, Benedict Elliott Smith  wrote:

> Do we want to manage more versions than we do now?  Why don’t we simply
> align these things to majors, like we’ve typically tried to anyway?
>
> I think it’s anyway better to decide on a strategy and find a versioning
> scheme that matches it, rather than to look for a strategy that matches our
> current versioning scheme.
>
>
>
>
> > On 25 Sep 2018, at 03:07, Mick Semb Wever  wrote:
> >
> >
> >
> >
> >> I'm totally spitballing here on possible uses of meaningful minors.
> >
> > Continuing the splitballing…
> >
> > What about aligning native protocol or sstable format changes with the
> minor version?
> >
> >
> >> Regardless, the OP's statement that new features and improvements
> should go to 4.0.x seems wrong
> >
> > Yeah, I instinctively thought features and improvements would be moved
> to either 4.x or 5.x (not to any subsequent patch version 4.0.x).
> >
> > -
> > 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
>
>

Re: Moving tickets out of 4.0 post freeze

[Benedict Elliott Smith]

Do we want to manage more versions than we do now?  Why don’t we simply align 
these things to majors, like we’ve typically tried to anyway?

I think it’s anyway better to decide on a strategy and find a versioning scheme 
that matches it, rather than to look for a strategy that matches our current 
versioning scheme.




> On 25 Sep 2018, at 03:07, Mick Semb Wever  wrote:
> 
> 
> 
> 
>> I'm totally spitballing here on possible uses of meaningful minors.
> 
> Continuing the splitballing…
> 
> What about aligning native protocol or sstable format changes with the minor 
> version?
> 
> 
>> Regardless, the OP's statement that new features and improvements should go 
>> to 4.0.x seems wrong
> 
> Yeah, I instinctively thought features and improvements would be moved to 
> either 4.x or 5.x (not to any subsequent patch version 4.0.x).
> 
> -
> 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