Undesired migrate repository path caching.

[Ilya Pekelny]

Oslo.db migration.py uses singleton to store defined `migrate.versioning.repository.Repository` instance containing migration repository path. Most of plugins have its own migrate repo. Usage of singleton in point of Repository instances causes implicit and unexpected behavior therefore as current Repository instance may contain inappropriate path to migrate repo.

Solution: do not use singleton.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/60877

[Dolph Mathews (dolph)]

How do you reproduce this as a bug? What's the failure?

[Ilya Pekelny (i159)]

Hello, Dolph! I reproduced the bug during the syncing keystone with `openstack/common/db/sqlalchemy/migration.py`.
The failure is:

    AppError: Bad response: 500 Internal Server Error (not 200 OK or 3xx redirect for http://localhost/v3/OS- OAUTH1/consumers/OS-OAUTH1/consumers/OS-OAUTH1/consumers)
    '{"error": {"message": "An unexpected error prevented the server from fulfilling your request. (OperationalError) no such table: consumer u\'INSERT INTO consumer (id, description, secret, extra) VALUES (?, ?, ?, ?)\' (\'0cb09dea1f1046f9b4dc47d0c9a16ad9\', u\'c14c2d8c71444abc8821a676b0d97036\', \'6ff135b84a9a4c089d4fac4179875e35\', \'{}\')", "code": 500, "title": "Internal Server Error"}}'

There is no expected tables because the wrong migrate repo path was used for migrations. I amended the bug report. Now the cause described well, I hope. Feel free to ask.

[Dolph Mathews (dolph)]

Thanks!

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/60877
Committed: https://git.openstack.org/cgit/openstack/oslo-incubator/commit/?id=855644a7e9b850238bc69b35c990a5d82ab48f7e
Submitter: Jenkins
Branch: master

commit 855644a7e9b850238bc69b35c990a5d82ab48f7e
Author: Ilya Pekelny <email address hidden>
Date: Mon Dec 9 19:05:23 2013 +0200

    Removal of _REPOSITORY global variable.

    Oslo.db migration.py uses global variable to store defined
    `migrate.versioning.repository.Repository` instance containing migration
    repository path. At first _find_migrate_repo(repo_path) call the return value
    will be stored in a global variable. So all subsequent calls
    will return the existing global variable value regardless of repo_path
    value passed. This design makes impossible to have multiple migration
    repositories in the same project.
    Detected at syncing of Keystone with Oslo.db.

    Change-Id: If6187a0f7c4590e1c2cd4d998b25ee90aeac17dc
    Closes-Bug: #1259229

[Steve Martinelli (stevemar)]

We no longer have extension specific migrations for reasons just like this. We've collapsed all the extensions into keystone proper and run them all by default. Marking this as fix released.