Open Stack

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