[
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
