'rolling_update' property should be treated as implicitly specified

[Qiming Teng]

After a user has created an AutoScalingGroup, an AutoScalingResourceGroup or an InstanceGroup, he or she may want to update its setting by modifying LaunchConfiguration or the equivalent 'resource' property. For example:

The original stack has this:

  resources:
    WebServerGroup:
      type: OS::Heat::AutoScalingGroup
      properties:
        resource:
          type: OS::Nova::Server
          properties:
            flavor: flavor-1

Then, the user wants to update it to:

  resources:
    WebServerGroup:
      type: OS::Heat::AutoScalingGroup
      properties:
        resource:
          type: OS::Nova::Server
          properties:
            flavor: flavor-2 # larger flavor

The current restriction is that this AutoScalingGroup resource has to have the'rolling_updates' property specified, even if a 'rolling_updates' property has a default value set that can be used. If there is no 'rolling_updates' property, the changes to the resource definition above won't happen.

The expected behavior is that 'rolling_updates' should be an implicit property since all of its fields have default values. Even it is not specified, Heat can make a good/valid guess that the user wants to update all members using the new properties.

The 'rolling_updates' property, as an optional one, is then used to customize how rolling updates is performed, instead of determining whether rolling update will happen or not.

[Qiming Teng (tengqim)]

I think I need to hear more from users before trying to fix this.

The reason I filed this bug is that we got complaints from users that stack update didn't work. In other words, no member from the group will change even the resource properties are different now. This is against their initial expectation. Resource definition is part of the InstanceGroup and AutoScalingResourceGroup resource. It is a little bit odd if we don't do anything just because user didn't specify update_policy.

The reason I hesitated to fix this is because AWS explicitly stated that updating LaunchConfiguration won't lead to a rolling update automatically. If we fix this, it will be another divergence from AWS.

Comments, suggestions?

[Zane Bitter (zaneb)]

We shouldn't break compatibility with CloudFormation for the AWS::AutoScaling::* resources, but we certainly can and I think probably should change this for the OS::Heat::* resources. Those resources don't have a separate LaunchConfiguration resource, so in my view it doesn't make a lot of sense not to update them if the configuration changes.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/137945

[Zane Bitter (zaneb)]

Since last time I looked at this I've figured out a bit more about how AWS works:

- The LaunchConfig is separate from the Autoscaling group itself
- LaunchConfigs are immutable, you create a new one rather than change them
- Autoscaling groups can happily contain members from different LaunchConfigs
- When scaling down, servers created from older LaunchConfigs are removed first
- All servers get replaced only if a rolling update is specifically requested in the update policy

In the native Autoscaling group type we elected (over my strenuous objections IIRC) to get rid of the separate LaunchConfig and make it part of the group's properties. It's still not yet clear to me what a good implementation of rolling update should look like in that model.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/137945
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=571b4dd7babeb7002377dbd895ae63072d914710
Submitter: Jenkins
Branch: master

commit 571b4dd7babeb7002377dbd895ae63072d914710
Author: tengqm <email address hidden>
Date: Sun Nov 30 19:23:22 2014 +0800

    Make Heat ASG always do rolling_updates

    This patch closes a bug related to the 'rolling_updates' property of a
    Heat AutoScalingResourceGroup resource. Currently the 'rolling_updates'
    property is a map will all keys having default values assigned. This
    means the 'rolling_updates' property as a whole has a default value
    ready to be used.

    Closes-Bug: 1343873
    Change-Id: Icb8dcf44ab16c0547fd1b8edcce650a6892900f2