Mike Spreitzer/Watson/IBM@IBMUS wrote on 07/02/2014 02:41:48 AM:

> Zane Bitter <zbit...@redhat.com> wrote on 07/01/2014 06:58:47 PM:
> > On 01/07/14 15:47, Mike Spreitzer wrote:
> > > In AWS, an autoscaling group includes health maintenance 
> > > --- both an ability to detect basic forms of failures and an ability 
> > > react properly to failures detected by itself or by a load balancer.
> > >   What is the thinking about how to get this functionality in 
> > >   Since OpenStack's OS::Heat::AutoScalingGroup has a more general 
> > > type, what is the thinking about what failure detection means (and 
> > > it would be accomplished, communicated)?
> > >
> > > I have not found design discussion of this; have I missed something?
> > 
> > Yes :)
> > 
> > https://review.openstack.org/#/c/95907/
> > 
> > The idea is that Convergence will provide health maintenance for _all_ 

> > forms of resources in Heat. Once this is implemented, autoscaling gets 

> > it for free by virtue of that fact that it manages resources using 
> > stacks.
> Ah, right.  My reading of that design is not quite so simple...

There are a couple more issues that arise in this approach.  The biggest 
one is how to integrate application-level failure detection.  I added a 
comment to this effect on the Convergence spec.

Another issue is that, at least initially, Convergence is not "always on"; 
rather, it is an operation that can be invoked on a stack.  When would a 
scaling group invoke this action on itself (more precisely, itself 
considered as a nested stack)?  One obvious possibility is on a periodic 
basis.  It the convergence operation is pretty cheap when no divergence 
has been detected, then that might be acceptable.  Otherwise we might want 
the scaling group to set up some sort of notification, but that would be 
another batch of member-type specific code.


OpenStack-dev mailing list

Reply via email to