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" <xavpa...@gmail.com> wrote: On 10 March 2016 at 19:26, Yuriy Brodskiy <ybrods...@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?
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
