Open Stack

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
>