Open Stack

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 
hackery.)

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 ;)

cheers,
Zane.