Open Stack

On 04/02/2015 05:42 AM, Eoghan Glynn wrote:
> 
> 
>> Hi all,
>>
>> we have a problem with dependencies for the kilo-rc1 release of Heat - see
>> bug [1]. Root cause is ceilometerclient was not updated for a long time and
>> just got an update recently. We are sure that Heat in Kilo would not work
>> with ceilometerclient <=1.0.12 (users would not be able to create Ceilometer
>> alarms in their stacks). In the same time, global requirements have
>> ceilometerclient >=1.0.12. That works on the gate, but will fail for any
>> deployment that happens to use an outdated pypi mirror. I am also afraid
>> that if the version of ceilometerclient would be upper-capped to 1.0.12 in
>> stable/kilo, Heat in stable/kilo would be completely broken in regards to
>> Ceilometer alarms usage.
>>
>> The patch to global requirements was already proposed [2] but is blocked by
>> requirements freeze. Can we somehow apply for an exception and still merge
>> it? Are there any other OpenStack projects besides Heat that use
>> ceilometerclient's Python API (just asking to assert the testing burden)?
>>
>> [1] https://bugs.launchpad.net/python-ceilometerclient/+bug/1423291
>>
>> [2] https://review.openstack.org/#/c/167527/
> 
> Pavlo - part of the resistance here I suspect may be due to the
> fact that I inadvertently broke the SEMVER rules when cutting
> the ceilometerclient 1.0.13 release, i.e. it was not sufficiently
> backward compatible with 1.0.12 to warrant only a Z-version bump.
> 
> Sean - would you be any happier with making a requirements freeze
> exception to facilitate Heat if we were to cut a fresh ceiloclient
> release that's properly versioned, i.e. 2.0.0?

A couple of concerns:

#1 - would have been really nice if the commit message for the review
included the above block of text. The current commit message is not
clear that Heat *can not* work.

#2 - why wasn't the fact that Heat *can not* work raised earlier,
because I assume that means there are tests that are blocking all kinds
of changes?

If this is truly blocking we can raise with Thierry, he has final
override here. However, if this means that one resource type doesn't
work quite as expected, I don't think that warrants a freeze bump. The
libraries are set to >= here so nothing in Kilo that prevents users from
deciding to take that upgrade.

Forcing that upgrade on all users for 1 use case which a user may or may
not be using is not the point of GR.

	-Sean

-- 
Sean Dague
http://dague.net