Open Stack

So this is also filed as https://bugs.launchpad.net/devstack/+bug/1468808

But I figure a lot of folk are going to be running into it.

Its the interaction between the changes discussed in
http://lists.openstack.org/pipermail/openstack-dev/2015-June/067823.html
and dirty devstack VM's that already have older releases (e.g. of
keystonemiddleware) present.

Whats happening is that when you do 'pip install keystonemiddleware'
and you already have a keystonemiddleware installed, pip *doesn't* do
a no-op. It verifies that the dependencies of keystonemiddleware are
satisfied, and if they aren't, fixes it. This downgrades pbr to 0.11[
the highest version satisfying the old release of keystonemiddleware].

And this can repeat for many different packages.

How to fix?

*) Use a fresh VM.

*) Look in your log for things expressing the pbr lower cap:
pbr!=0.7,<1.0,>=0.6:
pbr!=0.7,<1.0,>=0.6 (from keystonekeystonemiddlewaremiddleware>=1.5.0)
This tells you the package triggering the downgrade. Upgrade that package:
sudo -H pip install -U pbr
sudo -H pip install -U keystonemiddleware
(The install of pbr here is so that you can see if it gets downgraded
- if it does, the latest release of $package is still problematic).

*) Try the big hammer:
export PIP_UPGRADE=1
./stack.sh # this will fail
unset PIP_UPGRADE
./stash.sh # this might work ;)

The reason it fails with PIP_UPGRADE set is that this is triggering
the converse behaviour and force upgrading stuff which makes it
incompatible with other versions on the system.

I'd say 'or use the published upper-constraints.txt' file, but we
haven't got the constraints logic passing tests or included in a pip
release yet, so its a little premature. But very very close.

-Rob
-- 
Robert Collins <rbtcollins at hp.com>
Distinguished Technologist
HP Converged Cloud