Issue #5517 has been updated by Dustin Mitchell.
I dislike the idea of removing `class { name: ... }` syntax entirely. I think
it was an awkward fit and would be fine with use of a time machine to ensure it
was never introduced, but now that it's here, it has some uses, and works fine
outside of silent failures when using inheritance.
In particular, I think of classes as groups of machines. If you write `include
httpd`, then the affected machines are in the httpd class, probably meaning
they run Apache. Class membership is boolean: a machine is in a class or it's
not. This contrasts with defined resources, which can be instantiated multiple
times on the same machine. The parameterized class syntax just lets you
further refine classes. `class { 'httpd': version => 2.2; }` puts every
affected machine in the httpd-with-version-2.2 class, and has the helpful side
effect of prohibiting such machines from also being in the
httpd-with-version-2.4 class.
The use-case for overriding parameters is to indicate a machine's class in two
places, with the more specific place taking precedence. Thus, you might have a
"webserver" class that applies httpd-with-version-2.2 everywhere, but a more
specific "testing_webserver" class that inherits from "webserver" and overrides
the version to 2.4. There are other ways to accomplish this kind of
hierarchical specialization (although ironically it's not a good fit with
hiera), so as long as this syntax causes an error rather than failing silently,
I think it's OK.
----------------------------------------
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-96392
* 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.
For more options, visit https://groups.google.com/groups/opt_out.
