[openstack-dev] [all] Problems with keystoneclient stable branch (and maybe yours too)
blk at acm.org
Tue Apr 14 13:59:56 UTC 2015
On Mon, Apr 13, 2015 at 9:33 PM, gordon chung <gord at live.ca> wrote:
> >> 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
> >> is very good at catching this problem for whatever reason). The cap
> >> have been <1.2.0 so that we can propose patches and also make fix
> >> (1.1.1, 1.1.2, etc.).
> >>  https://review.openstack.org/#/c/172718/
> > Approved.
> we have the same issue for ceilometerclient for both icehouse and
> juno, i put up requirement patches for each 
>  https://review.openstack.org/#/c/173085/
>  https://review.openstack.org/#/c/173086/
>  https://review.openstack.org/#/c/173149/
>  https://review.openstack.org/#/c/173148/
Those caps were originally <=1.0.12 and the new cap is <1.0.13, but these
caps are equivalent since the next fix release after 1.0.12 is 1.0.13
(unless you can use a version with 220.127.116.11?). So I'm not sure how this is
going to work.
> >> I tried to recap all of the clients but that didn't pass Jenkins,
> >> because one or more clients didn't use semver correctly and have
> >> requirements updates in a micro release.
> >>  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.
I updated all the python-*clients to allow for fixes, e.g., from
<=[major].[minor].[fix] to <[major].[minor+1].0. When this didn't work I
thought about checking all the client repos to see which ones have problems
but that was more work than I was willing to do.
don't know about others but full disclosure, we didn't use SEMVER
> correctly. :\
Maybe projects that didn't use semver correctly can't have stable branches
for now. I'm not sure what all the drawbacks are... maybe just that you
don't get to backport security fixes.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev