On Fri, Jan 7, 2011 at 3:26 AM, R.I.Pienaar <r...@devco.net> wrote: > > > ----- Original Message ----- >> On Thu, Jan 6, 2011 at 2:19 PM, R.I.Pienaar < r...@devco.net > wrote: >> >> >>> imho the right solution is a combination of the require and include >>> keywords,resources requiring classes used extremely sparingly and the new >>> syntax as Danpointed out. >>> >>> What worries me greatly is that 'use parametrized classes' for >>> everything >>> recommendation seems to be the default response these days from PL >>> even to the >>> point of suggesting the include and require keywords be removed and >>> deprecated >>> while the alternatives are, to be frank, half baked. >> >> >> >> We have some serious language issues with the combination of >> "include/require" being able to repeatedly operate on a class, and the >> new parameterized syntax only letting you operate on a class once. >> >> >> I'm not convinced what the right answer is yet. This is why the >> following bug is still in the "Needs Design Decision" stage. >> >> >> http://projects.puppetlabs.com/issues/5046 >> >> >> It's possible we just made a mistake with parameterized classes as >> implemented in 2.6.x. We do need to get to somewhere *consistent*, I'm >> just not quite sure what that place looks like yet. >> > > > Then I am doubly perplexed. It's not a surprise that the feature isn't > adequate perhaps even mistake has been made. > > Being that it is not done or fixed in stone you're almost guaranteed > that its behavior, implications, perhaps even the syntax will change in future > versions. And not just superficially either, its far from workable.
That's been true of lots of new features though RI, and it hasn't stopped them being useful for people, achieving actual work, and eventually moving to a stable place without causing significant user pain. Environments were definitely like this and we haven't caused significant pain as we improved them. > Does it serve the users that we are recommending they use such a feature? > Do we not almost guarantee costly from a time and effort and risk basis > that using this feature will result in a very difficult migration to a future > version of puppet? Hang on. You're making a whole bunch of logical leaps here that I don't believe are justified at all. People have been clamoring for some way to pass parameters to classes as you declare them for a long time, at least since the early days of 0.24.x and almost certainly earlier. There's a reason why this was merged into the code base. Right now I think we have some issues due to the inconsistency between include/require and the new declaration syntax, and all I said was that I want us to get to a consistent place, and maybe we made a misstep in our initial implementation. "our" there refers to all of us in the community, not just Puppet Labs people. Given the number of bugs I've seen you file or comment about this area, I can't believe you disagree with this. I don't see how you jump from our current situation to the idea that future user pain is guaranteed when we haven't all decided how to resolve these problems. > It's loose loose, the users loose since the Lynchpin of their production > systems - configuration management - is a ever moving target requiring heavy > refactors between versions. The community who support the opensource users > loose because it's ever more complex to support the number of puppet versions > out there - they all behave differently. That's a logical consequence of adding features. Didn't I state earlier that consistency was a primary goal though? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
