[openstack-dev] [heat] autoscaling and load balancers
zbitter at redhat.com
Thu Apr 9 14:31:14 UTC 2015
On 08/04/15 21:51, Miguel Grinberg wrote:
> Hi Angus,
> Regarding this:
> > As Zane suggested, you should think of autoscaling as been in a
> different service.
> It's not that I can't see your point of view. I can imagine an
> autoscaling service. I agree with you guys that if we had that, then
> none of this would be Heat's concern.
> When I think of this separate autoscaling service that can be used
> without Heat, I imagine that it provides a mechanism to update
> interested entities, such as (but not exclusively) load balancers when
> there is a scaling event, or actually any event of interest.
Yeah, and the hooks mechanism that I described in my previous email is
the one that we have talked about using for this.
> So if we had autoscaling as a service running outside of Heat, we would
> not be talking about this problem.
Or maybe we would ;) Nothing about making autoscaling a separate service
gives us this for free. It needs to be implemented whether or not
autoscaling becomes a separate service.
> Heat would not refresh the ASG attributes
> and it would not know when the ASG resizes, but it wouldn't need to,
> because this imaginary service would have some way to talk to the load
> balancer or anybody else that wants to do stuff based on its state. I
> would probably not even create my load balancer as a heat resource in
> that situation, I would not need to.
> For such a service we would have a lightweight wrapper Heat resource
> that would take some inputs and invoke the service public APIs. This
> resource would not take a heat sub-resource or nested stack as the
> scaled entity, since that service runs outside of Heat and manages its
> own pool of scaled entities.
No, it would. That's one of our explicit design goals.
> The wrapper resource would probably not
> expose the pool size, or any properties of the scaled entities, because
> none of this would be in heat's domain.
I imagine we probably still would. The plan is to eventually have a
seamless transition from the existing ASG resource to a separate
service. (This is why we don't want to reintroduce the old hacks: the
native ASG's only purpose in life is to establish a clean break from the
But yeah, you would still not be able to use it in the way that you're
currently trying to, at _least_ until phase 2 of Convergence is available.
> Even if you had that
> information, it would not be of much use within a stack. The ASG becomes
> sort of a black box, like other openstack native resources. This would
> be nice because it moves the notification problem to a dedicated service
> where it can be best addressed.
> So I do get what you are saying. But looking at things that way does not
> help solve my problem.
Yes, I acknowledge that your problem is not solved, and that sucks
because it really is an important problem. However, there is no quick fix.
> LBAAS isn't widely deployed, and the
Right, life would be a lot easier if it were because the autoscaling
group could just call the Neutron API directly. Providing a completely
generic, user-configurable notification mechanism is a lot more
difficult, which is one reason why it hasn't been done yet.
> OS::Heat::ASG lacks a good notification mechanism, so I'm still left
> with the same choices, which are to either build my own notifications
> (using a custom resource or maybe polling the API from the lb instance),
> or else not use Heat's ASG and instead build my own autoscaler.
> I know you guys don't like the AWS autoscaling mechanism, I agree that
> it isn't a well thought out design, but I can't ignore its one good
> quality: it works.
It wouldn't say it wasn't well thought out, it was simply the best we
could do in the absence of a LBaaS API, which the Amazon autoscaling
design is predicated upon. Everyone was aware that it was a hack, even
at the time. The problem is that the hacks and hacks on top of hacks are
actually an obstacle to implementing real, long-term solutions.
> Anyway, I ended up writing yet another long email. :)
> I'll let you guys know if I come up with any other ideas that don't
> disagree with the original design you envisioned for the ASG. Thanks for
> spending the time discussing this, it was a really useful discussion.
Agreed, discussion is always good. We have ideas for long-term fixes for
all of the problems you've raised, but we could really use help on
implementing them. Tell your friends ;)
More information about the OpenStack-dev