<tt><font size=2>Clint Byrum <clint@fewbar.com> wrote on 07/18/2014
12:56:32 PM:<br>
<br>
> Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700:<br>
> > ...<br>
> > OK, let's work with these.  My current view is this: supposing
the <br>
> > Convergence work delivers monitoring of health according to a
member's <br>
> > status in its service and reacts accordingly, the gaps (compared
to AWS <br>
> > functionality) are the abilities to (1) get member health from
<br>
> > "application level pings" (e.g., URL polling) and (2)
accept member health <br>
> > declarations from an external system, with consistent reaction
to health <br>
> > information from all sources.<br>
> > <br>
> <br>
> Convergence will not deliver monitoring, though I understand how one<br>
> might have that misunderstanding. Convergence will check with the
API<br>
> that controls a physical resource to determine what Heat should consider<br>
> its status to be for the purpose of ongoing orchestration.</font></tt>
<br>
<br><tt><font size=2>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?</font></tt>
<br><tt><font size=2><br>
> > Source (1) is what an OS::Neutron::HealthMonitor specifies, and
an <br>
> > OS::Neutron::Pool is the thing that takes such a spec.  So
we could <br>
> > complete the (1) part if there were a way to tell a scaling group
to poll <br>
> > the member health information developed by an OS::Neutron::Pool.
 Does <br>
> > that look like the right approach?<br>
> > <br>
> > For (2), this would amount to having an API that an external
system (with <br>
> > proper authorization) can use to declare member health.  In
the grand and <br>
> > glorious future when scaling groups have true APIs rather than
being Heat <br>
> > hacks, such a thing would be part of those APIs.  In the
immediate future <br>
> > we could simply add this to the Heat API.  Such an operation
would take <br>
> > somethings like a stack name or UUID, the name or UUID of a resource
that <br>
> > is a scaling group, and the member name or UUID of the Resource
whose <br>
> > health is being declared, and "health_status=unhealthy".
 Does that look <br>
> > about right?<br>
> > <br>
> <br>
> Isn't (2) covered already by the cloudwatch API in Heat? I am going
to<br>
> claim ignorance of it a bit, as I've never used it, but it seems like<br>
> the same thing.<br>
</font></tt>
<br><tt><font size=2>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).</font></tt>
<br>
<br><tt><font size=2>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.</font></tt>
<br>
<br><tt><font size=2>Thanks,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>
<br>