Open Stack

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/26185/
https://review.openstack.org/#/c/26367/
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.


-Angus

>Cheers,
>Patrick
>
>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 
>>>resource
>>>implementations.
>>
>>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.
>>
>>+1
>>
>>>
>>>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 
>>>use-cases
>>>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).
>>
>>>Steve
>>>
>>>_______________________________________________
>>>OpenStack-dev mailing list
>>>OpenStack-dev at lists.openstack.org
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>_______________________________________________
>>OpenStack-dev mailing list
>>OpenStack-dev at lists.openstack.org
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>-- 
>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
>http://www.bull.com
>