[openstack-dev] 答复: [Heat] Re-evaluate conditions specification
Steven Hardy
shardy at redhat.com
Fri Apr 1 16:31:45 UTC 2016
On Fri, Apr 01, 2016 at 04:15:30PM +0200, 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}}
>
> my_resource:
> condition: {get_attr: [is_prod, value}}
Another alternative (which maybe you discussed, sorry I missed the IRC
chat) would be just to use parameters, as that's already conceptually where
we obtain values that are input to resources.
E.g:
parameters:
env:
type: string
default: prod
is_prod:
type: boolean
default: {equals: {get_param, env}}
>From an interface standpoint this seems much cleaner and more intuitive than
the other solutions discussed IMHO, but I suspect it's potentially harder to
implement.
Your original example gets much cleaner too if we allow all intrinsic function
(except get_attr) in the scope of parameters:
parameters:
host:
type: string
port:
type: string
endpoint:
type: string
default:
str_replace:
template:
http://HOSTORT/
params:
HOST: {get_param: host}
PORT: {get_param: port}
Steve
More information about the OpenStack-dev
mailing list