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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
