Created attachment 953274 [details] install and config logs Description of problem: [mNotice: /Stage[main]/Main/Exec[neutron-db-manage upgrade]/returns: sqlalchemy.exc.OperationalError: (OperationalError) (1832, "Cannot change column 'l3_agent_id': used in a foreign key constraint 'routerl3agentbindings_ibfk_1'") 'ALTER TABLE routerl3agentbindings ADD CONSTRAINT pk_routerl3agentbindings PRIMARY KEY (router_id, l3_agent_id)' ()[0m [1;31mError: neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head returned 1 instead of one of [0][0m [1;31mError: /Stage[main]/Main/Exec[neutron-db-manage upgrade]/returns: change from notrun to 0 failed: neutron-db-manage --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugin.ini upgrade head returned 1 instead of one of [0][0m see trace in _neutron_pp.log attached /var/tmp/packstack
I'll try to look into this later today.
OK, I haven't yet confirmed what may be the issue is. So far, facts that seem likely so far are: 1. this issue has not been reported on any launchpad issue for neutron. 2. the error message seems to be a feature that was first added to MySQL in 5.6.7, mentioned here: http://dev.mysql.com/doc/refman/5.6/en/alter-table.html. The idea is that if an operation modifies a column that is referred to by foreign key, and the operation modifies it such that values within the column will break the link to an existing FK record, this error is emitted. MySQL bug [1] shows where they started doing this. 3. I'm not able to find through documentation alone what exactly adding a PK constraint would do here. My vague theory so far is that the add of the PK constraint, which changes the nullable status of the column to 'NOT NULL DEFAULT ""', is triggering the issue. However, running an equivalent test on a somewhat arbitrary MySQL version (5.6.16) fails to reproduce this condition. The bug reported at [1] illustrates this breaking an FK reference due to the presence of an actual NULL value in the table which can only be part of an FK reference as a composite FK, which is not the case here; additionally, if I just try altering with a NULL value in the column here, I get the more expected error which is "Invalid use of NULL value", in terms of the primary key. So I need to get the exact mariadb-galera-server-10.0.13-6.fc21.x86_64 running on an F21 instance and see if I can reproduce this. I have a local script I'm using to simulate the same operations, which is attached. In any case, if my #3 theory is at least somewhat correct, it would have to be determined if the error message is driven by the presence of data within the table, particularly a NULL value; if that's the case, then the migration here isn't valid with that data and the source of this NULL would have to be narrowed down. Alternatively, if the issue is structural only and not related to NULL data, then the migration here may have to be altered to temporarily drop the FK constraint, which it does do in other contexts already (the script is 31d7f831a591_add_constraint_for_routerid.py). [1] http://bugs.mysql.com/bug.php?id=46599
Created attachment 953878 [details] a sqlalchemy/alembic script which runs the essential operations of the issue
> 1. this issue has not been reported on any launchpad issue for neutron. Lukas attached under External Trackers here: https://bugs.launchpad.net/neutron/+bug/1384555
well OK! I tried pretty hard using the advanced search to find an issue with any of that error text in it, I wonder if launchpad search is not very good...
oh its under external trackers. OK! please ignore then....
*** This bug has been marked as a duplicate of bug 1157599 ***