[neutron][db] Train: neutron-db-manage can't locate revision
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
On 30/03/2021 11:16, Eugen Block wrote:
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
Hi Eugen, it looks like you've run the db update with Ussuri code already. e4e236b0e1ff was added in that cycle and 5c85685d616d is the contract head since Newton (seems like there has not been a change since). I think what you need is to update your alembic scripts to Ussuri and run the "update heads" command again. This should bring the DB schema to Ussuri version because it knows the revisions. I hope it helps. Best regards, Jakub
Thank you, Jakub.
it looks like you've run the db update with Ussuri code already.
That can't be true, my virtual controller runs on Ussuri and it reports these: ---snip--- controller-vm:~ # neutron-db-manage current Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. 5c85685d616d (head) d8bdf05313f4 (head) OK ---snip--- There's also no sign of mentioned missing revision, I grepped in /usr/lib/... without finding anything related to that.
I think what you need is to update your alembic scripts to Ussuri and run the "update heads" command again. This should bring the DB schema to Ussuri version because it knows the revisions.
Since I'm planning to upgrade to Ussuri anyway that's probably what will resolve this, I assume. But as I said, I'm confused why I don't find anything related to e4e236b0e1ff. Regards, Eugen Zitat von Jakub Libosvar <jlibosva@redhat.com>:
On 30/03/2021 11:16, Eugen Block wrote:
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
Hi Eugen,
it looks like you've run the db update with Ussuri code already.
e4e236b0e1ff was added in that cycle and 5c85685d616d is the contract head since Newton (seems like there has not been a change since).
I think what you need is to update your alembic scripts to Ussuri and run the "update heads" command again. This should bring the DB schema to Ussuri version because it knows the revisions.
I hope it helps.
Best regards, Jakub
Interesting, I downloaded the latest ussuri rpm for python3-neutron and indeed, I see this line: revision = 'e4e236b0e1ff' But apparently my VM doesn't have that, I wonder how that could be. And the more important question is, how did that version get into the Train control nodes, they have never seen an Ussuri repository. But I did run the database migrations on said VM, so the only logical explanation is that the VM was in an inconsistent state, I guess. Anyway, I assume that after I upgrade the packages on the control nodes I'll have this mess cleaned up. Thanks again! Eugen Zitat von Eugen Block <eblock@nde.ag>:
Thank you, Jakub.
it looks like you've run the db update with Ussuri code already.
That can't be true, my virtual controller runs on Ussuri and it reports these:
---snip--- controller-vm:~ # neutron-db-manage current Running current for neutron ... INFO [alembic.runtime.migration] Context impl MySQLImpl. INFO [alembic.runtime.migration] Will assume non-transactional DDL. 5c85685d616d (head) d8bdf05313f4 (head) OK ---snip---
There's also no sign of mentioned missing revision, I grepped in /usr/lib/... without finding anything related to that.
I think what you need is to update your alembic scripts to Ussuri and run the "update heads" command again. This should bring the DB schema to Ussuri version because it knows the revisions.
Since I'm planning to upgrade to Ussuri anyway that's probably what will resolve this, I assume. But as I said, I'm confused why I don't find anything related to e4e236b0e1ff.
Regards, Eugen
Zitat von Jakub Libosvar <jlibosva@redhat.com>:
On 30/03/2021 11:16, Eugen Block wrote:
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
Hi Eugen,
it looks like you've run the db update with Ussuri code already.
e4e236b0e1ff was added in that cycle and 5c85685d616d is the contract head since Newton (seems like there has not been a change since).
I think what you need is to update your alembic scripts to Ussuri and run the "update heads" command again. This should bring the DB schema to Ussuri version because it knows the revisions.
I hope it helps.
Best regards, Jakub
participants (2)
-
Eugen Block
-
Jakub Libosvar