Before we can migrate to multi-instance Cassandra, ansible-deploy needs to be capable of dealing with such a configuration.
See: T95253: Finish conversion to multiple Cassandra instances per hardware node
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| 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 |
Event Timeline
Comment Actions
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.
Comment Actions
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.
Comment Actions
It looks like @Eevans is happy with the new tool and not using ansible any more, so closing this one.