Issue #5517 has been updated by Luke Kanies.
John Bollinger wrote:
> 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.
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.
You don't have to worry or care why the class exists, whether it's an include,
how many classes deep it is, etc.
> 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.
Huh. Interesting. I obviously hadn't thought of that. One of the reasons I
hadn't is that classes had always been resources internally, and in fact they
get translated to Component resource instances on the client (thus they still
exist as resources on the client, they're just noops).
I agree with your basic point, which is that parameterized classes were meant
to be mainly be used via external interfaces, not via the language. I've no
real idea if we could realistically make this change, though.
----------------------------------------
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-83571
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.
