[openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
Pavlo Shchelokovskyy
pshchelokovskyy at mirantis.com
Thu Apr 2 11:26:01 UTC 2015
Hi all,
a (may be hasty) update.
I just tried using a quite fresh devstack master that somehow still
(PIP_UPGRADE=False?) has ceilometerclient as 1.0.12,
and ceilometer alarms do work as expected, template is [1]. May be the
actual bug/backward incompatibility was somewhere in oslo-incubator and
latest syncs fixed it.
I urge Heat team to double-check if 1.0.12 does indeed work now, so we can
"call of the dogs" and close this issue.
[1]
https://github.com/pshchelo/stackdev/blob/master/templates/autoscaling/asg.yaml
Best regards,
Pavlo Shchelokovskyy
Software Engineer
Mirantis Inc
www.mirantis.com
On Thu, Apr 2, 2015 at 1:46 PM, Sergey Kraynev <skraynev at mirantis.com>
wrote:
> Hi Guys.
>
>
>> 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.
>>
>
> I will update commit message regarding info mentioned in this thread.
>
>
>>
>> #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?
>>
>
> The reason, why we don't tell it early is:
> when issue was found we ask ceilometer team to bump new version,
> after that I uploaded patch to global-requirements and believed that it
> will be merged before release.
> It does not block gates (due to reason mentioned above), but the reality
> is so, that with 1.0.12 version
> user can not use any ceilometer resources in Heat (as result we loose
> autoscaling templates, where ceilometer plays one of major roles).
>
>
>>
>> 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
>>
>
>
> Regards,
> Sergey.
>
> __________________________________________________________________________
> 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/7f1f9441/attachment.html>
More information about the OpenStack-dev
mailing list