<div dir="ltr">Thomas,<div><br></div><div>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.</div><div><br></div><div>I'll look into doing an update when a resize event is triggered, since we seem to agree that it is a potential solution.</div><div><br></div><div>Thanks,</div><div><br></div><div>Miguel</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 8, 2015 at 7:30 AM, Thomas Herve <span dir="ltr"><<a href="mailto:thomas.herve@enovance.com" target="_blank">thomas.herve@enovance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Response inline.<br>
<span class=""><br>
<br>
> Hi,<br>
><br>
> The OS::Heat::AutoScalingGroup resource is somewhat limited at this time,<br>
> because when a scaling even occurs it does not notify dependent resources,<br>
> such as a load balancer, that the pool of instances has changed.<br>
<br>
</span>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.<br>
<div><div class="h5"><br>
> The AWS::AutoScaling::AutoScalingGroup resource, on the other side, has a<br>
> LoadBalancerNames property that takes a list of<br>
> AWS::ElasticLoadBalancing::LoadBalancer resources that get updated anytime<br>
> the size of the ASG changes.<br>
><br>
> I'm trying to implement this notification mechanism for HOT templates, but<br>
> there are a few aspects that I hope to do better.<br>
><br>
> 1. A HOT template can have get_attr function calls that invoke attributes of<br>
> the ASG. None of these update when the ASG resizes at this time, a scaling<br>
> even does a partial update that only affects the ASG resource. I would like<br>
> to address this.<br>
><br>
> 2. The AWS solution relies on the well known LoadBalancer resource, but often<br>
> load balancers are just regular instances that get loaded with a load<br>
> balancer such as haproxy in a custom way. I'd like custom load balancers to<br>
> also update when the ASG resizes.<br>
><br>
> The ResourceGroup is an interesting resource. It is much simpler than the<br>
> ASG. In particular, the only way to scale the ResourceGroup is by issuing a<br>
> stack-update with a new size. This indirectly solves #1 and #2 above,<br>
> because when a full update is issued any references to the ResourceGroup get<br>
> updated as well.<br>
><br>
> In my opinion, the best way to address #1 and #2 above so that they work for<br>
> the ASG as they work for the RG, is to change what happens when there is a<br>
> scaling event. When the ScalingPolicy resource gets a signal, it reaches<br>
> directly to the ASG by calling asg.adjust() (or in the near future by<br>
> sending a signal to it, when a currently proposed patch merges) with the new<br>
> size. This bypasses the update mechanism, so only a partial update occurs,<br>
> just the ASG resource itself is updated. I would like this to be a full<br>
> stack update, so that all references get updated with the new ASG size. This<br>
> will address #1 and #2.<br>
<br>
</div></div>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.<br>
<span class=""><br>
> But there is an alternative to this. I guess we could copy the update<br>
> mechanism used on the AWS side, which is also partial, but at least covers<br>
> the load balancers, given in the LoadBalancerNames property. We can have a<br>
> "load_balancer_names" equivalent property for the OS::Heat::ASG resource,<br>
> and we can then trigger the updates of the load balancer(s) exactly like the<br>
> AWS side does it. For this option, I would like to extend the load balancer<br>
> update mechanism to work on custom load balancers, as it currently works<br>
> with the well known load balancer resources. I have implemented this<br>
> approach and is currently up for review:<br>
</span>> <a href="https://review.openstack.org/#/c/170634/" target="_blank">https://review.openstack.org/#/c/170634/</a> . I honestly prefer the full<br>
<span class="">> update, seems cleaner to me.<br>
<br>
</span>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.<br>
<span class=""><br>
> Anyway, sorry for the long email. If you can provide guidance on which of the<br>
> approaches are preferred, or if you have other ideas, I would appreciate it.<br>
<br>
</span>Thanks a lot for the careful explanation and for tackling this issue.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thomas<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></span></blockquote></div><br></div>