Open Stack

TL;DR: We need reviews on
https://review.openstack.org/#/q/topic:cd/placement-solo+status:open
and work on database management command line tools. More detail
within.

The stack of code, mostly put together by Matt, to get migrating
placement-in-nova to placement-in-placement working is passing its
tests. You can see the remaining pieces of not yet merged code at

     https://review.openstack.org/#/q/topic:cd/placement-solo+status:open

Once that is fully merged, the first bullet point on the extraction
plan at

     http://lists.openstack.org/pipermail/openstack-dev/2018-September/134541.html

will be complete and we'll have a model for how the next two bullet
points can be done.

At this time, there are two main sticking points to getting things
merged:

* The devstack, grenade, and devstack-gate changes need some review
   to make sure that some of the tricks Matt and I performed are
   acceptable to everyone. They are at:

   https://review.openstack.org/600162
   https://review.openstack.org/604454
   https://review.openstack.org/606853

* We need to address database creation scripts and database migrations.

   There's a general consensus that we should use alembic, and start
   things from a collapsed state. That is, we don't need to represent
   already existing migrations in the new repo, just the present-day
   structure of the tables.

   Right now the devstack code relies on a stubbed out command line
   tool at https://review.openstack.org/#/c/600161/ to create tables
   with a metadata.create_all(). This is a useful thing to have but
   doesn't follow the "db_sync" pattern set elsewhere, so I haven't
   followed through on making it pretty but can do so if people think
   it is useful. Whether we do that or not, we'll still need some
   kind of "db_sync" command. Do people want me to make a cleaned up
   "create" command?

   Ed has expressed some interest in exploring setting up alembic and
   the associated tools but that can easily be a more than one person
   job. Is anyone else interested?

It would be great to get all this stuff working sooner than later.
Without it we can't do two important tasks:

* Integration tests with the extracted placement [1].
* Hacking on extracted placement in/with devstack.

Another issue that needs some attention, but is not quite as urgent
is the desire to support other databases during the upgrade,
captured in this change

     https://review.openstack.org/#/c/604028/

[1] There's a stack of code for enabling placement integration tests
starting at https://review.openstack.org/#/c/601614/ . It depends on
the devstack changes.

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