Nested Stacks cannot read their resource metadata

Bug #1131666 reported by Steven Hardy
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Heat
Fix Released
High
Steven Hardy

Bug Description

Raising this bug related to the issue described in https://review.openstack.org/#/c/21863/ and following discussion.

Summary of way forward as proposed by Zane:

1) AWS::CloudFormation::Stack resources show up as completely normal stacks (we use a unique name + set owner=None).

2) Other nested stacks don't show up in ListStacks &c. (i.e. we continue passing the parent stack as the "owner"), but can still be accessed normally by anyone who knows the ARN (which can be found from the PhysicalResourceId, and of course appears in e.g. WaitConditionHandle URLs of resources inside the nested stack).

Fixing this will solve one of the issues mentioned in https://review.openstack.org/#/c/21864/, where the LoadBalancer nested stack cannot access it's resource metadata for cfn-hup (although it is a wider issue for all nested stacks)

Steven Hardy (shardy)
Changed in heat:
status: New → In Progress
importance: Undecided → High
assignee: nobody → Steven Hardy (shardy)
milestone: none → grizzly-rc1
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/22998

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

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

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

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

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

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

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

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

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

Reviewed: https://review.openstack.org/22998
Committed: http://github.com/openstack/heat/commit/8a4a1960f152431bd0ae822b249da156dc9d3bf1
Submitter: Jenkins
Branch: master

commit 8a4a1960f152431bd0ae822b249da156dc9d3bf1
Author: Steven Hardy <email address hidden>
Date: Mon Feb 25 14:47:45 2013 +0000

    heat engine : Add parser parameter support for AWS::StackId

    Adds support for the AWS::StackId pseudo parameter, which will
    allow us to to reference the stack ARN in the template, e.g so that
    stacks can query their resource metadata via ARN not stack name,
    which will solve the problem with nested resource being unable
    to query their metadata.

    ref bug 1131666

    Change-Id: Ib7b1d380fa8766b6d0c968bd66270da8ce8245c4

Changed in heat:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/22999
Committed: http://github.com/openstack/heat/commit/79bc8170a0d854b2d688af2da82f0ff3e106e562
Submitter: Jenkins
Branch: master

commit 79bc8170a0d854b2d688af2da82f0ff3e106e562
Author: Steven Hardy <email address hidden>
Date: Mon Feb 25 16:34:13 2013 +0000

    heat engine : Set stack parameters AWS::StackId on stack create/store

    We need to set the ARN provided via the AWS::StackId pseudo parameter
    when the stack is stored, and also whenever a parser.Stack object is
    created

    ref bug 1131666

    Change-Id: Ic8dc5ab2b25c85c51f2f685fe69bb2447a1e3615

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

Reviewed: https://review.openstack.org/23000
Committed: http://github.com/openstack/heat/commit/f4fcb7bd5ae3345555f1ac8fdbad2fe84408c0a5
Submitter: Jenkins
Branch: master

commit f4fcb7bd5ae3345555f1ac8fdbad2fe84408c0a5
Author: Steven Hardy <email address hidden>
Date: Tue Feb 26 14:55:18 2013 +0000

    heat engine : Compare runtime resolved resource snippets on update

    We need to compare the runtime resolved resource snippet, since that
    is what we get back from self.parsed_template. If we don't do this,
    then we get a false positive when a Ref to a parameter which gets
    updated (e.g AWS::StackId) is used in the resource properties.

    ref bug 1131666

    Change-Id: Ib488c43b9eca998a7a82b7571097f5bb69ef946c

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

Reviewed: https://review.openstack.org/23001
Committed: http://github.com/openstack/heat/commit/83780a788f00a8bb08bc71fa8db06a9a8f11be9f
Submitter: Jenkins
Branch: master

commit 83780a788f00a8bb08bc71fa8db06a9a8f11be9f
Author: Steven Hardy <email address hidden>
Date: Tue Feb 26 14:17:00 2013 +0000

    heat engine : Re-resolve resource static data before create

    Re-resolve the template static data before creating the resource,
    or we resolve the wrong value for the AWS::StackId pseudo parameter
    which is updated after the parser.Stack gets stored.

    ref bug 1131666

    Change-Id: I68e87366d379356fd7f2685367300abe5594d6f6

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

Reviewed: https://review.openstack.org/23002
Committed: http://github.com/openstack/heat/commit/6b55ccfaeacdb174e3e80912d7cd52951e9de0f2
Submitter: Jenkins
Branch: master

commit 6b55ccfaeacdb174e3e80912d7cd52951e9de0f2
Author: Steven Hardy <email address hidden>
Date: Tue Feb 26 14:20:00 2013 +0000

    heat engine : loadbalancer resource template, refer to StackId

    Use the new AWS::StackId pseudo parameter to refer to the stack for
    cfn-hup etc, otherwise the stack lookup by name will fail - using
    the AWS::StackId parameter means we'll refer to the stack via the
    full ARN and the CFN API will be able to lookup the nested stack.

    ref bug 1131666

    Change-Id: Ieac738df766ae1f1039e743d465cd080b2090473

Thierry Carrez (ttx)
Changed in heat:
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in heat:
milestone: grizzly-rc1 → 2013.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.