[openstack-dev] [all] Problems with keystoneclient stable branch (and maybe yours too)

Doug Hellmann doug at doughellmann.com
Mon Apr 13 21:58:49 UTC 2015

Excerpts from Brant Knudson's message of 2015-04-12 20:14:00 -0500:
> There were several problems with the keystoneclient stable/juno branch that
> have been or are in the process of being fixed since its creation.
> Hopefully this note will be useful to other projects that create stable
> branches for their libraries.

Thanks for documenting these, Brant.

> 1) Unit tests didn't pass with earlier packages
> The supported versions of several of the packages in requirements.txt in
> the stable branch are in the process of being capped[0], so that the tests
> are now running with older versions of the packages. Since we don't
> normally test with the older packages we didn't know that the
> keystoneclient unit tests don't actually pass with the old version of the
> package. This is fixed by correcting the tests to work with the older
> versions of the packages.[1][2]
> [0] https://review.openstack.org/#/c/172220/
> [1] https://review.openstack.org/#/c/172655/
> [2] https://review.openstack.org/#/c/172256/
> It would be great if we were testing with the minimum versions of the
> packages that we say we support somehow since that would have caught this.

OK, this was unexpected but does make sense. We have requests for
minimum version testing periodically for lots of other reasons, so we
should add this one to the list in case it is finally long enough to
attract someone to work on the problem.

> 2) Incorrect cap in requirements.txt
> python-keystoneclient in stable/juno was capped at <=1.1.0, and 1.1.0 is
> the version tagged for the stable branch. When you create a review in
> stable/juno it installs python-keystoneclient and now the system has got a
> version like 1.1.0.post1, which is >1.1.0, so now python-keystoneclient
> doesn't match the requirements and swift-proxy fails to start (swift-proxy
> is very good at catching this problem for whatever reason). The cap should
> have been <1.2.0 so that we can propose patches and also make fix releases
> (1.1.1, 1.1.2, etc.).[3]
> [3] https://review.openstack.org/#/c/172718/


> I tried to recap all of the clients but that didn't pass Jenkins, probably
> because one or more clients didn't use semver correctly and have
> requirements updates in a micro release.[4]
> [4] https://review.openstack.org/#/c/172719/

Did you literally update them all, or only the ones that looked like
they might be wrong? It looks like those caps came from the cap.py
script in the repository, which makes me wonder if we were just too
aggressive with defining what the cap should be.


More information about the OpenStack-dev mailing list