Open Stack

Excerpts from Chan, Winson C's message of 2013-06-18 23:22:15 -0700:
> Is the expectation here that the update policy for the auto-scaling group is enforced only when either the launch configuration or subnet group membership is changed in the auto-scaling group?  The LaunchConfigurationName is not currently listed as an update_allowed_properties in the AutoScalingGroup.  Update handling is not implemented in LaunchConfiguration either.  Also, VPCZoneIdentifier for listing subnet group membership is not implemented in the AutoScalingGroup either.  Should there be blueprints to handle these before working on the update policy?

I'm afraid I can't be much help here. The way AWS works is not really of
any concern to me. The way I think InstanceGroup and AutoScalingGroup
should work isn't really compatible with CloudFormation, so I don't
think it is worthwhile to lend too much credence to "how things are now".

If you want it to work like AWS, I suggest testing on AWS and then
filing/fixing bugs against Heat. However, if you want a rolling updates
mechanism to be practical and highly useful, I'd suggest reviewing the
rolling-updates blueprint/spec and helping to improve it. I'd like to
rewrite the spec actually, as I have learned a lot since writing it and
now have some better ideas on how to implement it.