Open Stack

On 05/04/16 06:43, Steven Hardy wrote:
> 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?

Since nobody is really disputing that we should implement *something* 
can we maybe just stop having this unhelpful argument about semantics?

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

Sorry, but all of the templates and environment files and other data 
(including parameters) together constitute the model. The distinction 
you're trying to draw between stuff that is defined in the template and 
stuff that is defined in the environment (as in your "more declarative 
approach" below) is entirely spurious.

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

You could make a similar argument about parameters, and it would be just 
as pointless.

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

As long as we follow the cfn model, or something in the same ballpark, 
it's completely declarative. You're *declaring* that you want this set 
of things, and simultaneously *declaring* that you don't want this other 
set of things. The only difference between this and the current 
templates is that you're being oddly specific about things you don't want :D

There's simply no hint of imperativeness here - the conditions are all 
completely determined before the model is built.

The same would arguably not be true if we allowed arbitrary data to be 
passed as the condition and for it to be evaluated at runtime (e.g. from 
get_attr), and the need to have some distinction in the template 
structure to indicate to users that we cannot, in fact, allow this is 
the reason that I now support hewing close to the cfn model.

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

Two problems with having this as the _only_ solution:

1) Stacks are an extremely heavyweight abstraction. This is part of the 
reason that Heat can chew up 10s of GB of RAM on a TripleO deployment 
with several hundred nodes.
2) Because moving a resource into a nested stack severs its dependency 
relationship with the surrounding resources, the declarative model is 
actually broken when it comes to deleting or replacing the now-nested 
resource.[1]

cheers,
Zane.

[1] https://etherpad.openstack.org/p/mitaka-heat-break-stack-barrier