[neutron][db] Train: neutron-db-manage can't locate revision

Eugen Block eblock at nde.ag
Tue Mar 30 09:16:32 UTC 2021


Hi *,

I have a new issue with our Train cloud (upgraded through the years).  
Currently I'm preparing the next upgrade step to Ussuri and stumbled  
upon this neutron db issue:


---snip---
controller01:~ # neutron-db-manage current
   Running current for neutron ...
INFO  [alembic.runtime.migration] Context impl MySQLImpl.
INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
ERROR [alembic.util.messaging] Can't locate revision identified by  
'e4e236b0e1ff'
   FAILED: Can't locate revision identified by 'e4e236b0e1ff'


controller01:~ # neutron-db-manage revision --contract
   Running revision for neutron ...
   Generating  
/usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/contract/b5344a66e818_.py ...  
done
   OK


controller01:~ # neutron-db-manage revision --expand
   Running revision for neutron ...
   Generating  
/usr/lib/python3.6/site-packages/neutron/db/migration/alembic_migrations/versions/train/expand/633d74ebbc4b_.py ...  
done
   OK


controller01:~ # neutron-db-manage heads
   Running heads for neutron ...
6c9eb0469914 (expand) (head)
c43a0ddb6a03 (contract) (head)
   OK
---snip---


I've been searching how that revision got into the database but I  
can't find any hint where that e4e236b0e1ff belongs to. To test the  
upgrade process I have a VM that was initially setup with Ocata, I'm  
able to investigate a snapshot from before the Pike upgrade, and I  
can't find a clue either, except for the neutron database.
Although our current setup works just fine I'm not sure if this will  
be a show stopper for the Ussuri upgrade, although it wasn't for the  
previous upgrades.

Anyway, how would I resolve this? I see these versions in the  
neutron.alembic_version table:

+--------------+
| version_num  |
+--------------+
| 5c85685d616d |
| e4e236b0e1ff |
+--------------+

And 5c85685d616d seems to be a valid version from Newton, it seems.  
Could anyone provide some guidance on how to fix this before the next  
uprade? If possible I would like to avoid making manual changes in the  
database myself.

Thanks and best regards,
Eugen




More information about the openstack-discuss mailing list