Before we can migrate to multi-instance Cassandra, ansible-deploy needs to be capable of dealing with such a configuration.
|Invalid||None||T93751 RFC: Next steps for long-term revision storage -- space needs, storage hierarchies|
|Resolved||RobH||T93790 Expand RESTBase cluster capacity|
|Resolved||fgiunchedi||T108306 better cassandra process checks|
|Resolved||Eevans||T106619 investigate G1GC pause times|
|Resolved||fgiunchedi||T95253 Finish conversion to multiple Cassandra instances per hardware node|
|Resolved||Eevans||T117114 Ensure ansible-deploy can cope with multi-instance restarts|
Re-opening, as the current implementation is affecting RESTBase deploys. Those are iterating through all instances where really only a single deploy is needed.
We'll need to find a way to apply a list of tasks to a list of dynamically constructed instances / hosts. One way would be the new block support in Ansible 2.0 (about to be released). Another solution that would work in 1.8 is creating a separate multi-instance role that loops over the main cassandra role, as discussed in this stackoverflow post.
See T132958: MVP: Cassandra (multi-instance) management tools, which includes a utility, c-foreach-restart, that reads local configuration to iterate over each instance, drains, stops, restarts, and blocks until the CQL port is open.