[openstack-dev] [heat][ceilometer] Can you please confirm those basic assumptions?

Angus Salkeld asalkeld at redhat.com
Tue Apr 30 23:32:59 UTC 2013

On 30/04/13 11:28 +0200, Patrick Petit wrote:
>Hi Angus and Steven,
>That is all good! I do share the opinion that we need to provide 
>tools to register metrics via in-instance monitoring.
>So, I'd like to suggest that we take on us the client side as an 
>application driven use case for the metrics monitoring API 
>extensions. It sounds natural to align that CLI to the CloudWatch 
>style of publishing metrics and setting alarms because that's the way 
>it's going to be encoded in the Heat templates. If your are fine with 
>this, our contribution will focus on producing an in-instance 
>cfn-push-stats atop of a functional equivalent of the AWS 
>PutMericData interface. That would be a starting point based on the 
>principal of dependency inversion. Can you please let us know if you 
>are fine with this and where / how to start?

Hi Patrick,

I have some work to do before it's worth getting stuck in.
https://review.openstack.org/#/c/27691/ (more to follow here)

Also Ceilometer might just go for a native sample posting API and
not the AWS API. So in the short term hold off and I'll ping you
when we can progress a bit more.


>On 4/30/13 1:33 AM, Angus Salkeld wrote:
>>On 29/04/13 18:32 +0100, Steven Hardy wrote:
>>>On Mon, Apr 29, 2013 at 06:02:22PM +0200, Patrick Petit wrote:
>>>>Dear All,
>>>>Following the Design Summit in Portland and couple follow-up
>>>>discussions we had with Julien Danjou, we have tried to delineate
>>>>what we understand will shape changes between Heat and Ceilometer
>>>>(versus what will remain relatively stable) regarding the Alarming
>>>>and AutoScaling capabilities currently supported in Heat.
>>>Ok, hopefully Angus can follow up with more details on the ceilometer
>>>specifics, but my understanding of the plan is below:
>>>>That question is important to us as as we would like to anticipate
>>>>as much as possible those changes and so, avoid having to wait until
>>>>the dust settles. I outlined below some high level assumptions which
>>>>I would appreciate if someone could tell us whether they are correct
>>>>or not. Here it is:
>>>>1 -  Support of Heat resources that implement the CloudWatch and
>>>>AutoScaling service capabilities are maintained and possibly
>>>>enhanced to reach feature parity with ClourodFormation
>>>Yes, we'll definitely maintain, and possibly improve our current 
>>Yip, any change to Ceilometer should only impove functionality.
>>>>2 - CloudWatch API becomes a facade to the Ceilometer API that is
>>>>extended to support push metrics and alarms. Or will the CloudWatch
>>>>API be deprecated altogether? We may question the idea that it makes
>>>>sense to maintain two alarming APIs in OpenStack... In doing so, is
>>>>it still intended to support cfn-push-stats in the VMs given the
>>>>fact that it's linked to the Boto library?
>>>I'd like to see the CloudWatch API removed from heat completely, 
>>>as well as
>>>the dependence on cfn-push-stats in its current form.
>>>It's not clear to me that anyone (other than our own tools) is using the
>>>Heat CloudWatch-compatible API, so I'd rather remove it, and as you say
>>>we then only have to worry about one alarm/metric API (ceilometer)
>>>However I definitely do think there are valid metric-collection 
>>>which will only be possible via in-instance monitoring (e.g application
>>>statistics or service status), so I'd like to see a tool (possibly a
>>>reworked cfn-push-stats or something similar provided by 
>>>ceilometer) which
>>>can push data to the ceilometer API.
>>I'll try find a home for that, one option is to keep it where it is
>>just to change it to post to Ceilometer instead of Heat-CW.
>>>>3 - AutoScaling remains in Heat project but implementation will move
>>>>out of Heat Engine to be supported as an independent service that
>>>>will expose its own service API. But, from a template standpoint
>>>>this should be transparent
>>>I think it's too early to tell exactly how this will work out, but as a
>>>first step adding an AS API to our existing AS implementation 
>>>seems likely,
>>>and yes this should be transparent to template users.
>>>>4 - Ceilometer alarming will inter-operate with Heat AutoScaling by
>>>>way of sending notifications and/or invoking webhooks (HTTP
>>>>callbacks) defined in the alarm statement. But again, from a
>>>>template standpoint this should be transparent.
>>>Yes, this is basically my understanding - hopefully Angus can confirm.
>>Yes, that is the plan (work in progress now).
>>>OpenStack-dev mailing list
>>>OpenStack-dev at lists.openstack.org
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>Patrick Petit
>Cloud Computing Principal Architect, Innovative Products
>Bull, Architect of an Open World TM
>Tél : +33 (0)4 76 29 70 31
>Mobile : +33 (0)6 85 22 06 39

More information about the OpenStack-dev mailing list