Open Stack

Params have the added advantage that horizon could be potentially tweaked to do form validation in the ui based in it.

Thanks,
Kevin

________________________________
From: Steven Hardy
Sent: Friday, April 01, 2016 9:31:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160401/c9201702/attachment.html>