[openstack-dev] [placement] devstack, grenade, database management

Matt Riedemann mriedemos at gmail.com
Tue Oct 16 20:38:20 UTC 2018


On 10/16/2018 5:48 AM, Chris Dent wrote:
> * 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 thing that came up today in IRC [1] which is maybe not as 
obvious from this email is what happens with the one online data 
migration we have for placement (create_incomplete_consumers). If we 
drop that online data migration from the placement repo, then ideally 
we'd have something to check it's done before people upgrade to stein 
and the extracted placement repo. There are some options there: 
placement-manage db sync could fail if there are missing consumers or we 
could simply have a placement-status upgrade check for it.

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

I have a grenade patch to test the postgresql-migrate-db.sh script now. [2]

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2018-10-16.log.html#t2018-10-16T19:37:25
[2] https://review.openstack.org/#/c/611020/

-- 

Thanks,

Matt



More information about the OpenStack-dev mailing list