Excerpts from Dan Smith's message of 2017-05-26 07:56:02 -0700: > > As most of the upgrade issues center around database migrations, we > > discussed some of the potential pitfalls at length. One approach was to > > roll-up all DB migrations into a single repository and run all upgrades > > for a given project in one step. Another was to simply have mutliple > > python virtual environments and just run in-line migrations from a > > version specific venv (this is what the OSA tooling does). Does one way > > work better than the other? Any thoughts on how this could be better? > > IMHO, and speaking from a Nova perspective, I think that maintaining a > separate repo of migrations is a bad idea. We occasionally have to fix a > migration to handle a case where someone is stuck and can't move past a > certain revision due to some situation that was not originally > understood. If you have a separate copy of our migrations, you wouldn't > get those fixes. Nova hasn't compacted migrations in a while anyway, so > there's not a whole lot of value there I think. > > The other thing to consider is that our _schema_ migrations often > require _data_ migrations to complete before moving on. That means you > really have to move to some milestone version of the schema, then > move/transform data, and then move to the next milestone. Since we > manage those according to releases, those are the milestones that are > most likely to be successful if you're stepping through things. > > I do think that the idea of being able to generate a small utility > container (using the broad sense of the word) from each release, and > using those to step through N, N+1, N+2 to arrive at N+3 makes the most > sense. > > Nova has offline tooling to push our data migrations (even though the > command is intended to be runnable online). The concern I would have
It seems like it would be very useful to have a tool like this for all projects that support online data migrations, no matter if they are written in python, as DB triggers, or whatever. > would be over how to push Keystone's migrations mechanically, since I > believe they moved forward with their proposal to do data migrations in > stored procedures with triggers. Presumably there is a need for > something similar to nova's online-data-migrations command which will > trip all the triggers and provide a green light for moving on? > > In the end, projects support N->N+1 today, so if you're just stepping > through actual 1-version gaps, you should be able to do as many of those > as you want and still be running "supported" transitions. There's a lot > of value in that, IMHO. +1 > > --Dan > _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators