Open Stack

Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:
> Thomas Herve <thomas.herve at enovance.com> wrote on 07/17/2014 02:06:13 AM:
> 
> > There are 4 resources related to neutron load balancing. 
> > OS::Neutron::LoadBalancer is probably the least useful and the one 
> > you can *not* use, as it's only there for compatibility with 
> > AWS::AutoScaling::AutoScalingGroup. OS::Neutron::HealthMonitor does 
> > the health checking part, although maybe not in the way you want it.
> 
> 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.

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