Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
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 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
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 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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
> 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? Cheers, Eoghan > > Best regards, > Pavlo Shchelokovskyy > Software Engineer > Mirantis Inc > www.mirantis.com > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] [Ceilometer] [rc1] bug is unresolved due to requirements freeze
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/ Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
