too old oslo.config: AttributeError: 'module' object has no attribute 'DeprecatedOpt'

[Lucas Alvares Gomes]

quantum-server is failing to start with:

Traceback (most recent call last):
  File "/opt/stack/venvs/quantum/bin/quantum-server", line 8, in <module>
    load_entry_point('quantum==2013.2.a3.g090432c', 'console_scripts', 'quantum-server')()
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/pkg_resources.py", line 347, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/pkg_resources.py", line 2517, in load_entry_point
    return ep.load()
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/pkg_resources.py", line 2211, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/quantum/server/__init__.py", line 26, in <module>
    from quantum.common import config
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/quantum/common/config.py", line 29, in <module>
    from quantum.openstack.common.db.sqlalchemy import session as db_session
  File "/opt/stack/venvs/quantum/local/lib/python2.7/site-packages/quantum/openstack/common/db/sqlalchemy/session.py", line 283, in <module>
    deprecated_opts=[cfg.DeprecatedOpt('sql_connection',
AttributeError: 'module' object has no attribute 'DeprecatedOpt'

Seems that something was merged in quantum that depends on trunk unreleased oslo components.

Oslo version I've installed: oslo.config-1.1.1

[yong sheng gong (gongysh)]

what version of your oslo are u using?

try to remove your current oslo module in system and then install: http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2.

For example:
cd /usr/local/lib/python2.7/dist-packages/
rm -rf oslo
pip install http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2

[Lucas Alvares Gomes (lucasagomes)]

Hey gongysh,

Thanks for that, worked great!

[root@localhost ~]# systemctl status quantum-server
quantum-server.service - quantum-server Service
   Loaded: loaded (/usr/lib/systemd/system/quantum-server.service; enabled)
   Active: active (running) since Wed 2013-06-26 06:03:47 EDT; 6s ago
 Main PID: 4767 (quantum-server)
   CGroup: name=systemd:/system/quantum-server.service
           └─4767 /opt/stack/venvs/quantum/bin/python /opt/stack/venvs/quantum/bin/quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini ...

...

[Robert Collins (lifeless)]

Ok, so not a quantum bug; we have something polluting the site packages.

[Mathieu Rohon (mathieu-rohon)]

I have the same issue when I do a quantum/run_test.sh

[Kyle Mestery (mestery)]

Same issue for me when running quantum tests or even starting quantum server. I can confirm Yong's workaround fixed the issue, however.

[Lucas Alvares Gomes (lucasagomes)]

Another workaround would be to remove the /lib/python2.7/site-packages/oslo.config-1.1.1-py2.7-nspkg.pth file which seems to be setting the old version as the default oslo

(quantum)[root@localhost /]# quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini --config-dir /etc/quantum
Traceback (most recent call last):
  File "/opt/stack/venvs/quantum/bin/quantum-server", line 8, in <module>
    load_entry_point('quantum==2013.2.a3.g090432c', 'console_scripts', 'quantum-server')()
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/pkg_resources.py", line 347, in load_entry_point
    return get_distribution(dist).load_entry_point(group, name)
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/pkg_resources.py", line 2517, in load_entry_point
    return ep.load()
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/pkg_resources.py", line 2211, in load
    entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/quantum/server/__init__.py", line 26, in <module>
    from quantum.common import config
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/quantum/common/config.py", line 29, in <module>
    from quantum.openstack.common.db.sqlalchemy import session as db_session
  File "/opt/stack/venvs/quantum/lib/python2.7/site-packages/quantum/openstack/common/db/sqlalchemy/session.py", line 283, in <module>
    deprecated_opts=[cfg.DeprecatedOpt('sql_connection',
AttributeError: 'module' object has no attribute 'DeprecatedOpt'
(quantum)[root@localhost /]# mv /lib/python2.7/site-packages/oslo.config-1.1.1-py2.7-nspkg.pth /tmp/
(quantum)[root@localhost /]# quantum-server --config-file /etc/quantum/quantum.conf --config-file /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini --config-dir /etc/quantum
2013-06-26 11:17:39.791 27692 INFO quantum.common.config [-] Logging enabled!
2013-06-26 11:17:39.791 27692 DEBUG quantum.service [-] ******************************************************************************** log_opt_values /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/config/cfg.py:1572
2013-06-26 11:17:39.791 27692 DEBUG quantum.service [-] Configuration options gathered from: log_opt_values /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/config/cfg.py:1573
2013-06-26 11:17:39.791 27692 DEBUG quantum.service [-] command line args: ['--config-file', '/etc/quantum/quantum.conf', '--config-file', '/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini', '--config-dir', '/etc/quantum'] log_opt_values /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/config/cfg.py:1574
2013-06-26 11:17:39.791 27692 DEBUG quantum.service [-] config files: ['/etc/quantum/quantum.conf', '/etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini'] log_opt_values /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/config/cfg.py:1575
2013-06-26 11:17:39.791 27692 DEBUG quantum.service [-] ================================================================================ log_opt_values /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/config/cfg.py:15...

[Armando Migliaccio (armando-migliaccio)]

As far as I can tell Yong's fix does not apply when running tests in a virtualenv.

[Joe Gordon (jogo)]

Here is the problem:

Installing collected packages: Paste, PasteDeploy, Routes, amqplib, eventlet, greenlet, httplib2, iso8601, kombu, netaddr, python-quantumclient, pyudev, sqlalchemy, WebOb, python-keystoneclient, alembic, oslo.config-1.2.0a2, stevedore, python-novaclient, repoze.lru, amqp, cliff, pyparsing, simplejson, oslo.config, Mako, cmd2, MarkupSafe
  Running setup.py install for Paste
<...>
  Running setup.py install for oslo.config-1.2.0a2
<...>
  Running setup.py install for oslo.config
    Skipping installation of /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo/__init__.py (namespace package)

    warning: no previously-included files found matching '.gitignore'
    warning: no previously-included files found matching '.gitreview'
    Installing /opt/stack/venvs/quantum/lib/python2.7/site-packages/oslo.config-1.1.1-py2.7-nspkg.pth

http://54.228.118.193/toci/toci_logs_W9TkGtY/setup.out

in the quantum venv we isntall the correct version and then the wrong version afterwards

[Joe Gordon (jogo)]

The oslo.config 1.2 requirement is coming directly from quantum (https://review.openstack.org/#/c/33429/) The second oslo.config is coming from python-keystoneclient. and because oslo.config-1.2.0a2 is an alpha and oslo.config>1.1 is not, pip overwrites oslo.config-1.2.0a2 with oslo.config-1.1

[Joe Gordon (jogo)]

How to reproduce:

reqs.txt:
python-keystoneclient>=0.2.0
http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2

virtualenv venv
source venv/bin/activate
pip install -r reqs.txt
pip freeze

$ pip freeze
argparse==1.2.1
d2to1==0.2.10
iso8601==0.1.4
oslo.config==1.1.1
pbr==0.5.17
prettytable==0.7.2
python-keystoneclient==0.3.0
requests==1.2.3
setuptools-git==1.0b1
simplejson==3.3.0
six==1.3.0
wsgiref==0.1.2

[yong sheng gong (gongysh)]

so I think the fix should be to push a new official version of oslo.config-1.2.0

[Mark McLoughlin (markmc)]

> because oslo.config-1.2.0a2 is an alpha and oslo.config>1.1 is not, pip overwrites oslo.config-1.2.0a2 with oslo.config-1.1

Oh, what the hell? That's insane

[Derek Higgins (derekh)]

oslo.config stopped generating a .pth file as of

commit d47560cce25d87212f852891a762e41c40535c7f
    Merge "Update build to use pbr."

installing oslo.config in a venv (with oslo 1.1.1 installed system wide), I can reproduce what looks like the problem after the switch to using pbr

Before pbr
$ venv/bin/python -d -c 'import oslo.config ; print oslo.config.__file__'
/root/tmp/venv/local/lib/python2.7/site-packages/oslo/config/__init__.pyc
$ find venv/ | grep -i .pth | grep oslo
venv/lib/python2.7/site-packages/oslo.config-1.2.0.a17.g1c1ae83-py2.7-nspkg.pth
$

After pbr
$ venv/bin/python -d -c 'import oslo.config ; print oslo.config.__file__'
/usr/local/lib/python2.7/dist-packages/oslo/config/__init__.pyc
$ find venv/ | grep -i .pth | grep oslo
$

A new release of oslo.config would possibly solve this for new systems that don't have the old release installed, but would the correct solution be to figure out how to have the oslo.config versions prioritized correctly once again?

[Mark McLoughlin (markmc)]

I can't shake the feeling this is somehow related to bug #1194742

[Derek Higgins (derekh)]

Ahh, I had a hunch it had something todo with namespace_packages but couldn't yet figure out how to get oslo to include it in the tarball.

The pth file seems to get written out by setuptools/command/install_egg_info.py in install_namespaces which does nothing if namespaces don't exist

        if not nsp: return

[Mark McLoughlin (markmc)]

Ok, well here's confirmation that using 'pip install -r quantum/requirements.txt' doesn't result in oslo.config 1.2.0a2 winning:

 $> virtualenv t
 $> . ./t/bin/activate
 $> pip install http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2 python-keystoneclient
 $> python -c 'from oslo.config.cfg import DeprecatedOpt'
 Traceback (most recent call last):
   File "<string>", line 1, in <module>
 ImportError: cannot import name DeprecatedOpt
 $> pip freeze | grep oslo.config
 oslo.config==1.1.1

This seems like a pip bug to me because if you install each of these individually, 1.2.0a2 does win:

 $> virtualenv t2
 $> . ./t2/bin/activate
 $> pip install http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2
 $> pip install python-keystoneclient
 $> python -c 'from oslo.config.cfg import DeprecatedOpt'
 $> pip freeze | grep oslo.config
 oslo.config==1.2.0a2

However, another thing to note is that between devstack and pbr, you actually see different semantics when doing this in devstack. That's because 'python setup.py egg_info' with pbr writes out 'oslo.config>=1.2.0a2' in requires.txt and the URL in dependency_links.txt so devstack winds up doing:

 $> virtualenv t1
 $> . ./t1/bin/activate
 $> pip install -f http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2 'oslo.config>=1.2.0a2' python-keystoneclient
 $> python -c 'from oslo.config.cfg import DeprecatedOpt'
 $> pip freeze | grep oslo.config
 oslo.config==1.2.0a2

[Mark McLoughlin (markmc)]

Thanks for looking into this Derek

I think the only sane conclusion is that we really need to fix bug #1194742 and see if that helps. We don't know for certain it will be enough to fix this issue, but it's very likely its at least a related issue.

[Mark McLoughlin (markmc)]

ok, now that bug #1194742 is fixed ...

  $> virtualenv t5
  $> . t5/bin/activate
  $> pip install http://tarballs.openstack.org/oslo.config/oslo.config-master.tar.gz#egg=oslo.config-1.2.0.a34.g08203f6/ python-keystoneclient
  $> python -c 'from oslo.config.cfg import DeprecatedOpt'Traceback (most recent call last):
   File "<string>", line 1, in <module>
 ImportError: cannot import name DeprecatedOpt
 $> pip freeze | grep oslo.config
 oslo.config==1.2.0.a34.g08203f6

i.e. the code in t5/lib/python2.7/site-packages/oslo/config/__init__.py is the 1.1.1 code, whereas pip thinks the 1.2.0 version is installed

I can't see how this isn't a pip bug

[Mark McLoughlin (markmc)]

For completeness

$> uname -a
Linux sorcha 3.5.2-3.fc17.x86_64 #1 SMP Tue Aug 21 19:06:52 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
$> virtualenv --version
1.8.3
$> . ./t5/bin/activate
(t5)$> pip --version
pip 1.2.1 from .../t5/lib/python2.7/site-packages/pip-1.2.1-py2.7.egg (python 2.7)
$> python --version
Python 2.7.3

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/34715
Committed: http://github.com/stackforge/tripleo-image-elements/commit/880e112e6f652878bdb9d53c7918785aea17692b
Submitter: Jenkins
Branch: master

commit 880e112e6f652878bdb9d53c7918785aea17692b
Author: Derek Higgins <email address hidden>
Date: Fri Jun 28 14:10:59 2013 +0100

    Install clients in their own venv

    Fixes bug 1194807

    This prevents dependencies from polluting the system
    environment.

    Change-Id: I47905f00ef0ffe7521098508def5f29839f9ae3f

[David Stanek (dstanek)]

Changing this:

     $ pip install http://tarballs.openstack.org/oslo.config/oslo.config-master.tar.gz#egg=oslo.config-1.2.0.a34.g08203f6 python-keystoneclient

to this:

    $ pip install http://tarballs.openstack.org/oslo.config/oslo.config-master.tar.gz#egg=oslo.config python-keystoneclient

will install the 1.2.0 version of the library. The fragment part of the URL tells pip what the name of the package will be when it is installed and doesn't need a version. The strange this is that my 'pip freeze' output doesn't show oslo.config 1.2.0 it shows version 1.1.1.

[Mark McLoughlin (markmc)]

Thanks, yes - dstufft also noticed that dropping the version part of the egg fragment helps

The problem with that is the way our setup.py works, we parse this URL and extract the egg fragment so that e.g. 'oslo.config>=1.2.0.a2' would end up in requires.txt

See https://github.com/openstack-dev/pbr/blob/master/pbr/packaging.py#L128

i.e. we can't easily just drop the version part of the egg fragment

[David Stanek (dstanek)]

It seems that pbr is going against the common use case. Would it be possible to change the URL format to something like:

    http://tarballs.openstack.org/oslo.config/oslo.config-master.tar.gz#egg=oslo.config&version=1.2.0

pip can handle this URL OK and pbr could be changed to accept this new format and still be backward compatible. Then other projects could be changed to use this new format.

I'm surprised that this hasn't come up before.

[Mark McLoughlin (markmc)]

Quick update on this

Firstly, I think the current behaviour of pip is definitely a bug and seems pretty fixable. Basically, it takes the egg= fragment and treats oslo.config-1.2.0a2 as the package name and installs *both* 'oslo.config-1.2.0a2' and 'oslo.config'. Simply fixing pip to strip the version from the package name in egg= fragment fixes this behaviour.

We obviously don't want to wait for pip to be fixed, thought. It looks like if we simply do:

  -f http://tarballs.openstack.org/oslo.config/oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2
 oslo.config>=1.2.0a2

then that will work just fine and will mirror the semantics we actually want. I'm actually a bit perplexed as to why we haven't always done this.

One possible complication is that the gating infrastructure around the requirements repo might reject it, but that should be fixable.

Anyway, I'll continue to push work on this today and will also file a bug against pip.

[Mark McLoughlin (markmc)]

Adding back the neutron task - if you do 'pip install -r quantum/requirements.txt' then you end up with the 1.1.1 version of the code installed

[Mark McLoughlin (markmc)]

David mentioned above that he was seeing '1.1.1' in his pip freeze

I'm pretty sure that if there are two .egg-info/ dirs in the same sys.path entry, the one pip reports is based on readdir() order ... which is completely filesystem specific. So, that would explain it?

Does that mean you should never be able to persuade pip to install two eggs in the same sys.path entry?

[OpenStack Infra (hudson-openstack)]

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

[Mark McLoughlin (markmc)]

The nova task is to track reverting this revert: https://review.openstack.org/33888

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35296
Committed: http://github.com/openstack-infra/config/commit/69f5a95ff1f7cb5e456b488f6cb2a0c2b831bb8c
Submitter: Jenkins
Branch: master

commit 69f5a95ff1f7cb5e456b488f6cb2a0c2b831bb8c
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 14:11:11 2013 +0100

    Ignore --find-links lines in requirement checks

    Fixes bug #1194807

    In quantum, we currently have a URL based requirement:

      http://.../oslo.config-1.2.0a2.tar.gz#egg=oslo.config-1.2.0a2

    The requirements check currently ignores this.

    It turns out that pip has a bug which doesn't where you can end up with
    the oslo.config 1.1.1 code installed. This is because oslo.config>=1.1.0
    gets pulled in as a transitive dep and pip gets confused. You can
    reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    I think it makes sense for the requirements check to just ignore
    --find-links lines for now like it does for URLs and -editable lines.
    Using this method means we actually do require new versions of libraries
    consumed this way to be approved into openstack/requirements first since
    we have an explicit 'oslo.config>=1.2.0a3' listed rather than that being
    derived from a URL.

    It may make sense in future to have automation around checking which
    find-links URLs are allowed ... but the same can be true for normal
    dependency URLs. This change allows us to move forward and use latest
    oslo.config in Nova, Neutron, etc. without falling foul of the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c

[Mark McLoughlin (markmc)]

I wrote up a bunch of stuff to provide some background why "just release to pypi" isn't an answer - https://wiki.openstack.org/wiki/Oslo#Why_aren.27t_alphas_releases_of_oslo.config_published_to_PyPI.3F

[zhangjinnan (zhang-jinnan)]

The same issue when run quantum/run_test.sh.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35280
Committed: http://github.com/openstack/oslo-incubator/commit/9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Submitter: Jenkins
Branch: master

commit 9f09474c5f8f591453e1dc5e3c1ddc3c7efd4985
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 13:01:26 2013 +0100

    Fix issue with pip installing oslo.config-1.2.0

    Fixes bug #1194807

    Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue
    with namespace packages (bug #1194742).

    But the main issue here is that if we ever added a dependency to our
    requirements.txt that had a dependency on an older version of
    oslo.config we would see the same issue thatt Nova and Quantum recently
    experienced where you end up with the oslo.config 1.1.1 code installed.
    This is because oslo.config>=1.1.0 gets pulled in as a transitive dep
    and pip gets confused. You can reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35279
Committed: http://github.com/openstack/neutron/commit/7d2588935086e7afce6969ff1f44239473af9953
Submitter: Jenkins
Branch: master

commit 7d2588935086e7afce6969ff1f44239473af9953
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 12:25:58 2013 +0100

    Fix issue with pip installing oslo.config-1.2.0

    Fixes bug #1194807

    Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue
    with namespace packages (bug #1194742).

    But the main issue here is that if you currently do:

      $> pip install -r quantum/requirements.txt

    then you end up with the oslo.config 1.1.1 code installed. This is
    because oslo.config>=1.1.0 gets pulled in as a transitive dep and pip
    gets confused. You can reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c

[Mark McLoughlin (markmc)]

I finally sent a pull request for the pip bug: https://github.com/pypa/pip/issues/1042

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/35281
Committed: http://github.com/openstack/nova/commit/59b799d30e58cc294e843dfc25895574b2ab40a7
Submitter: Jenkins
Branch: master

commit 59b799d30e58cc294e843dfc25895574b2ab40a7
Author: Mark McLoughlin <email address hidden>
Date: Tue Jul 2 13:05:08 2013 +0100

    Fix issue with pip installing oslo.config-1.2.0

    Fixes bug #1194807

    Firstly, we update the oslo.config dep to 1.2.0a3 because of the issue
    with namespace packages (bug #1194742).

    But the main issue here is that when we previously depended on 1.2.0a3
    we found that if you did:

      $> pip install -r nova/requirements.txt

    then you end up with the oslo.config 1.1.1 code installed. This is
    because oslo.config>=1.1.0 gets pulled in as a transitive dep and pip
    gets confused.

    See I977700d73342e81ee962019b76238d2cb2b1fff4

    You can reproduce with e.g.

      $> pip install \
           http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'
      Traceback (most recent call last):
        File "<string>", line 1, in <module>
      ImportError: cannot import name DeprecatedOpt

    This is because of a bug with pip where it sees oslo.config-1.2.0a3 and
    oslo.config as two unrelated things. It should strip the version part of
    the egg= fragment before using it as a package name, but it doesn't.

    However, we can simply use the -f/--find-links pip option in our
    requirements.txt to add the tarball URL to the list of URLs considered
    and also add the oslo.config>=1.2.0a3 dependency:

      $> pip install \
           -f http://.../oslo.config-1.2.0a3.tar.gz#egg=oslo.config-1.2.0a3 \
           'oslo.config>=1.2.0a3' \
           python-keystoneclient
      $> pip freeze | grep oslo.config
      oslo.config-1.2.0a3
      $> python -c 'from oslo.config.cfg import DeprecatedOpt'

    This is actually exactly the semantics we want and we go to great
    lengths in pbr to get these semantics while using a single tarball URL.
    The only downside to this --find-links strategy is that we gain an extra
    line in our requirements.txt ... but it does work around the pip bug.

    Change-Id: I6f3eb5fd2c75615d9a1cae172aed859b36b27d4c