Open Stack

On Wed, 19 Dec 2018, TETSURO NAKAMURA wrote:

> 1. Do it in the alembic script in the same way as the schema expansion
> 2. Have two stable version branches for alembic to separate schema changes 
> and data manipulation
> 3. Bring the online-migration batch CLI command
> 4. Any other ideas?

> Since it looks like it's going to have an impact both on operators who 
> upgrade and developers who add new features in placement, it is nice to seek 
> more ideas and to have a consensus before we go further.

As I said on the review of https://review.openstack.org/#/c/624942/
I'm somewhat reluctant to add yet another command, simply because
each moving part is another thing to know about and to manage, and
sometimes, yet another command to run. In that sense of the options
presented, I prefer option 1, but Dan makes good points on
https://review.openstack.org/#/c/619126/ . The idealist in me thinks
that we ought to be able to:

* ensure any migrations we do (schema or data) that need to be
   done from the command line are quick and light
* enable anything that is neither quick nor light on an as needed
   basis in the running code

Where this latter option with root id went wrong is that the
implementation was incomplete: It didn't cover all the cases where a
root id would be involved, or perhaps we added cases later that
didn't account for that possibility. In either case we didn't make
good enough tests.

However: the command that's been implemented in 624942 is pretty
clean and if it is what people think is the best solution, it's
likely the shortest path for us to have something that works and
keep the most people happy is using it.

Unless we hear from other people we should probably just go with
that, but we should wait until January to decide since not many
people are around now.

For the record, my real preference is that we have neither of
'db sync' nor 'db online-data-migration' commands and simply do
those things when the server process starts itself (but before
listening on a socket). There's a WIP for that in
https://review.openstack.org/#/c/619050/ . I've not pursued that too
aggressively because people don't seem that into it, but, to me,
having placement self contained with as few additional processes is
the way to have the most flexibility. However, my position doesn't
take into account the many diverse ways that people deploy their
clouds.

Which is why we need input from the larger community on these kinds
of decisions.

Thanks.

-- 
Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent