Open Stack

Thomas,

I stand corrected. If you use Neutron's LBAAS plugin you do get the correct
autoscaling behavior because Neutron updates the loadbalancer when pool
members are added or removed (Heat does not seem to participate in this
update, as far as I can see). Still my #1 issue still exists, references to
the ASG will not be re-evaluated, even with the LBAAS resources.

I'll look into doing an update when a resize event is triggered, since we
seem to agree that it is a potential solution.

Thanks,

Miguel



On Wed, Apr 8, 2015 at 7:30 AM, Thomas Herve <thomas.herve at enovance.com>
wrote:

> Hi,
>
> Response inline.
>
>
> > Hi,
> >
> > The OS::Heat::AutoScalingGroup resource is somewhat limited at this time,
> > because when a scaling even occurs it does not notify dependent
> resources,
> > such as a load balancer, that the pool of instances has changed.
>
> That's technically not true. If you use a neutron load balancer, and a
> PoolMember resource in each scaling unit, it will do exactly that.
>
> > The AWS::AutoScaling::AutoScalingGroup resource, on the other side, has a
> > LoadBalancerNames property that takes a list of
> > AWS::ElasticLoadBalancing::LoadBalancer resources that get updated
> anytime
> > the size of the ASG changes.
> >
> > I'm trying to implement this notification mechanism for HOT templates,
> but
> > there are a few aspects that I hope to do better.
> >
> > 1. A HOT template can have get_attr function calls that invoke
> attributes of
> > the ASG. None of these update when the ASG resizes at this time, a
> scaling
> > even does a partial update that only affects the ASG resource. I would
> like
> > to address this.
> >
> > 2. The AWS solution relies on the well known LoadBalancer resource, but
> often
> > load balancers are just regular instances that get loaded with a load
> > balancer such as haproxy in a custom way. I'd like custom load balancers
> to
> > also update when the ASG resizes.
> >
> > The ResourceGroup is an interesting resource. It is much simpler than the
> > ASG. In particular, the only way to scale the ResourceGroup is by
> issuing a
> > stack-update with a new size. This indirectly solves #1 and #2 above,
> > because when a full update is issued any references to the ResourceGroup
> get
> > updated as well.
> >
> > In my opinion, the best way to address #1 and #2 above so that they work
> for
> > the ASG as they work for the RG, is to change what happens when there is
> a
> > scaling event. When the ScalingPolicy resource gets a signal, it reaches
> > directly to the ASG by calling asg.adjust() (or in the near future by
> > sending a signal to it, when a currently proposed patch merges) with the
> new
> > size. This bypasses the update mechanism, so only a partial update
> occurs,
> > just the ASG resource itself is updated. I would like this to be a full
> > stack update, so that all references get updated with the new ASG size.
> This
> > will address #1 and #2.
>
> I'm in full support of this. We already do a localized stack update on the
> nested stack, I don't see any reason why we would do a full one. It would
> make the template works without making the user do any extra declaration.
>
> > But there is an alternative to this. I guess we could copy the update
> > mechanism used on the AWS side, which is also partial, but at least
> covers
> > the load balancers, given in the LoadBalancerNames property. We can have
> a
> > "load_balancer_names" equivalent property for the OS::Heat::ASG resource,
> > and we can then trigger the updates of the load balancer(s) exactly like
> the
> > AWS side does it. For this option, I would like to extend the load
> balancer
> > update mechanism to work on custom load balancers, as it currently works
> > with the well known load balancer resources. I have implemented this
> > approach and is currently up for review:
> > https://review.openstack.org/#/c/170634/ . I honestly prefer the full
> > update, seems cleaner to me.
>
> As mentioned in the review, I don't think it's the proper approach.
> Especially considering that the load_balancer_names property would actually
> contain arbitrary resources.
>
> > Anyway, sorry for the long email. If you can provide guidance on which
> of the
> > approaches are preferred, or if you have other ideas, I would appreciate
> it.
>
> Thanks a lot for the careful explanation and for tackling this issue.
>
> --
> Thomas
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20150408/ecdbdb06/attachment.html>