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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
