Open Stack

Zane Bitter <zbitter at redhat.com> wrote on 07/01/2014 07:05:15 PM:

> On 01/07/14 16:30, Mike Spreitzer wrote:
> > Thinking about my favorite use case for lifecycle plug points for 
cloud
> > providers (i.e., giving something a chance to make a holistic 
placement
> > decision), it occurs to me that one more is needed: a scale-down plug
> > point.  A plugin for this point has a distinctive job: to decide which
> > group member(s) to remove from a scaling group (i.e.,
> > OS::Heat::AutoScalingGroup or OS::Heat::InstanceGroup or
> > OS::Heat::ResourceGroup or AWS::AutoScaling::AutoScalingGroup).  The
> > plugin's signature could be something like this: given a list of group
> > members and a number to remove, return the list of members to remove
> > (or, equivalently, return the list of members to keep).  What do you 
think?
> 
> I think you're not thinking big enough ;)

I agree, I was taking only a small bite in hopes of a quick success.

> There exist a whole class of applications that would benefit from 
> autoscaling but which are not quite stateless. (For example, a PaaS.) So 

> it's not enough to have plugins that place the choice of which node to 
> scale down under operator control; in fact it needs to be under 
> _application_ control.

Exactly.  There are two different roles that want such control; in 
general, neither is happy if only the other gets it.  Now the question 
becomes, how do we get them to play nice together?  In the case of TripleO 
there may be an exceptionally easy out: the owner of an application 
deployed on the undercloud may well be the same as the provider of the 
undercloud (i.e., the operator whose end goal is to provide the 
overcloud(s) ).

> This is on the roadmap, and TripleO really needs it, so hopefully it 
> will happen in Juno.

I assume you mean giving this control to the application, which I presume 
amounts to giving it to the template author.  Is this written up 
somewhere?

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140701/4bdc9305/attachment.html>