Stack does not update properties in nested template

[Gobin Sougrakpam]

Updating weight property for OS::Neutron::PoolMember in the nested template does not update even though the stack update is successfull. Tested in Icehouse.

heat_template_version: 2013-05-23
description: AutoScaling Template for Testing
resources:
  webapp-group:
    type: OS::Heat::AutoScalingGroup
    properties:
      min_size: 1
      max_size: 2
      resource:
        type: deploy_webapp.yaml
------------------------------------------------------------------------------
deploy_webapp.yaml

pool_member:
    type: OS::Neutron::PoolMember
    properties:
      pool_id: 52222256-08f9-47c4-af8f-7a18d896ad80
      address: {get_attr: [webapp-server, first_address]}
      protocol_port: 80
      weight: 1

[Gobin Sougrakpam (gobinsougrakpam)]

Workaround

If the child template name is updated with the updated property value then the stack update takes place.
For example if you change the following lines:

resource:
        type: deploy_webapp.yaml

To

resource:
        type: deploy_webapp_updated.yaml

[Steven Hardy (shardy)]

Note this workaround probably results in the entire nested stack getting replaced, rather than recursing in to update the one resource which needs updating, which may not always be desirable.

[Steven Hardy (shardy)]

Possibly a better workaround would be to create an "update" parameter in the nested template, and change it in the parent template, which should trigger the nested stack to update without replacement:

resource:
        type: deploy_webapp.yaml
        properties:
            update: 1

then
resource:
        type: deploy_webapp.yaml
        properties:
            update: 2

This should cause the parent stack to update the child.

The problem here is we only use the nested stack resource properties (parameters in the nested stack) as a determination as to whether to update or not, when we should probably always recurse and update the entire tree.

Obviously heat should recurse automatically, trying to determine

[Steven Hardy (shardy)]

Minimal reproducer:

-bash-4.2$ cat rg_member.yaml
heat_template_version: 2013-05-23

resources:
    member:
        type: OS::Heat::RandomString
    member2:
        type: OS::Heat::RandomString

-bash-4.2$ cat resource_group_nested.yaml
heat_template_version: 2013-05-23

resources:
  random_group:
    type: OS::Heat::ResourceGroup
    properties:
      count: 2
      resource_def:
        type: rg_member.yaml

heat stack-create rg1 -f resource_group_nested.yaml

Then modify rg_member.yaml (for example adding a new resource), and update.

heat stack-update rg1 -f resource_group_nested.yaml

The tree ends up like this:
$ heat stack-list --show-nested
+--------------------------------------+----------------------------------------------+-----------------+----------------------+--------------------------------------+
| id | stack_name | stack_status | creation_time | parent |
+--------------------------------------+----------------------------------------------+-----------------+----------------------+--------------------------------------+
| 8a2c8bf5-968f-4363-b00b-ba44f512b474 | rg1 | UPDATE_COMPLETE | 2014-11-12T14:06:53Z | None |
| 23031cbd-2996-48e2-b9bc-0fe14b5e3f4c | rg1-random_group-yvdjzvvo3yqt | CREATE_COMPLETE | 2014-11-12T14:06:54Z | 8a2c8bf5-968f-4363-b00b-ba44f512b474 |
| c136ce95-6d84-46a2-84c7-5a8652e209ab | rg1-random_group-yvdjzvvo3yqt-0-p4argmnfoev2 | CREATE_COMPLETE | 2014-11-12T14:06:54Z | 23031cbd-2996-48e2-b9bc-0fe14b5e3f4c |
| d9c898c8-88be-4914-a252-064b1fc0c017 | rg1-random_group-yvdjzvvo3yqt-1-oxbxlverx5yq | CREATE_COMPLETE | 2014-11-12T14:06:54Z

So the updates to the nested template are never applied.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[Steven Hardy (shardy)]

It's been suggested by Angus in the reviews above to use the existing template resource implementation signature method to decide if we recurse or not, but that won't work for more than one level of nesting, so if we're going to do that, we at least need to traverse the entire downstream tree, calculating a hash of the template for the nested resource isn't enough:

