Open Stack

On 12/21/2018 05:18 AM, Chris Dent wrote:
> 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).

+1000

This is how Swift works [1] and is the least operational burden of all 
approaches I've seen.

> 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.

I haven't looked at the WIP patch for this yet. I will try to do that soon.

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

Agreed.

Best,
-jay

[1] examples: 
https://github.com/openstack/swift/blob/a7aa2329584f1d02f7d1fa205d56aeadffdc980f/swift/account/backend.py#L557-L632