Open Stack

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.

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.

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.

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.

Regards,

Miguel Grinberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150407/baaf84ac/attachment.html>