[Openstack-operators] Cloud Upgrade Strategies
Yuriy Brodskiy
ybrodskiy at gmail.com
Thu Mar 10 07:15:26 UTC 2016
Database only needed for control operations. During upgrade we disable API (mark down on LB or take them down). This will prevent users from making any database changes.
After that flow is "simple"- backup db - do a migration- perform your validation tests
If all good, bring up your api, if not, restore db backup to rollback
I'm over simplifying it here but this is basic concepts. You will find more details in the video
On Wed, Mar 9, 2016 at 10:38 PM -0800, "Xav Paice" <xavpaice at gmail.com> wrote:
On 10 March 2016 at 19:26, Yuriy Brodskiy <ybrodskiy at gmail.com> wrote:
building a new cloud is not practical for real production environments. even if you can afford it, how do you migrate data?
We have been doing upgrades for a while now, and came up with few basic principles:1) you don't have to upgrade all at the same time. do it component at the time2) stand up a new version along side of an existing one, test it and then flip DNS
Take a look at presentation team did during Vancouver summit https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/10-minutes-openstack-upgrades-done
(replying to the list this time, and regretting using gmail)
I readily admit to not having watched that video (but will!) - one question. How do you deal with the db migration if you have two versions running at the same time?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160310/91ad305b/attachment.html>
More information about the OpenStack-operators
mailing list