Clint Byrum <cl...@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
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
