stack-update doesn't update the metadata for running stack/resources

[Saurabh Surana]

The template that I used is available @ https://gist.github.com/saurabhsurana/9357107

I created stack with following command:
$heat stack-create Trove-API-2 -f trove.yaml -P "Trove-Image-ID=a8e065cd-5c18-4de7-84c5-c4977138dc68;Trove-Debug=False"

once the stack was up and running, I verified that stack metadata using

$heat resource-metadata Trove-API-2 troveapi
{
  "db": "mysql://<<>>:<<>>@10.0.0.1/trove",
  "trove": {
    "debug": "False",
    "bind_port": 8779,
    "verbose": true,
    "rabbit": {
      "host": "10.0.0.1",
      "password": "<<>>"
    }
  },
  "keystone": {
    "host": "10.0.0.1",
    "service-password": "<<>>"
  }
}

After this I tried to use stack-update to update the metadata on the running stack/resources with the following command:
$ heat stack-update Trove-API-2 -f trove.yaml -P "Trove-Image-ID=a8e065cd-5c18-4de7-84c5-c4977138dc68;Trove-Debug=True"
+--------------------------------------+-------------+-----------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+-------------+-----------------+----------------------+
| 2037646b-7c2c-43c8-866f-6963ec8d0873 | Trove-API-2 | CREATE_COMPLETE | 2014-02-28T06:31:49Z |
+--------------------------------------+-------------+-----------------+----------------------+

After this when I checked the resource-metadata, I didn't see the updated values of Trove-Debug (which is set to trove:debug):
$ heat resource-metadata Trove-API-2 troveapi
{
  "db": "mysql://<<>>:<<>>@10.0.0.1/trove",
  "trove": {
    "debug": "False",
    "bind_port": 8779,
    "verbose": true,
    "rabbit": {
      "host": "10.0.0.1",
      "password": "<<>>"
    }
  },
  "keystone": {
    "host": "10.0.0.1",
    "service-password": "<<>>"
  }
}

I did verify that the update of the debut parameter didn't even reflect inside the heat.stack table in the database.

[Steve Baker (steve-stevebaker)]

This may be related to bug 1291411. Can you please retest when this change lands? https://review.openstack.org/#/c/81678/

[Steve Baker (steve-stevebaker)]

Also, the gist is gone, can you please attach the template file.

[Steve Baker (steve-stevebaker)]

This tempest test appears to confirm that this bug exists.
https://review.openstack.org/#/c/107899/

I was relying on stack-update with changed metadata for the autoscaling tempest test, so I consider this a regression.
https://review.openstack.org/#/c/44967/7/tempest/scenario/orchestration/test_autoscaling.py

[Steven Hardy (shardy)]

After discussing this with stevebaker we've agreed to bump this to J3

[Steve Baker (steve-stevebaker)]

I don't think we can have a default behaviour which updates resource metadata during a stack update since so many resource implementations use metadata to store state.

CloudFormation templates only ever use Metadata for AWS::EC2::Instance, AWS::AutoScaling::LaunchConfiguration, and very occasionally AWS::CloudFormation::Stack (and to work around JSON's lack of comments)

HOT version 2013-05-23 has an undocumented metadata property for transitional purposes only, we should consider removing it completely from HOT version 2014-10-16

So I think this bug should track allowing updates of Metadata only for resources AWS::EC2::Instance and AWS::AutoScaling::LaunchConfiguration

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit 404bcbdacc7155a3eb52b9010e42cb0c9eed43e0
Author: Steve Baker <email address hidden>
Date: Tue Aug 5 12:32:47 2014 +1200

    LaunchConfiguration replace on changed Metadata

    This makes AWS::AutoScaling::LaunchConfiguration raise
    an UpdateReplace if its template Metadata is changed on a
    stack update. Any changes to LaunchConfiguration should result
    in the resource being replaced, since this is how those changes
    propagate to the scaling group.

    This fixes a regression which has likely existed since
    update_allowed_keys was removed: I78494aba07b6badeca8e95f1875ca8e4b9b0290c

    Change-Id: I3a53422ed862777dffb9cac28088fbfe8dd417fa
    Closes-Bug: #1287953