Issue #5517 has been updated by John Bollinger.
Luke Kanies wrote:
> It would be great to see a proposed fix that got us the appropriate behavior
> here and in #4778. Something like this might work:
>
> * Defer evaluation in both cases ('include' and parameterized classes)
> * Automatically evaluate unevaluated classes that have variables mentioned
> (which would fix #4778)
What if class A includes (only) class B, which in turn includes class C, and A
uses the value of $C::foo? Would class C be auto-'included' at that point?
What if B declared C via parametrized-class syntax (which will fail if C is
first 'included')?
Also, what about classes that are 'included' to ensure that their resource
declarations are parsed? A special case -- possibly with special solutions --
would be class inheritance with resource overrides (inasmuch as 'inherits' is
basically an augmented 'include'). A more general case is to prepare for
references to resources declared by the included class. And then there is
setting up for uses of troublesome functions such as defined().
I don't see a way to get all of that right without eagerly parsing classes when
they are first declared.
I propose a radical alternative: schedule parametrized-class declaration syntax
for removal in Puppet 4, and start work immediately on revising documentation
to reverse the last couple of years' tendency to describe classes as a special
kind of resources. Parametrized classes themselves would stay, relying
exclusively on hiera data binding for parameter value customization. In other
words, stop making people think that class parameter overrides should work in
the first place.
Although parametrized-class declaration syntax looks like resource declaration
syntax, there are fundamental differences between classes and resources, one of
the most important being that classes' fundamental significance is for the
**master**, whereas bona fide resources' is for target nodes. This is why the
parameter override issue is such a difficult problem for classes, whereas it is
much more tractable for resources. It was a mistake to shift toward casting
classes as resources, and the whole community, including PL, will be well
served by re-establishment of a clear distinction.
----------------------------------------
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-83530
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.
