Jay, I agree with your distinction - and when I am referring to rolling upgrades for keystone I am referring to when you are running a cluster of keystones (for performance and/or redundancy), and you want to roll the upgrade across the cluster without creating downtime of the overall keystone service. Such a keystone cluster deployment will be common in large clouds - and prior to Newton, keystone did not support such a rolling upgrade (you had to take all the nodes down, upgrade the DB and then boot them all back up). In order to support such a rolling upgrade you either need to have code that can work on different DB versions (either explicitly or via versioned objects), or you hide the schema changes by “data synchronisation via Triggers”, which is where this whole thread came from.
Henry > On 14 Sep 2016, at 23:08, Jay Pipes <jaypi...@gmail.com> wrote: > > On 09/01/2016 05:29 AM, Henry Nash wrote: >> So as the person who drove the rolling upgrade requirements into >> keystone in this cycle (because we have real customers that need it), >> and having first written the keystone upgrade process to be >> “versioned object ready” (because I assumed we would do this the same >> as everyone else), and subsequently re-written it to be “DB Trigger >> ready”…and written migration scripts for both these cases for the (in >> fact very minor) DB changes that keystone has in Newton…I guess I >> should also weigh in here :-) > > Sorry for delayed response. PTO and all... I'd just like to make a > clarification here. Henry, you are not referring to *rolling upgrades* but > rather *online database migrations*. There's an important distinction between > the two concepts. > > Online schema migrations, as discussed in this thread, are all about > minimizing the time that a database server is locked or otherwise busy > performing the tasks of changing SQL schemas and moving the underlying stored > data from their old location/name to their new location/name. As noted in > this thread, there's numerous ways of reducing the downtime experienced > during these data and schema migrations. > > Rolling upgrades are not the same thing, however. What rolling upgrades refer > to is the ability of a *distributed system* to have its distributed component > services running different versions of the software and still be able to > communicate with the other components of the system. This time period during > which the components of the distributed system may run different versions of > the software may be quite lengthy (days or weeks long). The "rolling" part of > "rolling upgrade" refers to the fact that in a distributed system of > thousands of components or nodes, the upgraded software must be "rolled out" > to those thousands of nodes over a period of time. > > Glance and Keystone do not participate in a rolling upgrade, because Keystone > and Glance do not have a distributed component architecture. Online data > migrations will reduce total downtime experienced during an *overall upgrade > procedure* for an OpenStack cloud, but Nova, Neutron and Cinder are the only > parts of OpenStack that are going to participate in a rolling upgrade because > they are the services that are distributed across all the many compute nodes. > > Best, > -jay > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
