Created attachment 1256108 [details] log Description of problem: OSP10 -> OSP11 upgrade fails during neutron-db-manage upgrade heads: oslo_db.exception.DBError: (pymysql.err.InternalError) (1060, u"Duplicate column name 'tenant_id'") [SQL: u'ALTER TABLE bsn_routerrules ADD COLUMN tenant_id VARCHAR(255)'] Version-Release number of selected component (if applicable): python-networking-bigswitch-10.0.0-0.20170211205641.584bf2d.el7ost.noarch openstack-neutron-bigswitch-agent-10.0.0-0.20170211205641.584bf2d.el7ost.noarch openstack-neutron-bigswitch-lldp-10.0.0-0.20170211205641.584bf2d.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Upgrade OSP10 to OSP11 Actual results: Upgrade fails during neutron-db-manage upgrade heads. Expected results: Additional info: Attaching full trace.
Looking at the u/s Launchpad it's unclear to me if the issue was resolved or not. Any ideas?
(In reply to Assaf Muller from comment #1) > Looking at the u/s Launchpad it's unclear to me if the issue was resolved or > not. Any ideas? FWIW the issue is still present in the latest downstream build.
@Marius can you spec the version of the packages in the lastest build? I'm trying to work out if we have the u/s patch that was supposed to fix this or not.
(In reply to Brent Eagles from comment #3) > @Marius can you spec the version of the packages in the lastest build? I'm > trying to work out if we have the u/s patch that was supposed to fix this or > not. openstack-neutron-bigswitch-agent-10.0.0-0.20170224232203.1f1208d.el7ost.noarch.rpm openstack-neutron-bigswitch-lldp-10.0.0-0.20170224232203.1f1208d.el7ost.noarch.rpm python-networking-bigswitch-10.0.0-0.20170224232203.1f1208d.el7ost.noarch.rpm
Unless I'm missing something, comparing with the u/s bug referenced here with the initial comment, these look like two (or more?) different issues. The one reported u/s is to do with an args mismatch on a decorator - this one is a duplicate field issue. Which is still occurring, the reported u/s issue, the one referenced later in comment 5 in the launchpad bug, or the original one for this bug report?
(In reply to Brent Eagles from comment #5) > Unless I'm missing something, comparing with the u/s bug referenced here > with the initial comment, these look like two (or more?) different issues. > The one reported u/s is to do with an args mismatch on a decorator - this > one is a duplicate field issue. Which is still occurring, the reported u/s > issue, the one referenced later in comment 5 in the launchpad bug, or the > original one for this bug report? Sorry, I missed the details but it seems they are different issues. The issue that I see with the downstream testing is the one in the trace attached to this report.
I've linked a more closely matched bug - same error actually. This should probably also be moved to the python-networking-bigswitch component.
This seems like a bit of an oddity. It looks like at one point in time, this database change was backported "way back" in time. It broke u/s CI in newton and the patch that was added this column was reverted (although it didn't seem to be for previous releases). It might be a good idea to check the bigswitch tables prior to upgrade to see if this column actually does already exist in the database and if so, how? Is the current "HEAD" for the database properly set so the alembic check prevents a second run? I've cloned this bug to python-networking-bigswitch because they should probably jump in here and sort it out - especially if it is going to involved patches to code or packaging.
This is also happening while installing rhos11, not just upgrading from 10 to 11.
Do you think we need to keep this RHBZ open with https://bugzilla.redhat.com/show_bug.cgi?id=1434843 ON_QA?
No. I'll move to modified so QA can verify.
*** This bug has been marked as a duplicate of bug 1434843 ***