Open Stack

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 CloudFormation

Yes, we'll definitely maintain, and possibly improve our current resource
implementations.

> 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 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.

> 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.

Steve