'rolling_update' property should be treated as implicitly specified
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Fix Released
|
Medium
|
Qiming Teng |
Bug Description
After a user has created an AutoScalingGroup, an AutoScalingReso
The original stack has this:
resources:
WebServerGroup:
type: OS::Heat:
properties:
resource:
type: OS::Nova::Server
flavor: flavor-1
Then, the user wants to update it to:
resources:
WebServerGroup:
type: OS::Heat:
properties:
resource:
type: OS::Nova::Server
flavor: flavor-2 # larger flavor
The current restriction is that this AutoScalingGroup resource has to have the'rolling_
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.
description: | updated |
description: | updated |
Changed in heat: | |
assignee: | nobody → Qiming Teng (tengqim) |
Changed in heat: | |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in heat: | |
assignee: | Qiming Teng (tengqim) → Thomas Herve (therve) |
Changed in heat: | |
assignee: | Thomas Herve (therve) → Qiming Teng (tengqim) |
Changed in heat: | |
milestone: | none → kilo-3 |
status: | Fix Committed → Fix Released |
Changed in heat: | |
milestone: | kilo-3 → 2015.1.0 |
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 AutoScalingReso urceGroup 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?