Then when you want to upgrade
juju deploy cs:cassandra-11 cassandra-B
juju add-unit -n 10 cassandra-B
juju remove-unit -n 10 cassandra-A
See that things keep working:
juju add-unit -n 50 cassandra-B
juju remove-unit -n 50 cassandra-A
etc
However, you'd need a way to configure the charm so that its configuration can cross services. (Peer relations only work inside a service ATM.)
The nice thing about this method is that it gives you very fine control over the process, and it lets you do the upgrade as clearly bringing up *more* units of work, rather than shutting down the units before adding more capacity. (though you can always remove-unit before you add-unit if you want that.)
It is a workaround, though, and being able to roll out upgrades in place would be very nice to have.
Note that you can simulate this a little bit by doing multiple service deploys.
So you do something like:
juju deploy cs:cassandra-10 cassandra-A
juju add-unit -n 100 cassandra-A
Then when you want to upgrade
juju deploy cs:cassandra-11 cassandra-B
juju add-unit -n 10 cassandra-B
juju remove-unit -n 10 cassandra-A
See that things keep working:
juju add-unit -n 50 cassandra-B
juju remove-unit -n 50 cassandra-A
etc
However, you'd need a way to configure the charm so that its configuration can cross services. (Peer relations only work inside a service ATM.)
The nice thing about this method is that it gives you very fine control over the process, and it lets you do the upgrade as clearly bringing up *more* units of work, rather than shutting down the units before adding more capacity. (though you can always remove-unit before you add-unit if you want that.)
It is a workaround, though, and being able to roll out upgrades in place would be very nice to have.