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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
