Open Stack

On 11/4/23 17:16, Eugen Block wrote:
> I don't really have more input than what I reported in the mentioned 
> thread. I'm also not familiar with kolla-ansible, unfortunately. But I 
> would check for files with the non-existing revision number on the 
> control node(s)? Something like this depending on your distro could 
> reveal something:
> 
> # find 
> /usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/ -name *6135a7bd4425*

Two matches in the same layer of the same Docker volume:
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/__pycache__/6135a7bd4425_add_rbac_support_for_address_group.cpython-38.pyc
/usr/lib/python3/dist-packages/neutron/db/migration/alembic_migrations/versions/wallaby/expand/6135a7bd4425_add_rbac_support_for_address_group.py

I have no time to look further right now though.

> If there are files that don't belong there remove them and retry the 
> neutron-db-manage commands with the correct revisions in the table. But 
> if you're using containers I'd be curious how those files would get 
> there... Does a release change in the globals.yaml also redeploy control 
> containers? But on the other hand, you seem to have deployed only a 
> compute node with wallaby? I hope someone with kolla-ansible experience 
> can chime in here.

It only deployed wallaby containers to the compute node, but a neutron 
container on that node then appears to have run `neutron-db-manage 
upgrade` and changed the database schema.

> Sorry if I can't be more helpful...

No problem, thank you for the attempt. We managed to revert the changes 
- I'll post separately.