Puppet users - Jan 2012 - params.pp class with parametrized class support?

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!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Look here at how I do this:
https://github.com/example42/puppet-openssh

-- 
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/-/Fw_KNwipuDgJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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




On Jan 18, 1:58 am, Alessandro Franceschi <a...@lab42.it>
wrote:
> Look here at how I do this:https://github.com/example42/puppet-openssh
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

> On Jan 18, 1:58 am, Alessandro Franceschi <a....@lab42.it> wrote: 
> > Look here at how I do this:https://github.com/example42/puppet-openssh
-- 
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/-/CiT-PdyT6TYJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.