Open Stack

On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <zbitter at redhat.com> wrote:
> On 31/03/16 18:10, Zane Bitter wrote:
>>
>>
>> I'm in favour of some sort of variable-based implementation for a few
>> reasons. One is that (5) seems to come up fairly regularly in a complex
>> deployment like TripleO. Another is that Fn::If feels awkward compared
>> to get_variable.
>
>
> I actually have to revise this last part after reviewing the patches.
> get_variable can't replace Fn::If, because we'd still need to handle stuff
> of the form:
>
>     some_property: {if: [{get_variable: some_var},
>                          {get_resource: res1},
>                          {get_resource: res2}]
>
> where the alternatives can't come from a variable because they contain
> resource references and we have said we'd constrain variables to be static.
>
> In fact the intrinsic functions that could be allowed in the first argument
> to the {if: } function would have to constrained in the same way as the
> constraint field in the resource, because we should only validate and obtain
> dependencies from _one_ of the alternates, so we need to be able to
> determine which one statically and not have to wait until the actual value
> is resolved. This is possibly the strongest argument for keeping on the cfn
> implementation course.

We talked about another possibilities on IRC: instead of having a new
section, create a new resource OS::Heat::Value which can hold some
data. It would look like that:

resources:
    is_prod:
        type: OS::Heat::Value
        properties:
            value: {equals: {get_param, env}, prod}}

    my_resource:
        condition: {get_attr: [is_prod, value}}


Sounds like it would be fairly flexible, really easy to implement, and
solve most of the issues I can think of (including being included in
the dependency resolution mechanism for free).

-- 
Thomas