This is the same issue I ran into a few months ago regarding the nested parameter validation. Since it resolves to None at that time, there's no hook in our current nested parameters implementation to show that it will have a value passed in from the parent template.

Unfortunately, I don't have much to offer in terms of a solution, but I'm very interested in where this conversation goes :)

On 3/23/16 1:14 PM, Steven Hardy wrote:
Hi all,

I'm looking for some help and additional input on this bug:

Basically, we have multiple issues due to the fact that we consider
get_attr to resolve to None at any point before a resource is actually

It's due to this:

This then causes problems during validation of several intrinsic functions,
because if they reference get_attr, they have to contain hacks and
special-cases to work around the validate-time None value (or, as reported
in the bug, fail to validate when all would be fine at runtime).

I started digging into fixes, and there are probably a few possible
approaches, e.g setting stack.Stack.strict_validate always to False, or
reworking the intrinsic function validation to always work with the
temporary None value.

However, it's a more widespread issue than just validation - this affects
any action which happens before the actual stack gets created, so things
like preview updates are also broken, e.g consider this:

     type: OS::Heat::RandomString

     type: OS::Heat::StructuredConfig
       group: script
         foo: {get_attr: [random, value]}

     type: OS::Heat::StructuredDeployment
         get_resource: config
       server: "dummy"

On update, nothing is replaced, but if you do e.g:

   heat stack-update -x --dry-run

You see this:

| replaced  | config        | OS::Heat::StructuredConfig     |

Which occurs due to the false comparison between the current value of
"random" and the None value we get from get_attr in the temporary stack
used for preview comparison:

after_props.get(key) returns None, which makes us falsely declare the
"config" resource gets replaced :(

I'm looking for ideas on how we solve this - it's clearly a major issue
which completely invalidates the results of validate and preview operations
in many cases.


OpenStack Development Mailing List (not for usage questions)

OpenStack Development Mailing List (not for usage questions)

Reply via email to