Open Stack

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

> Zane Bitter <zbitter at 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 
functionality
> > > --- both an ability to detect basic forms of failures and an ability 
to
> > > react properly to failures detected by itself or by a load balancer.
> > >   What is the thinking about how to get this functionality in 
OpenStack?
> > >   Since OpenStack's OS::Heat::AutoScalingGroup has a more general 
member
> > > type, what is the thinking about what failure detection means (and 
how
> > > 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 
Heat 
> > 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.

Thanks,
Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140702/56c6db89/attachment.html>