On Sunday, October 21, 2012 6:02:39 PM UTC-5, Guzmán Brasó wrote:
>
> John,
>
> I'm new to puppet and your mails confuse me a little bit... if
> parameterized classes are not recommended and you suggest when dealing with
> someone else parameterized class to set it through hiera (Puppet 3).
> Then I don't understand how to proceed with puppet 2 modules...
>
Here are some of your better choices, none of them especially good:
1. Upgrade your master to Puppet 3. The clients can stay at 2.7 if you
wish.
2. Avoid third-party modules whose interfaces involve parametrized
classes, unless they have built-in hiera support.
3. Be very careful and deliberate with the placement of your
parametrized-style class declarations, and expect to troubleshoot parse
order issues from time to time.
>
> Should I hack every module I need to set the defaults inside the module?
>
That's an option too, but I wouldn't recommend it.
>
> And if making a module, without using parameters, how I can reuse the
> module with different defaults ? Should I create a different params.pp for
> each scenario I need and then include it inheriting each one of the
> defaults, this would be a mess to deal with large arquitectures with many
> different types of nodes.
>
That is what hiera is for. Although not integrated into the core until
Puppet 3, hiera is a widely-used add-on to Puppet 2. Instead of
class mymodule::foo (
$param1 = 'default1',
$param2 = 'default2' ) {
# declarations
}
I recommend some variation on
class mymodule::foo {
$param1 = hiera('foo::param1', 'default1')
$param2 = hiera('foo::param2', 'default2')
# declarations
}
Then put any needed 'parameter' customizations into your hiera data. That
way not only can you avoid parametrized-style class declarations, but you
also achieve separation of your data from your code.
>
> I'm sorry to ask but since we started using puppet (a few months ago) we
> started doing everything with parameters as puppet docs said on
> http://docs.puppetlabs.com/guides/parameterized_classes.html and since
> then we had no issue (yet) with it. And now you say that parameters are a
> sickness and should not be used. Then how on Puppet 2? And why it's still
> puppet docs still recommending it?
>
>
Puppetlabs heavily promoted parametrized classes starting with their
release as part of Puppet 2.6. Evidently, they perceived and continue to
perceive substantial demand for such a feature. That doesn't mean it was
ever a good idea.
Having promoted the feature so effectively puts PuppetLabs in a difficult
position. At least some of their people will acknowledge the problems with
parametrized classes, at least in Puppet 2.x. I can only speculate about
company policy here, but it would be reasonable for PL to judge that doing
an about-face on parametrized classes could present credibility and trust
issues for the company.
PL put a lot of effort into improving parametrized classes for Puppet 3,
and they are indeed better. As I have lately written, I think the result
rescues a lot of parametrized classes that are already in use. That
doesn't mean that it's a good idea to write new parametrized classes even
for Puppet 3, however.
And of course, a lot of people are using parametrized classes
successfully. My argument has never been that they don't work, only that
they exact unneeded costs in productivity and stability relative to the
best available alternative. Those costs will scale with the number of
dependencies between classes.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/r53hq-Tk8CsJ.
To post to this group, send email to puppet-users@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.
