Repo stored version of wheel does not match version installed on repo containers

[Logan V]

I build some extra packages during my repo-build. I was having a lot of trouble installing one of the wheels on a new cluster and looking into it..

Doing a pip -v install gevent I noticed...
    Skipping link http://int-lb.osdev.corp.lsn:8181/os-releases/12.0.7/gevent-1.0.2-cp27-cp27mu-linux_x86_64.whl (from http://int-lb.osdev.corp.lsn:8181/os-releases/12.0.7/); it is not compatible with this Python

I see the ABI for this wheel on the newer repo is "cp27mu" instead of the usual "none".. ie:
old:
gevent-1.0.2-cp27-none-linux_x86_64.whl
new:
gevent-1.0.2-cp27-cp27mu-linux_x86_64.whl

After cloning gevent's github sources and building the wheel manually on both the new/old clusters repo containers, I see the same behavior.

Turns out the version of wheel being installed throughout the environment on this new cluster is is 0.26.0, while the version installed on the fresh repo containers is 0.29.0. On my older cluster (not that old.. just last week), wheel was 0.26.0 everywhere (including repo containers).

After downgrading wheel on the repo container to 0.26.0 it now builds the wheel with the -none abi as expected.

It looks like upper-constraints for liberty are https://github.com/openstack/requirements/blob/stable/liberty/upper-constraints.txt#L334 0.26.0 so the repo build should honor this not only for populating the repo but also for building the repo?

[Chris Boertien (chris-boertien)]

I had this error as well with openstackclient and glanceclient, due to cffi not installing.

$ pip install -v 'cffi>=1.4.1'
Skipping link http://172.29.236.100:8181/os-releases/11.2.10/cffi-1.5.2-cp27-cp27mu-linux_x86_64.whl (from http://172.29.236.100:8181/os-releases/11.2.10/); it is not compatible with this Python

I installed wheel==0.26.0 on the repo servers (both of them), did a repo-build, then continued with the utility-server and it installed the packages correctly.

[Logan V (loganv)]

Just a note to anyone hitting this.. for a workaround to this issue:

-Login to repo containers and run:
pip install wheel==0.26.0 (this will downgrade the repo container from wheel==0.29.0)

-Run repo-build play again to fix your repo

-Run the play that originally failed again and it should work now.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: kilo
Review: https://review.openstack.org/283039

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: liberty
Review: https://review.openstack.org/283657

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/283039
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=81f45653fa6bba4bc63fc44785b422b44f321a17
Submitter: Jenkins
Branch: kilo

commit 81f45653fa6bba4bc63fc44785b422b44f321a17
Author: Matt Thompson <email address hidden>
Date: Mon Feb 22 11:22:52 2016 +0000

    Pin wheel version in repo_server role

    Currently, wheel 0.29.0 is being pulled in and this is building some
    wheels that cannot be installed. For example,
    cffi-1.5.2-cp27-cp27mu-linux_x86_64.whl is being built but pip will
    not install this. Previously, when using 0.26.0, we were building
    cffi-1.5.2-cp27-none-linux_x86_64.whl.

    After chatting in #pypa, it was recommended to either downgrade wheel,
    or upgrade pip >= 8.

    Change-Id: Ic7a9d9992a88fcd93bd7c19fb7f5c907a7299b07
    Closes-Bug: #1545505

[OpenStack Infra (hudson-openstack)]

Change abandoned by Matt Thompson (<email address hidden>) on branch: liberty
Review: https://review.openstack.org/283657

[Jesse Pretorius (jesse-pretorius)]

Related patch: https://review.openstack.org/284977

[Jesse Pretorius (jesse-pretorius)]

Related set of patches:
 - https://review.openstack.org/#/q/I773c64e2ffb397862bd42ab80a4b4657cdc4809a,n,z
 - https://review.openstack.org/288405 (liberty)
 - https://review.openstack.org/288005 (kilo)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/288005
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=9abc2c85cf62a21d80dfa2d8f6a70022c0a346fc
Submitter: Jenkins
Branch: kilo

commit 9abc2c85cf62a21d80dfa2d8f6a70022c0a346fc
Author: Jesse Pretorius <email address hidden>
Date: Wed Mar 2 12:11:38 2016 +0000

    Use current, but pinned versions of pip, setuptools and wheel

    This patch provides a convenience script to check for the current
    version of any package on PyPI, then output it in various ways.

    This script is used in the SHA updating script in order to provide
    a current set of critical packages to ensure that each SHA bump
    includes an update to a current version of pip, setuptools and
    wheel but also to ensure that they are pinned to a specific version
    with this particular set of packages.

    This ensures that we keep current with these packages as they
    change, but also ensures that the versions tested for each tag are
    the versions used forever.

    The patch also ensures that any package installed by pip is upgraded
    to the expected versions.

    This is a combined backport of:
     - https://review.openstack.org/284701
     - https://review.openstack.org/284977
     - https://review.openstack.org/287700
     - https://review.openstack.org/287739

    Backport notes:
     - https://review.openstack.org/283039 is reverted as the pinning
       is now handled properly elsewhere.
     - The pip pinning done via global-requirements in
       https://review.openstack.org/270312 is removed.
     - The versions pinned are the versions used at the time of the
       last rpc-repo build. This is to ensure that this tag implements
       the same version of all the packages used as the time the tag
       repo was built.
     - The SHA for the requirements repository is updated in order to
       include the caps for osprofiler and testtools.

    Closes-Bug: 1545505
    Change-Id: I61795b3afb4804060d494a08975c10adcf52f468
    (cherry picked from commit 6ea8e986f1bc826ffd54477eddc1ea6f04b8ea53)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/288405
Committed: https://git.openstack.org/cgit/openstack/openstack-ansible/commit/?id=1a970ee0979576d9e17a683222d1b0343b5c3aa1
Submitter: Jenkins
Branch: liberty

commit 1a970ee0979576d9e17a683222d1b0343b5c3aa1
Author: Jesse Pretorius <email address hidden>
Date: Fri Mar 4 11:31:37 2016 +0000

    Ensure that the repo-server uses upper-constraints

    In order to ensure that builds are repeatable (ie the result is
    always the same when building from a tag), the repo server's
    packages must make use of OpenStack's upper-constraints file
    for its own packages.

    This patch ensures that this happens, and implements the
    additional changes required for it to succeed.

    This is a combined backport of:
     - https://review.openstack.org/284894
     - https://review.openstack.org/286923
     - https://review.openstack.org/286625 (partial)

    Closes-Bug: 1545505
    Change-Id: I157fd3f4e116afa886a27fc1f1422a3a04321c0a

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/openstack-ansible 11.2.11 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/openstack-ansible 12.0.8 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/openstack-ansible 11.2.12 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/openstack-ansible 12.0.9 release.

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/openstack-ansible 12.0.11 release.

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/openstack-ansible 11.2.14 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/openstack-ansible 11.2.15 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/openstack-ansible 12.0.8 release.