ResourceChain validation errors are non-obvious

[Steven Hardy]

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_ex_id=99662374-0dac-4068-8a96-0f0bce3e8ad2, action_cls='<class 'mistral.actions.action_factory.DeployStackAction'>', attributes='{}', params='{u'container': u'overcloud', u'timeout': 80}']\n ERROR: Failed to validate: : resources.ControllerServiceChain: : Failed to validate nested template: Property error: resources[3].properties: Unknown Property RoleName",

In the heat-engine.log we see:

2017-04-03 16:21:56.805 31632 INFO heat.engine.resource [req-24a08df7-df81-4bd3-a003-0cf1da99175e admin admin - - -] Validating TemplateResource "3"
2017-04-03 16:21:56.806 31632 DEBUG heat.engine.stack [req-24a08df7-df81-4bd3-a003-0cf1da99175e admin admin - - -] Property error: resources[3].properties: Unknown Property RoleName validate /usr/lib/python2.7/site-packages/heat/engine/stack.py:850

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.

[Zane Bitter (zaneb)]

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.

[Zane Bitter (zaneb)]

Actually, I think the specific thing you're asking for here was solved by bug 1686360, so I'm closing this as a duplicate.