> > I'm unable to create an epic in the project - not sure if that has to do > with project permissions. Could someone create an epic and link these > tickets as subtasks?
Just realized I can no longer create epics anymore (or the "new" JIRA UI is just so obtuse I can't figure it out. I give it 50/50 odds). Thinking this may have been due to transition to LDAP. Since I planned on experimenting with the whole "what does the confluent testing page look like in an epic" today, I'll ping Nate once it's not godawfully early in NZ about this. Or he'll read this email, either way. :) On Thu, Jan 23, 2020 at 11:13 PM Jeremy Hanna <jeremy.hanna1...@gmail.com> wrote: > I've previously created > https://issues.apache.org/jira/browse/CASSANDRA-14902 for updating the > compaction_throughput_in_mb default. I created > https://issues.apache.org/jira/browse/CASSANDRA-15521 for updating the > num_tokens default, https://issues.apache.org/jira/browse/CASSANDRA-15522 > for updating the [roles|permissions|credentials]_validity_in_ms defaults, > and https://issues.apache.org/jira/browse/CASSANDRA-15523 for updating the > default snitch to GossipingPropertyFileSnitch. > I'm unable to create an epic in the project - not sure if that has to do > with project permissions. Could someone create an epic and link these > tickets as subtasks? > Jon - would you mind creating the ticket around JVM defaults? Are you > thinking of the default GC and settings for a better out of the box > experience? > Thanks all, > Jeremy > > On Fri, Jan 24, 2020 at 1:57 PM Jon Haddad <j...@jonhaddad.com> wrote: > > > Yes. please do. We should also update our JVM defaults. > > > > On Thu, Jan 23, 2020, 9:28 PM Jeremy Hanna <jeremy.hanna1...@gmail.com> > > wrote: > > > > > To summarize this thread, I think people are generally okay with > updating > > > certain defaults for 4.0 provided we make sure it doesn't unpleasantly > > > surprise cluster operators. I think with the num_tokens and > > > compaction_throughput_in_mb we could go with a release note for the > > reasons > > > in my last email. I also agree that we should consider bump > > > roles_validity_in_ms, permissions_validity_in_ms, and > > > credentials_validity_in_ms along with the default snitch (going to > > GPFS > > > as the default) as that gives people a DC aware default at least to > > start. > > > > > > Is everyone okay if I create tickets for each of these and link them > with > > > an epic so that we can discuss them separately? > > > > > > Thanks, > > > > > > Jeremy > > > > > > On Thu, Jan 23, 2020 at 5:34 AM Alex Ott <alex...@gmail.com> wrote: > > > > > > > In addition to these, maybe we could consider to change other as > well? > > > > Like: > > > > > > > > 1. bump roles_validity_in_ms, permissions_validity_in_ms, and > > > > credentials_validity_in_ms as well - maybe at least to a minute, > or > > > 2. I > > > > have seen multiple times when authentication was failing under the > > > heavy > > > > load because queries to system tables were timing out - with these > > > > defaults people may still have the possibility to get updates to > > > > roles/credentials faster when specifying _update_interval_ > variants > > of > > > > these configurations. > > > > 2. change default snitch from SimpleSnitch to > > > GossipingPropertyFileSnitch - > > > > we're anyway saying that SimpleSnitch is only appropriate for > > > > single-datacenter deployments, and for real production we need to > > use > > > > GossipingPropertyFileSnitch - why not to set it as default? > > > > > > > > > > > > Jeremy Hanna at "Wed, 22 Jan 2020 11:22:36 +1100" wrote: > > > > JH> I mentioned this in the contributor meeting as a topic to bring > up > > > on > > > > the list - should we > > > > JH> take the opportunity to update defaults for Cassandra 4.0? > > > > > > > > JH> The rationale is two-fold: > > > > JH> 1) There are best practices and tribal knowledge around certain > > > > properties where people > > > > JH> just know to update those properties immediately as a starting > > > > point. If it's pretty much > > > > JH> a given that we set something as a starting point different than > > the > > > > current defaults, why > > > > JH> not make that the new default? > > > > JH> 2) We should align the defaults with what we test with. There > may > > > be > > > > exceptions if we > > > > JH> have one-off tests but on the whole, we should be testing with > > > > defaults. > > > > > > > > JH> As a starting point, compaction throughput and number of vnodes > > seem > > > > like good candidates > > > > JH> but it would be great to get feedback for any others. > > > > > > > > JH> For compaction throughput ( > > > > https://jira.apache.org/jira/browse/CASSANDRA-14902), I've made > > > > JH> a basic case on the ticket to default to 64 just as a starting > > point > > > > because the decision > > > > JH> for 16 was made when spinning disk was most common. Hence most > > > > people I know change that > > > > JH> and I think without too much bikeshedding, 64 is a reasonable > > > > starting point. A case > > > > JH> could be made that empirically the compaction throughput > throttle > > > may > > > > have less effect > > > > JH> than many people think, but I still think an updated default > would > > > > make sense. > > > > > > > > JH> For number of vnodes, Michael Shuler made the point in the > > > discussion > > > > that we already test > > > > JH> with 32, which is a far better number than the 256 default. I > > know > > > > many new users that > > > > JH> just leave the 256 default and then discover later that it's > > better > > > > to go lower. I think > > > > JH> 32 is a good balance. One could go lower with the new algorithm > > but > > > > I think 32 is much > > > > JH> better than 256 without being too skewed, and it's what we > > currently > > > > test. > > > > > > > > JH> Jeff brought up a good point that we want to be careful with > > > defaults > > > > since changing them > > > > JH> could come as an unpleasant surprise to people who don't > > explicitly > > > > set them. As a > > > > JH> general rule, we should always update release notes to clearly > > state > > > > that a default has > > > > JH> changed. For these two defaults in particular, I think it's > safe. > > > > For compaction > > > > JH> throughput I think a release not is sufficient in case they want > > to > > > > modify it. For number > > > > JH> of vnodes, it won't affect existing deployments with data - it > > would > > > > be for new clusters, > > > > JH> which would honestly benefit from this anyway. > > > > > > > > JH> The other point is whether it's too late to go into 4.0. For > > these > > > > two changes, I think > > > > JH> significant testing can still be done with these new defaults > > before > > > > release and I think > > > > JH> testing more explicitly with 32 vnodes in particular will give > > > people > > > > more confidence in > > > > JH> the lower number with a wider array of testing (where we don't > > > > already use 32 explicitly). > > > > > > > > JH> In summary, are people okay with considering updating these > > defaults > > > > and possibly others > > > > JH> in the alpha stage of a new major release? Are there other > > > > properties to consider? > > > > > > > > JH> Jeremy > > > > JH> > > > --------------------------------------------------------------------- > > > > JH> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > JH> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > -- > > > > With best wishes, Alex Ott > > > > Principal Architect, DataStax > > > > http://datastax.com/ > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > >
