[openstack-dev] [stable][ceilometer][all] stable/kilo 2015.1.3 delayed

gordon chung gord at live.ca
Fri Jan 29 19:34:01 UTC 2016



On 29/01/2016 1:27 PM, Jeremy Stanley wrote:
> On 2016-01-29 14:14:48 +0000 (+0000), gordon chung wrote:
>> trying to understand the situation here. isn't this all managed by
>> global-reqs? an incompatible pip and pbr were release so now we
>> can't build? were we the only project using downloadcache (i don't
>> recall us doing anything unique in our tox file)?
> The tox.ini for Ceilometer stable/kilo was adding a downloadcache
> inherited by all its environments which caused tox to add
> --download-cache to all pip install invocations. While deprecated in
> pip 6 (and removed from the tox.ini during the Liberty cycle), this
> worked up until pip 8 dropped that option from its command-line
> parser. Due to unfortunate timing, the last commit on stable/liberty
> was tested with pip 7 and merged, but the 2015.1.2 tag for that
> commit was pushed after pip 8 was released and so tox was no longer
> able to work with the tagged commit.
>
> A number of workarounds were tried, but ultimately the explicit
> addition of -U (upgrade) to pip calls in tox.ini prevented my
> attempts to temporarily pin to earlier versions of pip within the
> calling script.
>
>> i would prefer a release to be made as there was a performance
>> backport made. what is the effort required to push tarball
>> generated outside of jenkins? any drawbacks?
> [...]
>
> The steps followed by tox could be emulated manually, with the
> addition of forcing a pip 7 install, and the result would then be
> copied via scp to tarballs.openstack.org by one of our Infra root
> admins. The drawbacks mostly come down to needing to apply some
> additional scrutiny to the generated tarball before pronouncing it
> viable, and the need to place trust in a manual process slightly
> inconsistent with our usual sdist generation mechanisms.

hmm.. that's unfortunate... anything we need to update so this doesn't 
happen again? or just a matter of lesson learned, let's keep an eye out 
next time?

i guess the question is can users wait (a month?) for next release? i'm 
willing to poll operator list (or any list) to query for demand if 
that's easier on your end? if there's very little interest we can defer 
-- i do have a few patches lined up for next kilo release window so i 
would expect another release.

cheers,

-- 
gord




More information about the OpenStack-dev mailing list