Parameters passed via referencing an attribute in the parent template don't reflect it in when validating a template
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| OpenStack Heat |
New
|
Undecided
|
Jay Dobies | ||
Bug Description
This was split into a separate issue from https:/
The issue revolves around using the --show-nested functionality in template-validate. When enabled, the returned value will specifically describe parameters into nested stacks, including the value they are set to.
When the value passed into a nested stack is taken from the attribute of resource in the parent resource, that is not reflected in the returned template: there is no "Value" field for the nested parameter at all.
There should be some sort of indication that the value comes from the parent template. That might be as simple as having value reflect as None, although it might be nice to have some sort of syntax that reflects its relationship to the parent template resource.
| Jay Dobies (jdob) wrote | #1 |
| Changed in heat: | |
| assignee: | nobody → Jay Dobies (jdob) |
| Changed in heat: | |
| milestone: | none → no-priority-tag-bugs |
I did a bit of digging prior to submitting this. Here's what I found:
- It starts when the TemplateResource is asked for its child params.
- That calls get_user_value on each property. That's fine and works for most things, including get_param calls.
- For get_attr calls, it's running into a few problems:
--- in the GetAtt* function objects, it's checking the stack's action. If it's not one of the enumerated expected values (there are a bunch of them listed, but the value INIT isn't one of them) it returns None.
--- even if that check passed, it's still returning None
- When the parameters are formatted to be returned in the nested params dict, it's checking if param.user_value, seeing None, and omitting the Value entry in the dict.
All of the parsing parts of the above write up are triggered from the preview to generate the tree. Even if we modify or create a new version of preview for these purposes, it'd be difficult to pass something into the resolution of FnGetAtt that would let it throw a dummy value in for the get_attr case.
Since the whole process is recursive, there's no easy way of running through each parameter looking for these cases ahead of time.