<div dir="ltr">Sean,<div><br></div><div>unfortunately, in Heat we do not have yet integration tests for all the Heat resources (creating them in real OpenStack), and Ceilometer alarms are in those not covered. In unit tests the real client is of course mocked out. When we stumbled on this issue during normal Heat usage, we promptly raised a bug suggesting to make a new release, but propagating it to requirements took some time. The gate is not affected as it installs as per >= in requirements the latest which is 1.0.13.</div><div><br></div><div>With 1.0.12 ceilometerclient and Heat-Kilo, the Ceilometer alarm resource not "doesn't work quite as expected", it can not be created at all, failing any stack that has it in the template.</div><div><br></div><div>Best regards,</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Pavlo Shchelokovskyy<div>Software Engineer</div><div>Mirantis Inc</div><div><a href="http://www.mirantis.com" target="_blank">www.mirantis.com</a></div></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 2, 2015 at 1:12 PM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 04/02/2015 05:42 AM, Eoghan Glynn wrote:<br>
><br>
><br>
>> Hi all,<br>
>><br>
>> we have a problem with dependencies for the kilo-rc1 release of Heat - see<br>
>> bug [1]. Root cause is ceilometerclient was not updated for a long time and<br>
>> just got an update recently. We are sure that Heat in Kilo would not work<br>
>> with ceilometerclient <=1.0.12 (users would not be able to create Ceilometer<br>
>> alarms in their stacks). In the same time, global requirements have<br>
>> ceilometerclient >=1.0.12. That works on the gate, but will fail for any<br>
>> deployment that happens to use an outdated pypi mirror. I am also afraid<br>
>> that if the version of ceilometerclient would be upper-capped to 1.0.12 in<br>
>> stable/kilo, Heat in stable/kilo would be completely broken in regards to<br>
>> Ceilometer alarms usage.<br>
>><br>
>> The patch to global requirements was already proposed [2] but is blocked by<br>
>> requirements freeze. Can we somehow apply for an exception and still merge<br>
>> it? Are there any other OpenStack projects besides Heat that use<br>
>> ceilometerclient's Python API (just asking to assert the testing burden)?<br>
>><br>
>> [1] <a href="https://bugs.launchpad.net/python-ceilometerclient/+bug/1423291" target="_blank">https://bugs.launchpad.net/python-ceilometerclient/+bug/1423291</a><br>
>><br>
>> [2] <a href="https://review.openstack.org/#/c/167527/" target="_blank">https://review.openstack.org/#/c/167527/</a><br>
><br>
> Pavlo - part of the resistance here I suspect may be due to the<br>
> fact that I inadvertently broke the SEMVER rules when cutting<br>
> the ceilometerclient 1.0.13 release, i.e. it was not sufficiently<br>
> backward compatible with 1.0.12 to warrant only a Z-version bump.<br>
><br>
> Sean - would you be any happier with making a requirements freeze<br>
> exception to facilitate Heat if we were to cut a fresh ceiloclient<br>
> release that's properly versioned, i.e. 2.0.0?<br>
<br>
</div></div>A couple of concerns:<br>
<br>
#1 - would have been really nice if the commit message for the review<br>
included the above block of text. The current commit message is not<br>
clear that Heat *can not* work.<br>
<br>
#2 - why wasn't the fact that Heat *can not* work raised earlier,<br>
because I assume that means there are tests that are blocking all kinds<br>
of changes?<br>
<br>
If this is truly blocking we can raise with Thierry, he has final<br>
override here. However, if this means that one resource type doesn't<br>
work quite as expected, I don't think that warrants a freeze bump. The<br>
libraries are set to >= here so nothing in Kilo that prevents users from<br>
deciding to take that upgrade.<br>
<br>
Forcing that upgrade on all users for 1 use case which a user may or may<br>
not be using is not the point of GR.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>