Open Stack

Clint Byrum <clint at fewbar.com> wrote on 07/18/2014 12:56:32 PM:

> Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:
> > ...
> > OK, let's work with these.  My current view is this: supposing the 
> > Convergence work delivers monitoring of health according to a member's 

> > status in its service and reacts accordingly, the gaps (compared to 
AWS 
> > functionality) are the abilities to (1) get member health from 
> > "application level pings" (e.g., URL polling) and (2) accept member 
health 
> > declarations from an external system, with consistent reaction to 
health 
> > information from all sources.
> > 
> 
> Convergence will not deliver monitoring, though I understand how one
> might have that misunderstanding. Convergence will check with the API
> that controls a physical resource to determine what Heat should consider
> its status to be for the purpose of ongoing orchestration.

If I understand correctly, your point is that healing is not automatic. 
Since a scaling group is a nested stack, the observing part of Convergence 
will automatically note in the DB when the physical resource behind a 
scaling group member (in its role as a stack resource) is deleted.  And 
when convergence engine gets around to acting on that Resource, the 
backing physical resource will be automatically re-created.  But there is 
nothing that automatically links the notice of divergence to the 
converging action.  Have I got that right?

> > Source (1) is what an OS::Neutron::HealthMonitor specifies, and an 
> > OS::Neutron::Pool is the thing that takes such a spec.  So we could 
> > complete the (1) part if there were a way to tell a scaling group to 
poll 
> > the member health information developed by an OS::Neutron::Pool.  Does 

> > that look like the right approach?
> > 
> > For (2), this would amount to having an API that an external system 
(with 
> > proper authorization) can use to declare member health.  In the grand 
and 
> > glorious future when scaling groups have true APIs rather than being 
Heat 
> > hacks, such a thing would be part of those APIs.  In the immediate 
future 
> > we could simply add this to the Heat API.  Such an operation would 
take 
> > somethings like a stack name or UUID, the name or UUID of a resource 
that 
> > is a scaling group, and the member name or UUID of the Resource whose 
> > health is being declared, and "health_status=unhealthy".  Does that 
look 
> > about right?
> > 
> 
> Isn't (2) covered already by the cloudwatch API in Heat? I am going to
> claim ignorance of it a bit, as I've never used it, but it seems like
> the same thing.

I presume that by "cloudwatch API" you mean Ceilometer.  Today a 
Ceilometer alarm can be given a URL to invoke but can not be told about 
any special headers or body to use in the invocation (i.e., no parameters 
for the HTTP operation).

More to the point, the idea here is supporting a general external system 
that might determine health in its own way, not necessarily through 
programming Ceilometer to detect it.

Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140718/04ec5aa2/attachment.html>