Comment 1 for bug 1803143

So here's what I think is happening:

1. ceph gets installed from queens UCA and pulls in python-paste + python-pastedeploy pkgs.

http://logs.openstack.org/55/569055/7/check/devstack-plugin-ceph-tempest/45135b5/controller/logs/devstacklog.txt.gz#_2018-11-13_13_54_16_273

Versions are
python-paste 2.0.3+dfsg-4ubuntu1~cloud0
python-pastedeploy 1.5.2-1

2. Later keystone and its requirements are installed via pip, and it finds

http://logs.openstack.org/55/569055/7/check/devstack-plugin-ceph-tempest/45135b5/controller/logs/devstacklog.txt.gz#_2018-11-13_13_56_04_644

Requirement already satisfied: PasteDeploy===1.5.2 in /usr/lib/python2.7/dist-packages (from -c /opt/stack/requirements/upper-constraints.txt (line 20))
Collecting Paste===3.0.4 (from -c /opt/stack/requirements/upper-constraints.txt (line 19))

and then pip removes the distro-installed paste, replacing it with the newer version. But since it installs the new version into /usr/local/lib, it effectively shadows the system-install paste.deploy path.

This is exactly one of the issues that pip >= 10 wants to protect us from, but we are still pinning pip < 10 and thus exposed to this failure.

As a short-term workaround, doing a "pip uninstall PasteDeploy" and then "pip install PasteDeploy" solve the issue. But we really should continue to work on unpinning pip again, see https://review.openstack.org/561597