Excerpts from Mike Spreitzer's message of 2014-07-18 09:12:21 -0700: > Thomas Herve <thomas.he...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev