Issue #1565 has been updated by Andrew Parker.
Status changed from Needs Decision to Needs More Information
Assignee changed from Andrew Parker to eric sorenson
Keywords set to language
eric sorenson wrote:
> I came across this ticket searching for related ordering issues and figured
> I'd update it while I'm here.
>
> IMO once you leave straight resource declaration syntax in the DSL, you also
> leave the realm of its claim to declarative programming.
>
Yes. I think one of the most confusing things is that there are 2 levels (at
least) in puppet: declarative resources and procedural control flow. The
language itself is mainly a procedural control flow that decides what resources
to declare. Those declarations create model of the world (the catalog) that is
interpreted as declarative program on the agent (much like SQL) where it
essentially tries to come up with a way of making the real world match the
model of the world.
> Let me narrow scope to the issue presented by James Shubin in note-7 and ask
> Andy the question:
>
> [...]
>
> Assuming the bks::foo is included somewhere, doesn't referencing that
> variable now trigger its evaluation? Shouldn't it?
Assuming `bks::foo` has been included, then it should have already been
evaluated. The act of including something should evaluate the body of the
class. I don't understand why it isn't in this case. There has been talk about
having the evaluation of variables be lazy, but that has never moved forward as
far as I know, and it also presents a lot of different problems (circular
dependencies, side effects during evaluation).
I think this is a real bug in the language as it is currently speced out.
Eric, I think this is related to a whole slew of other bugs around behavior of
`include` and `class {...}`. A quick search of redmine showed quite a lot, but
I haven't taken the time to discover which are directly related to this. Some
of them might even be a non-obvious duplication of this problem.
----------------------------------------
Bug #1565: puppet parser not order independent
https://projects.puppetlabs.com/issues/1565#change-79711
Author: Ryan McBride
Status: Needs More Information
Priority: Normal
Assignee: eric sorenson
Category: language
Target version: 3.x
Affected Puppet version: 0.22.1
Keywords: language
Branch:
The puppet parser has number of issues regarding order-of evaluation:
* It does not always ensure that included classes are evaluated before
qualified variables referring to them are evaluated.
([[LanguageTutorial#qualified-variables]])
* It may evaluate classes before the scope in which they are defined is
evaluated.
* the defined() function is "unfortunately dependent on the parse order of the
configuration when testing whether a resource is defined."
([[FunctionReference#defined]])
As far as I understand it, the intent is that puppet is a declarative language,
in which order of evaluation should not matter, and it would be nice to have
these issues cleared up. Conversely, if puppet continues to be "somewhat order
dependant", stronger mechanisms to provide control over order-of-execution or
at least make order-of-execution more predictable are necessary. I believe the
former is preferable.
The following example demonstrates the first two of these problems (tested on
both 0.24.5 and HEAD):
<pre>
######################################
# define some classes
class apache {
apache_setup { "config" : }
}
define apache_setup (
$chroot = true,
$ssl = false
) {
# sanity checking, platform-specific defaults
$_chroot = $chroot
$_ssl = $ssl
class apache_config {
$ssl = $_ssl
$chroot = $_chroot
# more variables here
}
include apache_config
# actuall apache setup goes here
}
class trac {
case $apache_config::chroot {
true: {
notice("chroot = true")
# do something
}
default: {
# do something else
notice("chroot = ${apache_config::chroot}")
}
}
}
######################################
# Now use what we've set up
class apache_ssl inherits apache {
# override the defaults
Apache_setup["config"] {
ssl => true,
chroot => false
}
}
include apache_ssl
#include apache_config
include trac
</pre>
If this example is executed as-is, we recieve the error, it has clearly been
included in apache_setup. (issue 1 above)
<pre>
Class apache_config has not been evaluated so its variables cannot be
referenced at /tmp/foo:26 on node 000AE43B1909
</pre>
If we uncomment the 'include apache_config' directive at the bottom of the
example to ensure that puppet sees the class as being included, puppet
evaluates apache_config _before_ the apache class and apache_setup define; the
scope in which apache_config is defined is not evaluated, and the variables it
depends on are evaluated as empty strings. (issue 2 above)
<pre>
notice: Scope(Class[trac]): chroot =
</pre>
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
