Issue #5517 has been updated by John Bollinger.
Dustin Mitchell wrote:
> 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.
But it *doesn't* otherwise work fine. This issue with parameter
(non-)overrides is one of the lesser of the problems with the syntax. The
syntax has never been a good fit for the actual underlying idea, and a number
of problems have arisen because of the mismatch. The one I most frequently
harp on is the inherent parse-order dependencies in parameterized-style class
declarations, but there are others. And if the mismatch is retained as Puppet
moves forward then it presents a risk of spawning additional issues.
Parameterized-style declarations do get the job done provided that you exercise
reasonable care -- perhaps by adhering to style guidelines tailored for the
purpose -- or that you get lucky. That's a long way from "fine" in my book.
Anyway, we have already established that class parameter overrides *cannot* be
made to work reliably. It doesn't seem very sensible to me to devise use cases
for a feature you cannot have, no matter how wonderful those uses might make
your life.
It's time for PL to throw in the towel on parameterized-style class
declarations. They simply are not the right tool for the job of binding data
to classes. They never have been, and they never can be. ARM-8 looks like it
may be moving in the right direction (thanks for the pointer, Henrik). PL
ought to be devoting its efforts to devising a solution that is fundamentally
viable, instead of trying out new shades of lipstick on the pig.
----------------------------------------
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-96398
* 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.
