Open Stack

Sean,

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.

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.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 1:12 PM, Sean Dague <sean at dague.net> wrote:

> 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
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150402/7232c98c/attachment.html>