-bash-4.2$ cat env.yaml
resource_registry:
  OS::Steve::Level1: nested_l1.yaml
  OS::Steve::Level2: nested_l2.yaml
-bash-4.2$
-bash-4.2$ cat nested_l1.yaml
heat_template_version: 2014-10-16

resources:
  server:
    type: OS::Steve::Level2
-bash-4.2$ cat nested_l2.yaml
heat_template_version: 2014-10-16

resources:
  random_name:
    type: OS::Heat::RandomString

  instance:
    type: OS::Nova::Server
    properties:
      image: cirros-0.3.3-x86_64-disk
      flavor: m1.nano
      name:
        str_replace:
            template: 'server_name-$suffix'
            params:
                $suffix: {get_resource: random_name}
  instance2:
    type: OS::Nova::Server
    properties:
      image: cirros-0.3.3-x86_64-disk
      flavor: m1.nano

outputs:
  nova_server_resource:
    description: Heat resource handle for the Nova compute server
    value:
      {get_resource: instance}
-bash-4.2$ cat two_level_nested.yaml
heat_template_version: 2014-10-16

resources:
  foo:
    type: OS::Steve::Level1

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/135348

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/135353

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Change abandoned by Steven Hardy (<email address hidden>) on branch: master
Review: https://review.openstack.org/134036
Reason: Superseded by implementation signature approach including files, as discussed with asalkeld on IRC:

https://review.openstack.org/#/c/135355/

[OpenStack Infra (hudson-openstack)]

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

commit f5221feb8bf9066b1a9cf078f224f8b00cacb5fc
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 11:51:12 2014 +0000

    Move implementation_signature to StackResource

    We need to use common logic for the update determination which
    uses implementation_signature, so move the common code from
    TemplateResource to the StackResource base-class.

    Change-Id: Ibd64b3607721487be5b0562cdb54e6c76db51149
    Partial-Bug: #1389499

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/135355
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=32b4988ae5a3720e8a8c6edd2521d1dc659ad971
Submitter: Jenkins
Branch: master

commit 32b4988ae5a3720e8a8c6edd2521d1dc659ad971
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 16:12:54 2014 +0000

    StackResource consider files in implementation_signature

    Currently, if the definition of something changes further down
    the tree (beyond the template in the StackResource itself in a
    more deeply nested template, e.g a provider resource in a
    provider resource), we don't recurse on update, so the changes
    are not reflected correctly on update.

    So modify the definition part of the StackResource implementation
    signature so we include both the resource template and the files
    map, so we recurse whenver the files content has changed.

    Note, on upgrade the first stack update of nested stacks after
    this change will update even if no changes have occurred, because
    the signature will change. This should be a no-op other than
    the stacks going UPDATE_COMPLETE.

    Change-Id: Iff3ecfbe410e47e31f78e111065888b7fd2ddd00
    Partial-Bug: #1389499

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/135669

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/135670

[OpenStack Infra (hudson-openstack)]

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

commit ea7f0144215763b62d35f3ec9bc22bba69256e69
Author: Steven Hardy <email address hidden>
Date: Wed Nov 12 19:27:36 2014 +0000

    Make ResourceGroup updates update nested stacks

    When you update a ResourceGroup which contains a provider resource
    any update only happens when the properties input to the provider
    change. Instead, always trigger an update, so we can respond to
    changes to the provider template definitions which may occur.

    For AutoScalingGroup, we may want something more sophisticated,
    where instead of unconditionally recurising on update, the option
    to instead use rolling updates to do batched replacemnt of nested
    stacks is offered. But for ResourceGroup (which is a simple
    container resource), this behavior seems most appropriate.

    Change-Id: I6e0e50c821a27a0a9fb16dbf186558da3632935d
    Closes-Bug: #1389499

[OpenStack Infra (hudson-openstack)]

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

