Open Stack

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?

Thanks,
Kevin

________________________________
From: Thomas Herve
Sent: Thursday, March 31, 2016 7:10:45 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] 答复: [Heat] Re-evaluate conditions specification

On Thu, Mar 31, 2016 at 2:25 PM, Huangtianhua <huangtianhua at huawei.com> wrote:
> 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

And for a reason: this is a tricky issue, and introducing imperative
constructs in a template can lead to bad practices.

> 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

I don't say that you should scratch everything. I'm mostly OK with
what has been done, with the exception of the top-level conditions
section. Templates are our user interface, and we need to be very
careful when we introduce new things. 3 years ago following AWS was
the easy path because we didn't have much idea on what to do, but I
believe we now have enough background to be more innovative.

It's also slightly worrying that the spec "only" got 3 cores approving
it, especially on such a touchy subject. I'm guilty as others to not
have voiced my concerns then, though.

--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160401/a87a5943/attachment.html>