Devstack cannot install Horizon plugins using pip version > 8

[Valeriy Ponomaryov]

Devstack always installs "test-requirements" for all projects, but lots of UI plugins for Horizon install "Horizon" from url for tests, and it should not be installed in Devstack, only for tests env.

Latest pip (8.0.2) fails to do it with following error:

Could not satisfy constraints for 'horizon': installation from path or url cannot be constrained to a version

Example in Manila project logs that installs its Manila UI plugin for Horizon in CI:

http://logs.openstack.org/36/274136/2/check/gate-manila-tempest-dsvm-neutron/3b33fd6/logs/devstacklog.txt.gz#_2016-02-01_08_30_54_723
(copied to http://paste.openstack.org/show/486969/)

Problem appeared after merge of following change to devstack:

https://review.openstack.org/#/c/271985/

List of potentially affected UI projects, that are going to fail:

evoque-dashboard
cue-dashboard
trove-dashboard
senlin-dashboard
neutron-lbaas-dashboard
sahara-dashboard
mistral-dashboard
manila-ui
horizon-cisco-ui
zaqar-ui
group-based-policy-ui
monasca-ui
magnum-ui

and project "manila-ui" fails for sure.

[Chad Roberts (croberts)]

Indeed, I can confirm that sahara-dashboard is affected by this

[Akihiro Motoki (amotoki)]

In neutron subprojects, we install neutron (as dependency) as part of tox install_command like [1] and [2].
Of course, it is great if pip handles it appropriately, but I think the way neutron team uses is a good possible workaround.

[1] http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tox.ini#n11
[2] http://git.openstack.org/cgit/openstack/neutron-lbaas/tree/tools/tox_install.sh

[Mathieu Rohon (mathieu-rohon)]

networking-bgpvpn has the same issue, as it has two git repo in its test-requirements.txt, without any version specified.

So running devstack locally fails, but I'm surprised the gate doesn't fail, even when it uses pip 8.1.0 :

http://logs.openstack.org/58/281358/19/experimental/gate-install-dsvm-networking-bgpvpn/fd734f7/logs/devstacklog.txt.gz#_2016-03-09_10_31_43_952

and

http://logs.openstack.org/58/281358/19/experimental/gate-install-dsvm-networking-bgpvpn/fd734f7/logs/devstacklog.txt.gz#_2016-03-09_10_34_14_006
http://logs.openstack.org/58/281358/19/experimental/gate-install-dsvm-networking-bgpvpn/fd734f7/logs/devstacklog.txt.gz#_2016-03-09_10_34_15_131

[Mathieu Rohon (mathieu-rohon)]

I can confirm that for bgpvpn, the devstack script works on a fresh deployment, but subsequent call to stack.sh fails with the error :

Could not satisfy constraints for 'networking-bagpipe': installation from path or url cannot be constrained to a version

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by YAMAMOTO Takashi (<email address hidden>) on branch: master
Review: https://review.openstack.org/294627
Reason: see https://review.openstack.org/#/c/295629/

[Robert Collins (lifeless)]

The bug is definitely in second+ calls to stack.sh.

A workaround is to git reset --hard on /opt/stack/requirements.

I suspect there is a bad dependency / pip call somewhere but I haven't tracked it down yet.

[purandarrao (purandarrao)]

I was still facing this problem today when stack.sh is ran after the 1st time again. Robert Collins work around suggestion worked for me, Thanks!

[Sean Murphy (murp)]

Robert's workaround also worked for me.

[Sharat Sharma (sharat-sharma)]

Robert Collins, that's a great workaround. Thanks. But we should find a solution for this problem

[fengchaoyang (fengchaoyang)]

Now pip version = 9.0.1, This bug still exists. We only have to wait for the pip developer community to fix this bug.:(

[zhangdetong (zhangdetong)]

Affected when installing mistral.

[Tony Breeds (o-tony)]

So this isn't a pip issue. It's doing *exactly* what it's designed to do.

I'm not convinced it's a devstack *bug*, it could be considered a missing feature but that's a differnt thing.

When devstack installs a $service from git it also updates the constraints to denote the "one true version". Later when a $project comes along (say a *-ui which depends on horizon, or blazar-nova which depends on nova) pip cannot install from the tarball fro $service because it doesn't match the "one true version" already recorded in the upper-constraints.txt

Listing the tarball in *requirements.txt is great from an installation POV but it causes problem like this in the gate.

There are 4 main installation methods:
1. Dirsto packages[1]
2. Some variation of git clone $project_url && cd $project" && pip install .
3. A developer wanting to run tox unit tests in $project (where $project *needs* $service)
4. An integration test (devstack) that needs to install $project and $service

The neutron-*aas projects have solved all 4 scenarios but *not* codifying the requirement for $service instead relying on documentation to make that clear *and* using something like [2] to handle scenarios 3 and 4

[1] This is actually pretty simple as they'll follow more or less whatever works for scenario 2
[2] http://git.openstack.org/cgit/openstack/neutron-vpnaas/tree/tools/tox_install.sh

[Sean Dague (sdague)]

This devstack bug was last updated over 180 days ago, as devstack
is a fast moving project and we'd like to get the tracker down to
currently actionable bugs, this is getting marked as Invalid. If the
issue still exists, please feel free to reopen it.