Open Stack

Zane,

If you happen to have a link to this blueprint, could you reply with it? I took a look, but did not find it.

I’d like to suggest that the implementation allow apps to call unauthenticated (signed) webhook URLs in order to trigger a scale up/down event within a scaling group. This is about the simplest possible API to allow any application to control it’s own elasticity.

Thanks,

Adrian

On Jul 1, 2014, at 6:09 PM, Mike Spreitzer <mspreitz at us.ibm.com<mailto:mspreitz at us.ibm.com>> wrote:

Zane Bitter <zbitter at redhat.com<mailto: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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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