On Fri, 26 Jan 2018 at 13:32 Sandor Zeestraten <zando...@gmail.com> wrote:
> Hey OpenStack Charmers,
> We have a Newton deployment on MAAS with 3 controller machines running all
> the usual OpenStack controller services in 3x HA with the hacluster charm
> in LXD containers. Now we'd like migrate some of those OpenStack services
> to 3 larger controller machines. Downtime of the services during the
> migration is not an issue.
> My current plan is test something like this:
> * Add the new controller machines to the model
> * Increase the cluster_count from 3 to 6 on the hacluster charm of the
> services in question
> * Add units to the service to LXD containers on the new controller machine
> * Wait for things to deploy and cluster
> * Decrease the cluster_count from 6 to 3
> * Remove units on the old controller
> 1. Is there a preferred way to migrate OpenStack services deployed by
I think your approach above is how I've always envisioned deployments would
migrate services between machines.
> 2. Does the plan above look somewhat sane?
Yes - esp the bit about increasing the cluster_count on the hacluster
applications *prior* to adding the new units to the cluster. Failure todo
this results in some confused behaviour from corosync.
> 3. If yes to the above, does the order of changing the cluster_count and
> adding/removing units matter? I've seen this bug for example:
Set cluster_count before adding the units (I remember that bug).
> 4. Anything to keep in mind for scaling up and down the rabbitmq and
> percona clusters?
For PXC bear in mind that if you have a large amount of data in your
database, its going to take a bit of time and generate some load in terms
of disk IO and network IO whilst the new unit receive a full state transfer.
I'd also recommend testing your migration process first - this does mean
having some spare kit around to standup a second cloud and then testing the
migration. I believe the above should work fine, but I'd not want you to
trip over the edge case/bug we've not seen during testing in your
OpenStack-operators mailing list