On Fri, Apr 01, 2016 at 04:39:02PM +0000, Fox, Kevin M wrote: > 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?
I think it's because as soon as you start conflating specific conditions with a declarative model (in the same place, e.g within the same template), you end up with an imperative flow whether you want it or not. E.g if condition=$foo, resource X is created, but resource Y isn't, which means you no longer have an explicit definition of the required state in the template. This feels imperative because the template now contains statements which change the resulting desired state and it influences references (e.g attributes) elsewhere in the template. The more declarative approach to composition I was aiming for here: https://github.com/openstack/heat-specs/blob/master/specs/mitaka/resource-capabilities.rst This is a model where each template retains it's declarative interface, and you select which combination of templates to use by "eliminating unacceptlable solutions" exactly as you say above. Sadly I've not made much progress on this as some folks opposed it and despite a broadly positive summit session it wasn't approved until late in the Mitaka cycle :( Maybe it's something we can revisit in Newton tho. Steve __________________________________________________________________________ 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