yahoo-eng-team team mailing list archive

[Ron De Rose <ronald.de.rose@xxxxxxxxx>]

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