Open Stack

+1. This sounds good. The lack of any conditionals at all has caused a lot of pain.

Thanks,
Kevin

________________________________
From: Huangtianhua
Sent: Thursday, March 31, 2016 5:25:29 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

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.

-----邮件原件-----
发件人: 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160331/982d81b2/attachment.html>