Open Stack

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