Bug 1879788 - RHOSP13 Minor update | "Duplicate column name 'created_at'\") [SQL: u'ALTER TABLE nsxv_router_bindings ADD COLUMN created_at DATETIME'
Summary: RHOSP13 Minor update | "Duplicate column name 'created_at'\") [SQL: u'ALTER T...
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 13.0 (Queens)
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: ---
Assignee: Dan Radez
QA Contact: Eran Kuris
Depends On:
TreeView+ depends on / blocked
Reported: 2020-09-17 02:15 UTC by chrisbro@redhat.com
Modified: 2020-10-26 12:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-09-25 13:28:03 UTC
Target Upstream Version:

Attachments (Terms of Use)

Comment 2 Brendan Shephard 2020-09-17 03:01:19 UTC
This DB migration seems to be quite old (credit to tkajinam++)


Seems odd to be trying to do this migration that was included 4 years ago. The created_at column clearly exists in the table. Checking the versions of openstack-neutron and the container versions, everything seems to be at the latest available:

╰─ grep neutron installed-rpms
openstack-neutron-12.1.1-18.el7ost.noarch                   Wed Sep 16 18:35:53 2020


Which is the latest available:

There seems to be a conflict somewhere here. We'll keep digging to see where the older Revision ID is coming from.

Comment 3 Brendan Shephard 2020-09-17 03:22:28 UTC
Are we able to get the output from the following on one of the controllers?

docker exec -it neutron_api neutron-db-manage current --verbose


ssh heat-admin@controller_ip
[root@overcloud-controller-0 ~]# sudo su -
[root@overcloud-controller-0 ~]# docker exec -it neutron_api neutron-db-manage current --verbose

Comment 8 Dan Radez 2020-09-17 14:16:16 UTC
python-networking-vmware-nsx is installed by default laying down files in /usr/lib/python2.7/site-packages/vmware_nsx

Comment 12 Dan Radez 2020-09-17 16:43:03 UTC
I'm working on rebuilding the tables to aede17d51d0f for import, then we can force set the alembic version to match.

Comment 18 Bernard Cafarelli 2020-09-25 13:28:03 UTC
Fixed on customer site cleaning the (unused anyway) tables and recreating them to proper state before attempting update again, which succeeded

Note You need to log in before you can comment on or make changes to this bug.