Issue #5517 has been updated by John Bollinger.
Luke Kanies wrote: > On Aug 14, 2013, at 9:18 AM, "[email protected]" < > [email protected]> wrote: > > Issue #5517 has been updated by John Bollinger. [Me:] > 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. [Luke:] > I'm not sure I agree with this. I don't think we've actually tried very > much to make this work, have we? What alternatives have we actually tried? We already had this discussion in this very thread. See your own response at #45. You are free to find fault with my characterization of the situation, or even with my definition of "reliably", but you have already acknowledged that there is no way to completely solve the problem. > 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. > > Hi John, > > Do you have a recommendation for what we would replace it with? Do you > think classes still make sense in a world without parameterized classes, or > do you think we should just remove classes entirely? I think you are baiting me, but nevertheless 1. Yes, classes make sense regardless of parameterization. They are one of the fundamental things that make Puppet work well. They did the job very nicely before class parameterization was introduced, and nothing now in Puppet itself makes it essential to use parameterized classes. Fundamentally, class parameters are merely a formal definition of (some of) the data consumed by / characterizing classes in the context of particular nodes. Although such a thing can be useful, it is not an essential part of classes' nature. 2. I am not now arguing, nor have I done since Puppet 3 was released, that parameterized classes themselves should not be used. Instead, I am arguing that parameterized-style class declaration syntax should not be used. There are fundamental problems with binding data to classes as part of the normal process of evaluating classes, nodes, and other Puppet objects. These play out in the form of real-world problems for Puppet users. 3. Moreover, I am arguing that the mere existence of parameterized-style class declaration syntax leads people to draw the wrong conclusions about classes -- for example, that it should be possible to override class parameters, which simply cannot work reliably. Perhaps some of the people misled in this way are on the PL staff. It is inescapable, however, that classes are not parallel to ordinary resources (as we have also covered), no matter how much DSL syntax, PL documents, and perhaps even the underlying implementation strive to make them seem so. 4. What I have so far digested of ARM-8 seems very promising for the future direction of binding data to classes. As for present Puppet, data binding via Hiera and / or an ENC do quite well for binding data to class parameters. And of course, Hiera or any other external data access mechanism can be used to bind data to unparameterized classes. ---------------------------------------- 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-96436 * 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.
