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