Issue #5517 has been updated by John Bollinger.
Luke Kanies wrote:
> It's pretty easy -- if code asks for a variable scoped in a class that hasn't
> been evaluated, and a resource exists that can be evaluated right now, then
> evaluate. Otherwise, fail.
Do you mean *any* class that hasn't yet been evaluated, or do you mean the
class to which the variable belongs? If the latter, then you are creating a
new failure scenario. Consider:
class m::a {
include m::b
notify { "m::c::var is ${m::c::var}": }
}
class m::b {
class { 'm::c': param => 'from_b' }
}
class m::c ($param = 'default') {
$var = $param
}
(in separate files). That code should compile and run fine on Puppet 2.6 -
3.1, and the Notify's message is always "m::c::var is from_b". If that is to
continue to work as it does now in a lazy evaluation mode, then when the parser
sees ${c::var} it cannot just look for class c and parse it, because
1. it will get the wrong value for the variable, and
2. when it eventually gets around to evaluating class b, the parser will fail
at the parametrized declaration of c with a duplicate declaration error. And
rightly so -- this is not merely a (mostly) harmless duplicate, this is (with
the proposed parse order) is a conflicting declaration.
Suppose, then, that when the parser sees ${m::c::var} in class m::a, it must
start parsing all as-yet unparsed classes until one of them causes class c to
be evaluated. Well, that would work in the simple scenario I present, but
1. a more complicated scenario could be created in which the same problem will
be triggered by some other class -- say one that contains "include c", and
which eager parsing reliably parses after class b.
2. at this point you've pretty much scuttled the whole plan anyway, because it
is pretty hard to predict whether any given class is going to be evaluated
early or late, so class parameter overrides still don't work reliably.
John
----------------------------------------
Bug #5517: behavior change within 2.6 makes it impossible to override class
parameters of "included" parametrized classes
https://projects.puppetlabs.com/issues/5517#change-83581
Author: Peter Meier
Status: Accepted
Priority: High
Assignee: eric sorenson
Category: language
Target version: 3.x
Affected Puppet version: 3.0.2
Keywords: parameterized_classes
Branch:
In 2.6.1 the following recipe:
<pre>
class a(
$b_c = { 'b' => 'foo' }
) {
notice $a::b_c
if $a::b_c {
notice $a::b_c['b']
}
}
class b {
class{'a': b_c => false }
}
class b::c inherits b {
Class['a']{ b_c => { 'b' => 'bleh' } }
}
class b::d {
include ::b::c
}
include b::d
</pre>
produces the following output:
<pre>
$ puppet foo.pp
notice: Scope(Class[A]): bbleh
notice: Scope(Class[A]): bleh
</pre>
Which is what I expected. However with 2.6.3 it produces the following output:
<pre>
# puppet foo.pp
notice: Scope(Class[A]): false
</pre>
Imho likely the changes for #4778 and #5074 are responsible for that behavior
change.
However this makes it impossible to overwrite parameters of a "included"
parametrized class in a subclass. There are only ugly workarounds for that
problem and I think this should actually work as it did within 2.6.1. Otherwise
the usefulness of parametrized classes is quite reduced.
--
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 unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
