Open Stack

On 01/04/16 10:15, Thomas Herve wrote:
> 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}}

We could even get fancy and have an optional 'type' property for type 
checking.

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

Ah, I think I misunderstood the conversation on IRC.

Using a value from get_attr for a condition like this doesn't work, at 
least with something similar to the current implementation, because the 
result would only be known once the is_prod resource is created, but 
currently at least we exclude my_resource from the list of resource 
definitions that we return when we ask the template what it contains, 
long before we create any resources. It's possible to imagine a world in 
which all of the resource definitions are returned and we decide at the 
point of creating/updating what to do with them (create/not 
create/delete), but it would require extensive changes throughout Heat. 
The current proposed implementation is much, much safer.

What this would be *great* for is to provide the variable functionality 
that things like TripleO could really use, without needing to affect the 
implementation of conditionals at all.

> 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).

Adding OS::Heat::Value for variables & sticking with the existing spec 
for the conditional resources gets my +1. Seems less complicated all round.

cheers,
Zane.