
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=big5">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>

</head>

<body>

<div>Why is imperative programming always brought up when discussing conditionals in the templates? We are not wanting anything imperative. The heat engine still picks the final ordering of things. We just want to give it all the valid options, and then enough

 knowledge to eliminate unacceptlable solutions. Maybe we are using the wrong term for them? Would 'constraint' suit the conversation better?<br>

<br>

Thanks,<br>

Kevin <strong>

<div><font face="Tahoma" color="#000000" size="2"> </font></div>

</strong>

<hr tabindex="-1">

<font face="Tahoma" size="2"><b>From:</b> Thomas Herve<br>

<b>Sent:</b> Thursday, March 31, 2016 7:10:45 AM<br>

<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>

<b>Subject:</b> Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification<br>

</font><br>

<div></div>

</div>

<font size="2"><span style="font-size:10pt;">

<div class="PlainText">On Thu, Mar 31, 2016 at 2:25 PM, Huangtianhua <huangtianhua@huawei.com> wrote:<br>

> 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.<br>

> <a href="https://review.openstack.org/#/c/84468/3/doc/source/template_guide/hot_spec.rst">

https://review.openstack.org/#/c/84468/3/doc/source/template_guide/hot_spec.rst</a><br>

> <a href="https://review.openstack.org/#/c/153771/1/specs/kilo/resource-enabled-meta-property.rst">

https://review.openstack.org/#/c/153771/1/specs/kilo/resource-enabled-meta-property.rst</a><br>

<br>

And for a reason: this is a tricky issue, and introducing imperative<br>

constructs in a template can lead to bad practices.<br>

<br>

> 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.<br>

> And the patches are good in-progress. I don't want everything back to zero:)<br>

> <a href="https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/support-conditions-function">

https://review.openstack.org/#/q/status:open+project:openstack/heat+branch:master+topic:bp/support-conditions-function</a><br>

<br>

I don't say that you should scratch everything. I'm mostly OK with<br>

what has been done, with the exception of the top-level conditions<br>

section. Templates are our user interface, and we need to be very<br>

careful when we introduce new things. 3 years ago following AWS was<br>

the easy path because we didn't have much idea on what to do, but I<br>

believe we now have enough background to be more innovative.<br>

<br>

It's also slightly worrying that the spec "only" got 3 cores approving<br>

it, especially on such a touchy subject. I'm guilty as others to not<br>

have voiced my concerns then, though.<br>

<br>

-- <br>

Thomas<br>

<br>

__________________________________________________________________________<br>

OpenStack Development Mailing List (not for usage questions)<br>

Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>

<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>

</div>

</span></font>

</body>

</html>