Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1428968

Summary:	Outputs aren't correctly validated
Product:	Red Hat OpenStack	Reporter:	Jaromir Coufal <jcoufal>
Component:	openstack-heat	Assignee:	Zane Bitter <zbitter>
Status:	CLOSED ERRATA	QA Contact:	Amit Ugol <augol>
Severity:	unspecified	Docs Contact:
Priority:	high
Version:	10.0 (Newton)	CC:	mburns, rhel-osp-director-maint, rrasouli, sbaker, shardy, srevivo
Target Milestone:	z3	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-heat-7.0.2-5.el7ost	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1428969 (view as bug list)		Environment:
Last Closed:	2017-06-28 15:25:46 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1428969

Description Jaromir Coufal 2017-03-03 17:43:11 UTC

Reference to upstream launchpad:
https://bugs.launchpad.net/heat/+bug/1599114

We've had bug(s) about this before IIRC, but it's still not working correctly, see reproducer below where an output references a wrong parameter - the stack goes CREATE_COMPLETE, but then resolving the outputs fails.

This is more of a problem than it seems at first glance, because although the stack-show error output is pretty clear, it's not reflected clearly at all when this happens in a nested template - some parent resource that references the nested stack output randomly fails and you have to manually inspect the nested stack to see the cause of the error - it'd be *much* clearer and easier to debug if the nested stack just failed.

If it's not possible to validate this during the validate stage due to dependencies on runtime data (I suspect this may be the case), we should special-case this for TemplateResource such that we resolve all attributes/outputs before declaring the parent resource COMPLETE.

[stack@instack openstack-tripleo-heat-templates]$ cat /tmp/reproducer.yaml
heat_template_version: 2016-04-08

parameters:
  SaharaWorkers:
    default: 0
    description: The number of workers for the sahara-api.
    type: number
outputs:
  role_data:
    description: Role data for the Sahara API role.
    value:
      config_settings:
        sahara::service::api::api_workers: {get_param: SaharaApiWorkers}

[stack@instack openstack-tripleo-heat-templates]$ heat stack-create r1 -f /tmp/reproducer.yaml
| 75d5a2bc-86e5-4551-8f88-4742d6a9f709 | r1 | CREATE_IN_PROGRESS | 2016-07-05T10:39:22 | None |

[stack@instack openstack-tripleo-heat-templates]$ heat stack-list
| 75d5a2bc-86e5-4551-8f88-4742d6a9f709 | r1 | CREATE_COMPLETE | 2016-07-05T10:39:22 | None |

[stack@instack openstack-tripleo-heat-templates]$ heat stack-show r1
...
| outputs | [ |
| | { |
| | "output_value": null, |
| | "output_error": "The Parameter (SaharaApiWorkers) was not provided.", |
| | "output_key": "role_data", |
| | "description": "Role data for the Sahara API role." |
| | }

Comment 7 Zane Bitter 2017-06-13 14:34:00 UTC

The reproducer here is a little too minimal to cover the change we ended up making.

The issue is not so much that we don't detect the problem with the output at validation time, as it is that when we access the output with the problem from a parent stack (using get_attr on a nested stack resource), you used to get an error message that said the attribute you were trying to access did not exist.

One solution would have been to detect the problem with the output definition at validation time, as it would have prevented the nested stack from being created at all. However, we didn't do that as it could cause problems for people with existing templates that have errors in them they were unaware of. We may eventually fix that, but not in a stable branch backport.

Instead, we fixed the error message in the parent stack to pass on the output error message from the child stack and tell the user what the source of the error was. So to test this, you'd need to create a parent stack that uses the output from the given reproducer, maybe something like this:

heat_template_version: 2016-04-08

resources:
  child:
     type: reproducer.yaml

  value:
     type: OS::Heat::Value
     value: {get_attr: [child, role_data]}

Comment 9 errata-xmlrpc 2017-06-28 15:25:46 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1589