Open Stack

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