Open Stack

Hi Sandor

On Fri, 26 Jan 2018 at 13:32 Sandor Zeestraten <zandor.z at 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
>
> Questions:
> 1. Is there a preferred way to migrate OpenStack services deployed by
> charms?
>

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:
> https://bugs.launchpad.net/charm-hacluster/+bug/1424048
>

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
production environment.

Cheers

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180202/97d8549d/attachment.html>