ResourceChain validation errors are non-obvious
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Heat |
Triaged
|
Medium
|
Unassigned |
Bug Description
When validation fails on a ResourceChain referencing multiple nested stacks, it's really hard to figure out which template contains the error, particularly when you have concurrent: true selected.
Example from a TripleO CI job:
2017-04-03 16:21:59.276836 | u'message': u"Failed to run action [action_
In the heat-engine.log we see:
2017-04-03 16:21:56.805 31632 INFO heat.engine.
2017-04-03 16:21:56.806 31632 DEBUG heat.engine.stack [req-24a08df7-
In both cases it's basically impossible to work out which nested stack "3" relates to, without digging into code or perhaps setting concurrent: false so the resource names match the input list indexes.
It'd be really great if we could detect on any kind of validation error that the stack is a nested stack, and output the template name or resource_registry alias along with the validation error.
Changed in heat: | |
status: | New → Triaged |
importance: | Undecided → Medium |
milestone: | none → pike-1 |
Changed in heat: | |
milestone: | pike-1 → pike-2 |
Changed in heat: | |
milestone: | pike-2 → pike-3 |
Changed in heat: | |
milestone: | pike-3 → pike-rc1 |
The problem isn't that this is a nested stack, the problem is that ResourceChain uses non-descriptive resource names like "3". (Changing that now would massively bork existing stacks though.)
It _might_ be possible to hack the error messages for just ResourceChain to display e.g. the type name instead of the resource name in the error path.
> perhaps setting concurrent: false so the resource names match the input list indexes.
This seems wrong - the indices are always assigned in the same order as the input list. The only difference that concurrent: false makes is that adds depends_on to order the actual creation.