params.pp class with parametrized class support?

[Ryan Bowlby]

If I wanted to allow all the variables normally set within params.pp
to also be assigned as class parameters or as global variables how
would I do this?

I still want all the variables to be initially set to defaults within
the params.pp class but allow for them to be overridden at the node
level. Does this make sense? Anyone have examples? Thanks!

[Alessandro Franceschi]

Look here at how I do this:

https://github.com/example42/puppet-openssh

[Ryan Bowlby]

Show off! ;) Great example thanks.

I noticed you fully qualify variables within the very class they were
assigned. Is that best practice now?

I've created a simple apache module using your openssh module as
inspiration. I still need to modify params.pp to check for globally
defined vars. In the current incarnation it optionally installs the
mod_ssl package if the "apache:ssl" class is declared (which inherits
the apache class).

Would you recommend doing optional packages as sub classes? Does it
make more sense to install optional packages based on class
parameters?

https://github.com/rbowlby/apache

[Alessandro Franceschi]

On Wednesday, January 18, 2012 12:01:42 PM UTC+1, Ryan Bowlby wrote:

Show off! ;) Great example thanks.

I noticed you fully qualify variables within the very class they were
assigned. Is that best practice now?

Erm, dunno :-D

Still haven't understood what's best practice in Puppet world.

I think is somehow relative to Puppet version and personal approach to things.

In any case generally speaking I'd recommend to use fully qualified variables. 

I've created a simple apache module using your openssh module as
inspiration. I still need to modify params.pp to check for globally
defined vars. In the current incarnation it optionally installs the
mod_ssl package if the "apache:ssl" class is declared (which inherits
the apache class).

 

 

Would you recommend doing optional packages as sub classes? Does it
make more sense to install optional packages based on class
parameters?

Really, this is a matter of personal taste.

I'm going towards and approach with "rich" class parameters, so I probably would add the ssl stuff via a parameter to enable whe calling the apache class.

As a side note I noticed (not surprisingly) that when you have plenty of resources and classes compilation and reporting times grow and this is a problem on some scales, that's why in my new modules I'm trying to reduce the number of subclasses.

But, well, 2 years ago I was doing the opposite... 

Sorry for lack of definitive answers but I'm still exploring and trying to find out if the approach I use is usable and fitting for others.

my2c

al

[jcbollinger]

On Jan 18, 5:01 am, Ryan Bowlby <rbowlb...@gmail.com> wrote:

> I noticed you fully qualify variables within the very class they were
> assigned. Is that best practice now?

Not that I am aware. If you want to adopt that as a local convention,
however, I don't think it's contrary to best practices either.

Personally, I think it's convenient and more readable to refer to
local variables via their unqualified names, and it emphasizes that
they are indeed local. When dynamic scoping goes away in Telly,
Puppet in fact will enforce that unqualified names are local.

On the other hand, referring to variables only via their fully-
qualified variables makes it easier to cut & paste code between
classes, and it explicitly avoids dynamic scoping in Puppet 2.7.x and
earlier.

Adherents of each approach would probably identify additional
advantages.


John