[openstack-dev] 答复: [Heat] Re-evaluate conditions specification
zbitter at redhat.com
Tue Apr 5 14:16:54 UTC 2016
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
> 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:
> 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
More information about the OpenStack-dev