Open Stack

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