Invalid AWS::StackId value is returned when updating a nested stack

Bug #1260282 reported by Simon Pasquier
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
Undecided
Zane Bitter

Bug Description

When updating a stack containing a nested stack, the AWS::StackId value expanded in the nested stack is invalid as it ends with '/None' (see logs below). Note that my code is patched with the fix for bug #1240888.

The templates are publicly available:
- stack: http://gitorious.ow2.org/~xlcloud-continuous-integration/xlcloud/heat-resources-ci/blobs/0cc2383eb1e8d19cdf35435d9937df29ac088ca3/templates/stack-blueprints/slurm-stack.yaml
- nested stack: http://gitorious.ow2.org/~xlcloud-continuous-integration/xlcloud/heat-resources-ci/blobs/0cc2383eb1e8d19cdf35435d9937df29ac088ca3/templates/layer-blueprints/slurm-layer.yaml

They are fairly complex so I'll try to come up with simpler ones to demonstrate the bug.

Heat engine logs (with added debug logs):
2013-12-12 11:45:14.088 23557 WARNING heat.engine.resource [-] [update_template_diff_properties] the following keys have raised UpdateReplace for 'Instance "Login"': set([u'Tags'])
2013-12-12 11:45:14.088 23557 WARNING heat.engine.resource [-] [update_template_diff_properties] Properties[Tags]: [{u'Key': u'metering.StackId', u'Value': u'arn:openstack:heat::22f8c2381d104ae7871029e47a956b0c:stacks/HPCVC-Slurm-fh6rvg3g6c2s/None'}]
2013-12-12 11:45:14.649 23557 ERROR heat.engine.resource [-] CREATE : Instance "Login"
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource Traceback (most recent call last):
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/src/heat/heat/engine/resource.py", line 369, in _do_action
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource handle_data = handle()
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/src/heat/heat/engine/resources/instance.py", line 362, in handle_create
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource availability_zone=availability_zone)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/v1_1/servers.py", line 658, in create
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource **boot_kwargs)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/base.py", line 402, in _boot
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource return_raw=return_raw, **kwargs)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/base.py", line 145, in _create
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource _resp, body = self.api.client.post(url, body=body)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/client.py", line 232, in post
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource return self._cs_request(url, 'POST', **kwargs)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/client.py", line 213, in _cs_request
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource **kwargs)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/client.py", line 195, in _time_request
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource resp, body = self.request(url, method, **kwargs)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource File "/usr/local/heat/local/lib/python2.7/site-packages/novaclient/client.py", line 189, in request
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource raise exceptions.from_response(resp, body, url, method)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource ClientException: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d5a9a7a1-224c-4a55-9a1e-08e2798ff3ec)
2013-12-12 11:45:14.649 23557 TRACE heat.engine.resource
2013-12-12 11:45:14.708 23557 ERROR heat.engine.resource [-] update NestedStack "Slurm" : Nested stack update failed: ClientException: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d5a9a7a1-224c-4a55-9a1e-08e2798ff3ec)
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource Traceback (most recent call last):
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource File "/usr/src/heat/heat/engine/resource.py", line 443, in update
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource while not self.check_update_complete(handle_data):
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource File "/usr/src/heat/heat/engine/stack_resource.py", line 174, in check_update_complete
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource nested_stack.status_reason)
2013-12-12 11:45:14.708 23557 TRACE heat.engine.resource Error: Nested stack update failed: ClientException: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-d5a9a7a1-224c-4a55-9a1e-08e2798ff3ec)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

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

Changed in heat:
assignee: nobody → Simon Pasquier (simon-pasquier)
status: New → In Progress
Revision history for this message
Simon Pasquier (simon-pasquier) wrote :
Download full text (4.7 KiB)

I've been able to reproduce the problem with simpler templates:
- stack.yaml, creates a nested stack passing it the 'foobar' parameter straight from the input parameters + the parent stack id (http://paste.openstack.org/show/55059/)
- nested.yaml, creates 2 instance resources: Node1 and Node2 (http://paste.openstack.org/show/55060/)

When a stack update operation modifies the foobar parameter:
  - Node1 should be updated in place because foobar is only referenced in Tags and Metadata properties. The User-Data property references the parent stack id but this should not be changed by the stack update.
  - Node2 should be replaced because foobar is also injected into the User-Data property.

To reproduce on a DevStack installation, drop the nested.yaml file to the ${DEST}/horizon/openstack_dashboard/static/ directory.

The following output demonstrates that Node1 instance is replaced while it should be updated in place. You'll see that the 'AWS::StackId' for the parent stack ends with '/None' instead of the stack identifier.

$ heat stack-create -f stack.yaml -P "foobar=123;xlcloud:defaultKeyName=test" stack1
+--------------------------------------+------------+--------------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+--------------------+----------------------+
| a295e13a-f5e9-40b3-861f-d78ecea93aa5 | stack1 | CREATE_IN_PROGRESS | 2013-12-16T15:34:21Z |
+--------------------------------------+------------+--------------------+----------------------+

$ nova list
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+------------------+
| 7ad411b8-5dc7-492a-8487-ee33503164fb | stack1-GettingStarted-efiupd3vuy3n-Node1-djgxpbxqkuu6 | ACTIVE | None | Running | private=10.0.0.4 |
| 38a0c4cf-3440-4fc6-bb78-fe7e7c961d02 | stack1-GettingStarted-efiupd3vuy3n-Node2-nedndtcp3p4m | ACTIVE | None | Running | private=10.0.0.2 |
+--------------------------------------+-------------------------------------------------------+--------+------------+-------------+------------------+

$ heat stack-update -f stack.yaml -P "foobar=1234;xlcloud:defaultKeyName=test" stack1
+--------------------------------------+------------+--------------------+----------------------+
| id | stack_name | stack_status | creation_time |
+--------------------------------------+------------+--------------------+----------------------+
| a295e13a-f5e9-40b3-861f-d78ecea93aa5 | stack1 | UPDATE_IN_PROGRESS | 2013-12-16T15:34:21Z |
+--------------------------------------+------------+--------------------+----------------------+

$ nova list
+--------------------------------------+-----------------------------...

Read more...

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

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

Changed in heat:
assignee: Simon Pasquier (simon-pasquier) → Zane Bitter (zaneb)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to heat (master)

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

commit 92583c6c79ebcece89eb90c8581634b9ea10832a
Author: Zane Bitter <email address hidden>
Date: Tue Jan 28 18:27:34 2014 -0500

    Fix AWS::StackId pseudo-parameter during stack update

    Parameters, including pseudo-parameters, are resolved at the time that
    resources are created, which is as soon as they are first accessed (in the
    case of a stack update, this means during the validation of the new
    template). As a result, by the time we set the AWS::StackId
    pseudo-parameter in the process of doing an update it is already too late
    for resources in the new stack to resolve them correctly. This was leading
    to spurious differences being detected on stack update.

    This patch fixes the issue by setting the pseudo-parameter before any
    resources in the new stack are created.

    Fixes bug 1260282

    Change-Id: I908879827d6460ecbef30e9db98ac5597dc323cd

Changed in heat:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in heat:
milestone: none → icehouse-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: icehouse-3 → 2014.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.