On 01/04/16 10:15, Thomas Herve wrote:
On Fri, Apr 1, 2016 at 3:21 AM, Zane Bitter <[email protected]> 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.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
