[ https://issues.apache.org/jira/browse/CASSANDRA-16205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218641#comment-17218641 ]
Paulo Motta commented on CASSANDRA-16205: ----------------------------------------- bq. For CASSANDRA-16079 isn't the code (and the imbalance) parity what we want? That is we want tests to be running on the same setups that allocate_tokens_for_local_replication_factor generates, since that is our default (soon to be). It would be ideal to have all dtests using the new token allocator but given that slowed down dtests I find it suboptimal to create and maintain a new tool that is only used for this purpose. Auto_bootstrap=true is also a default, but we set it to false to speed up dtests so we have precedent here. I don't see why we need to run all dtests (for instance auth, snitch, notifications, cql, ttl etc) using the token allocation algorithm given these tests are agnostic to the ring layout? As long as unit tests guarantee correctness of the token allocator, and we have a few dtests ensuring its correctness during bootstraps, we're safe to use random allocation for all dtests? > Offline token allocation strategy generator tool > ------------------------------------------------ > > Key: CASSANDRA-16205 > URL: https://issues.apache.org/jira/browse/CASSANDRA-16205 > Project: Cassandra > Issue Type: Improvement > Components: Local/Config, Local/Scripts > Reporter: Michael Semb Wever > Assignee: Michael Semb Wever > Priority: Normal > > A command line tool to generate tokens (using the > allocate_tokens_for_local_replication_factor algorithm) for pre-configuration > of {{initial_tokens}} in cassandra.yaml. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org