Open Stack

Excerpts from Mike Spreitzer's message of 2014-07-18 10:38:32 -0700:
> Clint Byrum <clint at 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".