Open Stack

> The conditions function has been requested for a long time, and there have
> been several previous discussions, which all ended up in debating the
> implementation, and no result.
> https://review.openstack.org/#/c/84468/3/doc/source/template_guide/hot_spec.rst
> https://review.openstack.org/#/c/153771/1/specs/kilo/resource-enabled-meta-property.rst
> 
> I think we should focus on the simplest possible way(same as AWS) to meet the
> user requirement, and follows the AWS, there is no doubt that we will get a
> very good compatibility.
> And the patches are good in-progress. I don't want everything back to zero:)
> https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/support-conditions-function
> 
> In the example you given of 'variables', seems there's no relation with
> resource/output/property conditions, it seems as another function which
> likes really 'variables' to used in template.

If I understand the suggestion correctly, the only relation it has with conditions is,
conditions are nothing but variables(boolean).

conditions: {
    'for_prod': {equals: [{get_param: env_type}, 'prod']}
  }

would be

variables:
   for_prod: {equals: [{get_param: env_type}, prod]}


then you can use it in your example as:

    floating_ip:
      type: OS::Nova::FloatingIP
      condition: {get_variable: for_prod}

so suggestion is to make it more generic, so that it can be used for other things
and reduce some of the verbosity in the templates.

However, I think the term 'variable' makes is sound more like a programming thing. May
be we can use something better. However, personally I kind of like the idea.
 
> -----邮件原件-----
> 发件人: Thomas Herve [mailto:therve at redhat.com]
> 发送时间: 2016年3月31日 19:55
> 收件人: OpenStack Development Mailing List (not for usage questions)
> 主题: Re: [openstack-dev] [Heat] Re-evaluate conditions specification
> 
> On Thu, Mar 31, 2016 at 10:40 AM, Thomas Herve <therve at redhat.com> wrote:
> > Hi all,
> >
> > As the patches for conditions support are incoming, I've found
> > something in the code (and the spec) I'm not really happy with. We're
> > creating a new top-level section in the template called "conditions"
> > which holds names that can be reused for conditionally creating
> > resource.
> >
> > While it's fine and maps to what AWS does, I think it's a bit
> > short-sighted and limited. What I have suggested in the past is to
> > have a "variables" (or whatever you want to call it) section, where
> > one can declare names and values. Then we can add an intrinsic
> > function to retrieve data from there, and use that for examples for
> > conditions.
> 
> I was asked to give examples, here's at least one that can illustrate what I
> meant:
> 
> parameters:
>    host:
>       type: string
>    port:
>       type: string
> 
> variables:
>    endpoint:
>       str_replace:
>         template:
>            http://HOST:PORT/
>         params:
>            HOST: {get_param: host}
>            PORT: {get_param: port}
> 
> resources:
>    config1:
>       type: OS::Heat::StructuredConfig
>       properties:
>         config:
>            hosts: [{get_variable: endpoint}]
> 
> --
> Thomas
> 
> __________________________________________________________________________
> 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
> __________________________________________________________________________
> 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
>