Open Stack

Hi all,

my previous update was a bit too hasty indeed - the problem is still there.

Steps I took:

in two empty virtualenvs I installed cilometerclient 1.0.12 and 1.0.13 and
compared "pip freeze" outputs - everything is the same except the
ceilometerclient itself.

Then I re-installed my DevStack with PIP_UPGRADE=True, all the latest
allowed libs are installed (that's what happens on the gate, right?),
ceilometerclient is 1.0.13 and all its dependencies are exactly as in those
two virtualenvs. Everything works, alarm resources are created by Heat.

Then I manually downgraded ceilometerclient to 1.0.12, restarted all Heat
and Ceilometer services - and can no more create Ceilometer alarms via Heat.

Upgrading ceilometerclient back (and restarting Ceilometer and Heat) solves
the problem.

We do better bump the requirements. The only projects I know of using
ceilometerclient are Heat, Horizon and Ceilometer itself.

Best regards,

Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com

On Thu, Apr 2, 2015 at 3:36 PM, Ihar Hrachyshka <ihrachys at redhat.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/02/2015 01:58 PM, Eoghan Glynn wrote:
> >
> >> Pavlo Shchelokovskyy wrote:
> >>> 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.
> >>
> >> I'm +1 on the change.
> >>
> >> Let's wait until tomorrow to make sure this is not completely
> >> unacceptable to packagers.
> >
>
> Packaging wise, it does not seem like a great deal, since all
> new/updated dependencies that were touched from 1.0.12 to 1.0.13 are
> already present in other Kilo components for a long time (all of them
> are covered by neutron kilo deps). The package hasn't changed a lot
> (just a new CONTRIBUTE file was introduced that can be easily
> added/skipped from downstream packages).
>
> Though, have we actually determined that the issue we try to tackle is
> still present in Kilo? I don't see an update to the latest email from
> Pavlo in the thread where he said that he cannot reproduce it.
>
> So in the end, if it fixes a valid bug, I don't see a huge problem
> packaging wise to bump the version. Though there can be other
> concerns, like exposing a new code to users that could potentially get
> new bugs with the bump. [I personally don't consider it a huge risk
> though.]
>
> /Ihar
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVHTevAAoJEC5aWaUY1u577IgIANuqzfg5Oo/JhKY/RlpcEYB0
> rOKI6DhlE5YXMiOsUR4R5w6kl8NdlJGLkj4OSilBzSFQ+LwmiqRR3T3xll6HwLSE
> IZYxMvM/YIKF34nsJ+G40u/8OQzNATnWXby4YwAR58YG96c/EDy50smJDlPVcuKd
> IC8P44qklbmqr7LhU+V7PeB25QuLNyyJNuo3Ni7FuuXPiwC3GzBChuCk+Yol3a8J
> jPJwF/sBX9lDquroaCuhIJXBv/imv73H2Ccar1J+3QMqvbqtLs6yFnepW93aaQFn
> sMe7aQC9zlHZMi72CY5G2h/PpBG2CpLJQ0wQN22xgtrMQ90lFFqTPGxnyvpJeBo=
> =mE3g
> -----END PGP SIGNATURE-----
>
> __________________________________________________________________________
> 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/15d8fcde/attachment.html>