Excerpts from Mike Spreitzer's message of 2014-07-18 10:38:32 -0700: > 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? >
Yes you have it right. I just wanted to be clear, that is not "monitoring". _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
