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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
