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 <huangtian...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