commit f96fe31a1c6c1fa5307d9ea7955b016066a09c10
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 12:54:50 2014 +0000

    Add functional test for update of provider resource

    Adds a test where we update a nested stack definition, to ensure
    the implementation signature is correctly recognised as changed
    so the update is applied in-place to the nested stack.

    Change-Id: I2fbbf749d7265d26fd7104036fe61d3e855ca7b7
    Related-Bug: #1389499

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/135353
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=0b2256e461e275d5eda301a031bc6b868ee3ab58
Submitter: Jenkins
Branch: master

commit 0b2256e461e275d5eda301a031bc6b868ee3ab58
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 16:30:35 2014 +0000

    Add functional test for update of group of provider resources

    A new test which tests the (previously buggy) behavior when updating
    a nested stack of more than one level of nesting, specifically updating
    a ResourceGroup which contains provider resources.

    Change-Id: I8abfd99f1ecc2cc84410fb552f18f93e47144c17
    Related-Bug: #1389499

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/juno
Review: https://review.openstack.org/136426

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/135669
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=5664854f372b9810d040c615d8a678dbfdfb880e
Submitter: Jenkins
Branch: stable/juno

commit 5664854f372b9810d040c615d8a678dbfdfb880e
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 11:51:12 2014 +0000

    Move implementation_signature to StackResource

    We need to use common logic for the update determination which
    uses implementation_signature, so move the common code from
    TemplateResource to the StackResource base-class.

    Change-Id: Ibd64b3607721487be5b0562cdb54e6c76db51149
    Partial-Bug: #1389499
    (cherry picked from commit f5221feb8bf9066b1a9cf078f224f8b00cacb5fc)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/135670
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=7acee563aa99f19c28199d785d9edd8e9e880ab8
Submitter: Jenkins
Branch: stable/juno

commit 7acee563aa99f19c28199d785d9edd8e9e880ab8
Author: Steven Hardy <email address hidden>
Date: Tue Nov 18 16:12:54 2014 +0000

    StackResource consider files in implementation_signature

    Currently, if the definition of something changes further down
    the tree (beyond the template in the StackResource itself in a
    more deeply nested template, e.g a provider resource in a
    provider resource), we don't recurse on update, so the changes
    are not reflected correctly on update.

    So modify the definition part of the StackResource implementation
    signature so we include both the resource template and the files
    map, so we recurse whenver the files content has changed.

    Note, on upgrade the first stack update of nested stacks after
    this change will update even if no changes have occurred, because
    the signature will change. This should be a no-op other than
    the stacks going UPDATE_COMPLETE.

    Change-Id: Iff3ecfbe410e47e31f78e111065888b7fd2ddd00
    Partial-Bug: #1389499
    (cherry picked from commit 32b4988ae5a3720e8a8c6edd2521d1dc659ad971)

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/136426
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=808b5c7287812ed168d34196ca1e5f0dc4604b09
Submitter: Jenkins
Branch: stable/juno

commit 808b5c7287812ed168d34196ca1e5f0dc4604b09
Author: Steven Hardy <email address hidden>
Date: Wed Nov 12 19:27:36 2014 +0000

    Make ResourceGroup updates update nested stacks

    When you update a ResourceGroup which contains a provider resource
    any update only happens when the properties input to the provider
    change. Instead, always trigger an update, so we can respond to
    changes to the provider template definitions which may occur.

    For AutoScalingGroup, we may want something more sophisticated,
    where instead of unconditionally recurising on update, the option
    to instead use rolling updates to do batched replacemnt of nested
    stacks is offered. But for ResourceGroup (which is a simple
    container resource), this behavior seems most appropriate.

    Conflicts:
     heat/engine/resources/resource_group.py
     heat/tests/test_resource_group.py

    Change-Id: I6e0e50c821a27a0a9fb16dbf186558da3632935d
    Closes-Bug: #1389499
    (cherry picked from commit ea7f0144215763b62d35f3ec9bc22bba69256e69)