<div dir="ltr">Hi Sandor<br><br><div class="gmail_quote"><div dir="ltr">On Fri, 26 Jan 2018 at 13:32 Sandor Zeestraten <<a href="mailto:zandor.z@gmail.com">zandor.z@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-size:12.8px">Hey OpenStack Charmers,</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">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.</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">My current plan is test something like this: </div><div style="font-size:12.8px">* Add the new controller machines to the model</div><div style="font-size:12.8px">* Increase the cluster_count from 3 to 6 on the hacluster charm of the services in question</div><div style="font-size:12.8px">* Add units to the service to LXD containers on the new controller machine<br></div><div style="font-size:12.8px">* Wait for things to deploy and cluster</div><div style="font-size:12.8px">* Decrease the cluster_count from 6 to 3</div><div style="font-size:12.8px">* Remove units on the old controller</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">Questions:</div><div style="font-size:12.8px">1. Is there a preferred way to migrate OpenStack services deployed by charms?</div></div></div></blockquote><div><br></div><div>I think your approach above is how I've always envisioned deployments would migrate services between machines.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-size:12.8px">2. Does the plan above look somewhat sane?</div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-size:12.8px">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: <a href="https://bugs.launchpad.net/charm-hacluster/+bug/1424048" target="_blank">https://bugs.launchpad.net/charm-hacluster/+bug/1424048</a></div></div></div></blockquote><div><br></div><div>Set cluster_count before adding the units (I remember that bug).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div style="font-size:12.8px">4. Anything to keep in mind for scaling up and down the rabbitmq and percona clusters?</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div><br></div><div>James</div></div></div>