Public bug reported: We've seen a couple instances now where the wrong migration step is run in tests, when the migration file names in each repo are the same. For example, in the following patch, expand was called, yet the contract file was the one actually run:
Traceback (most recent call last): File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user self.expand(13) File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand self.repos[EXPAND_REPO].upgrade(*args, **kwargs) File "keystone/common/sql/upgrades.py", line 63, in upgrade self.schema_.runchange(ver, change, changeset.step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange change.run(self.engine, step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run script_func(engine) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade migrate.UniqueConstraint(user.c.id, user.c.domain_id, File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ raise AttributeError(key) AttributeError: domain_id http://logs.openstack.org/74/409874/29/check/gate-keystone-python27-db- ubuntu-xenial/d2a60fd/testr_results.html.gz Likewise, morgan was seeing a similar issue here, where the expand migration file wasn't being run, so the test failed the table exist check: https://review.openstack.org/#/c/422817/3/keystone/tests/unit/test_sql_upgrade.py http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2017-01-20.log.html However, both patches would run successfully locally. As a workaround, making the repo file names unique fixes the problem, suggesting that perhaps this is related to the files being cached. ** Affects: keystone Importance: Undecided Assignee: Ron De Rose (ronald-de-rose) Status: New ** Description changed: - We seen a couple instances now where the wrong migration step is run in - tests when the migration file names in each repo are the same. For + We've seen a couple instances now where the wrong migration step is run + in tests when the migration file names in each repo are the same. For example, in the following patch, expand was called, yet the contract file was the one actually run: Traceback (most recent call last): - File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user - self.expand(13) - File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand - self.repos[EXPAND_REPO].upgrade(*args, **kwargs) - File "keystone/common/sql/upgrades.py", line 63, in upgrade - self.schema_.runchange(ver, change, changeset.step) - File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange - change.run(self.engine, step) - File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run - script_func(engine) - File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade - migrate.UniqueConstraint(user.c.id, user.c.domain_id, - File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ - raise AttributeError(key) + File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user + self.expand(13) + File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand + self.repos[EXPAND_REPO].upgrade(*args, **kwargs) + File "keystone/common/sql/upgrades.py", line 63, in upgrade + self.schema_.runchange(ver, change, changeset.step) + File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange + change.run(self.engine, step) + File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run + script_func(engine) + File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade + migrate.UniqueConstraint(user.c.id, user.c.domain_id, + File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ + raise AttributeError(key) AttributeError: domain_id http://logs.openstack.org/74/409874/29/check/gate-keystone-python27-db- ubuntu-xenial/d2a60fd/testr_results.html.gz Likewise, morgan was seeing a similar issue here, where the expand migration file wasn't being run, so the test failed the table exist check: https://review.openstack.org/#/c/422817/3/keystone/tests/unit/test_sql_upgrade.py However, both patches would run successfully locally. As a workaround, making the repo file names unique fixes the problem, suggesting that perhaps this is related to the files being cached. ** Description changed: We've seen a couple instances now where the wrong migration step is run - in tests when the migration file names in each repo are the same. For + in tests, when the migration file names in each repo are the same. For example, in the following patch, expand was called, yet the contract file was the one actually run: Traceback (most recent call last): File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user self.expand(13) File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand self.repos[EXPAND_REPO].upgrade(*args, **kwargs) File "keystone/common/sql/upgrades.py", line 63, in upgrade self.schema_.runchange(ver, change, changeset.step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange change.run(self.engine, step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run script_func(engine) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade migrate.UniqueConstraint(user.c.id, user.c.domain_id, File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ raise AttributeError(key) AttributeError: domain_id http://logs.openstack.org/74/409874/29/check/gate-keystone-python27-db- ubuntu-xenial/d2a60fd/testr_results.html.gz Likewise, morgan was seeing a similar issue here, where the expand migration file wasn't being run, so the test failed the table exist check: https://review.openstack.org/#/c/422817/3/keystone/tests/unit/test_sql_upgrade.py However, both patches would run successfully locally. As a workaround, making the repo file names unique fixes the problem, suggesting that perhaps this is related to the files being cached. ** Description changed: We've seen a couple instances now where the wrong migration step is run in tests, when the migration file names in each repo are the same. For example, in the following patch, expand was called, yet the contract file was the one actually run: Traceback (most recent call last): File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user self.expand(13) File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand self.repos[EXPAND_REPO].upgrade(*args, **kwargs) File "keystone/common/sql/upgrades.py", line 63, in upgrade self.schema_.runchange(ver, change, changeset.step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange change.run(self.engine, step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run script_func(engine) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade migrate.UniqueConstraint(user.c.id, user.c.domain_id, File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ raise AttributeError(key) AttributeError: domain_id http://logs.openstack.org/74/409874/29/check/gate-keystone-python27-db- ubuntu-xenial/d2a60fd/testr_results.html.gz Likewise, morgan was seeing a similar issue here, where the expand migration file wasn't being run, so the test failed the table exist check: https://review.openstack.org/#/c/422817/3/keystone/tests/unit/test_sql_upgrade.py + http://eavesdrop.openstack.org/irclogs/%23openstack-keystone + /%23openstack-keystone.2017-01-20.log.html + However, both patches would run successfully locally. As a workaround, making the repo file names unique fixes the problem, suggesting that perhaps this is related to the files being cached. ** Changed in: keystone Assignee: (unassigned) => Ron De Rose (ronald-de-rose) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1658116 Title: Wrong migration step run when file names are the same Status in OpenStack Identity (keystone): New Bug description: We've seen a couple instances now where the wrong migration step is run in tests, when the migration file names in each repo are the same. For example, in the following patch, expand was called, yet the contract file was the one actually run: Traceback (most recent call last): File "keystone/tests/unit/test_sql_upgrade.py", line 1964, in test_migration_013_add_domain_id_to_user self.expand(13) File "keystone/tests/unit/test_sql_upgrade.py", line 228, in expand self.repos[EXPAND_REPO].upgrade(*args, **kwargs) File "keystone/common/sql/upgrades.py", line 63, in upgrade self.schema_.runchange(ver, change, changeset.step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/schema.py", line 93, in runchange change.run(self.engine, step) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/migrate/versioning/script/py.py", line 148, in run script_func(engine) File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/keystone/common/sql/contract_repo/versions/013_add_domain_id_to_user.py", line 43, in upgrade migrate.UniqueConstraint(user.c.id, user.c.domain_id, File "/home/jenkins/workspace/gate-keystone-python27-db-ubuntu-xenial/.tox/py27/local/lib/python2.7/site-packages/sqlalchemy/util/_collections.py", line 212, in __getattr__ raise AttributeError(key) AttributeError: domain_id http://logs.openstack.org/74/409874/29/check/gate-keystone-python27 -db-ubuntu-xenial/d2a60fd/testr_results.html.gz Likewise, morgan was seeing a similar issue here, where the expand migration file wasn't being run, so the test failed the table exist check: https://review.openstack.org/#/c/422817/3/keystone/tests/unit/test_sql_upgrade.py http://eavesdrop.openstack.org/irclogs/%23openstack-keystone /%23openstack-keystone.2017-01-20.log.html However, both patches would run successfully locally. As a workaround, making the repo file names unique fixes the problem, suggesting that perhaps this is related to the files being cached. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1658116/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
