Ask Your Question

How to best resolve the debian nova-cell_v2 update catch22?

asked 2019-08-01 05:22:57 -0500

Aphid gravatar image

Suppose I have the openstack database in a separate database cluster and I'm distro-upgrading the debian machines. This is a relatively small installation, so I am not running into scaling issues and thus do not want to actually use cells, so the simple cell setup should be sufficient for my needs.

After installation completes of new openstack components, I have to run their database upgrade scripts. However nova's upgrade script nova-manage api_db syncfails with the message nova.exception.ValidationError: Cell mappings are not created, but required for Ocata. Please run nova-manage cell_v2 simple_cell_setup before continuing.

So I've created the nova_cell0 database, given the nova SQL user full rights to it, then ran nova-manage cell_v2 simple_cell_setup. I've also tried nova-manage cell_v2 map_cell0 --database_connection mysql+pymysql://nova:V8Ek53A7LT0qRS1k@ Both of these fail with the following message (truncated):

oslo_db.exception.DBError: (pymysql.err.InternalError) (1054, "Unknown column 'disabled' in 'field list'") [SQL: 'INSERT INTO cell_mappings (created_at, updated_at, uuid, name, transport_url, database_connection, disabled) VALUES (%(created_at)s, %(updated_at)s, %(uuid)s, %(name)s, %(transport_url)s, %(database_connection)s, %(disabled)s)'] [parameters: (...)

In other words, the cell_v2 script wants me to update the database as it's trying to access a column that does not yet exist, and the update-the-database-script wants me to create a cell_v2. I believe I've tried creating cells in the old Newton version and failed to do so because of other bugs, so that's a no-go either.

I don't think manually messing about in the database is a great idea either; it may break the update script in unknown ways, I've read that someone stated it wasn't idempotent.

What's the best way to resolve these problems?

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2019-08-01 06:42:37 -0500

Aphid gravatar image

For now, I've attempted to solve this by manually running the following two queries in the nova_api database.

ALTER TABLE instance_mappings ADD COLUMN `queued_for_delete` BOOLEAN DEFAULT FALSE;

Then, afterwards, running

nova-manage api_db sync
nova-manage db sync

This appears to cause the automatic migration script to now function.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower


Asked: 2019-08-01 05:03:56 -0500

Seen: 46 times

Last updated: Aug 01