Puppet users - Aug 2013 - params pattern when writing modules

So, I''ve been looking into the params pattern for writing modules, ie. 
having a params.pp file that init.pp inherits from as a place to use custom 
logic to set variables, and it seems very useful. I do have one question 
that I''m hoping someone can answer. If, for example, I look at an
example42
module, everything is in params.pp. On the other hand, looking at, say, 
puppetlabs modules, there''s some mixing, with the case statements 
determining variable contents living in params.pp, but with straightforward 
string and boolean values stored between params.pp and the argument list in 
init.pp, with seemingly little logic dictating what goes where.

Basically, what''s people thoughts on the value of having every single 
variable defined in params.pp, vs only the complex, logicky ones, and also, 
in the case that I''m being dense, can someone explain the logic behind
the
puppetlabs modules.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

As one of the two new maintainers of all Puppetlabs modules I can tell you
for sure that our intent is to make sure everything in init.pp inherits out
of params.pp instead of declaring them directly in the main class, and if
you''re kind enough and can throw a github issue up for any cases you
notice
where that''s not true we can fix them.

I never liked the params.pp pattern myself but there''s no great
solution to
"where do I store all my weird logic to make the rest of my classes
simple".  We''re standardizing on keeping all params defined in
params.pp
and inheriting that in init.pp so that they can be overridden.

I can''t claim it''s the best pattern, but we''re at
least going to strive for
consistency.

(For background, each puppetlabs module was written by a different person
with their own views on this stuff and we had no unifying style guide or
guidelines to work from.  We''re working on fixing these, but it takes
time
and we don''t want to barge in rewriting everything and upsetting
current
users).


On Tue, Aug 13, 2013 at 5:32 PM, Ellison Marks <gtyaoi@gmail.com> wrote:
> So, I''ve been looking into the params pattern for writing modules,
ie.
> having a params.pp file that init.pp inherits from as a place to use custom
> logic to set variables, and it seems very useful. I do have one question
> that I''m hoping someone can answer. If, for example, I look at an
example42
> module, everything is in params.pp. On the other hand, looking at, say,
> puppetlabs modules, there''s some mixing, with the case statements
> determining variable contents living in params.pp, but with straightforward
> string and boolean values stored between params.pp and the argument list in
> init.pp, with seemingly little logic dictating what goes where.
>
> Basically, what''s people thoughts on the value of having every
single
> variable defined in params.pp, vs only the complex, logicky ones, and also,
> in the case that I''m being dense, can someone explain the logic
behind the
> puppetlabs modules.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscribe@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/puppet-users.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Ah, good to know. I''ll file some tickets as I come across instances of
this.

On Tuesday, August 13, 2013 2:47:43 PM UTC-7, Ashley Penney
wrote:
>
> As one of the two new maintainers of all Puppetlabs modules I can tell you 
> for sure that our intent is to make sure everything in init.pp inherits out
> of params.pp instead of declaring them directly in the main class, and if 
> you''re kind enough and can throw a github issue up for any cases
you notice
> where that''s not true we can fix them.
>
> I never liked the params.pp pattern myself but there''s no great
solution
> to "where do I store all my weird logic to make the rest of my classes
> simple".  We''re standardizing on keeping all params defined
in params.pp
> and inheriting that in init.pp so that they can be overridden.
>
> I can''t claim it''s the best pattern, but we''re
at least going to strive
> for consistency.
>
> (For background, each puppetlabs module was written by a different person 
> with their own views on this stuff and we had no unifying style guide or 
> guidelines to work from.  We''re working on fixing these, but it
takes time
> and we don''t want to barge in rewriting everything and upsetting
current
> users).
>
>
> On Tue, Aug 13, 2013 at 5:32 PM, Ellison Marks
<gty...@gmail.com<javascript:>
> > wrote:
>
>> So, I''ve been looking into the params pattern for writing
modules, ie.
>> having a params.pp file that init.pp inherits from as a place to use
custom
>> logic to set variables, and it seems very useful. I do have one
question
>> that I''m hoping someone can answer. If, for example, I look at
an example42
>> module, everything is in params.pp. On the other hand, looking at, say,
>> puppetlabs modules, there''s some mixing, with the case
statements
>> determining variable contents living in params.pp, but with
straightforward
>> string and boolean values stored between params.pp and the argument
list in
>> init.pp, with seemingly little logic dictating what goes where.
>>
>> Basically, what''s people thoughts on the value of having every
single
>> variable defined in params.pp, vs only the complex, logicky ones, and
also,
>> in the case that I''m being dense, can someone explain the
logic behind the
>> puppetlabs modules.
>>  
>> -- 
>> You received this message because you are subscribed to the Google
Groups
>> "Puppet Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send
an
>> email to puppet-users...@googlegroups.com <javascript:>.
>> To post to this group, send email to
puppet...@googlegroups.com<javascript:>
>> .
>> Visit this group at http://groups.google.com/group/puppet-users.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>  
>>  
>>
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

A small note on params.pp, even if I''ve largely used it in the
Example42
modules there are cases where it''s totally uneffective, for example
when
you''ve to define there a parameters whose value may change according to
another parameter the user may pass to init.pp

An example is here:
https://github.com/example42/puppet-logstash/blob/master/manifests/init.pp#L439
or even worse here:
https://github.com/example42/puppet-elasticsearch/blob/master/manifests/init.pp#L399
where some parameters change according to the installation method and I 
found myself placing horrible static references in init.pp

I still haven''t found an elegant way to manage cases like this but,
working
with different modules scenarios I''m more and more convinced that
different
design patterns should be used according to the kind of module you''re
doing
and the kind of options you want to throw in (for the above examples all 
the extra complexity is due to the option to have the possibility to choose 
how to install the application (via a package, downloading the upstream 
tarball ...).

my2c
al


On Wednesday, August 14, 2013 1:08:28 AM UTC+2, Ellison Marks
wrote:
>
> Ah, good to know. I''ll file some tickets as I come across
instances of
> this.
>
> On Tuesday, August 13, 2013 2:47:43 PM UTC-7, Ashley Penney wrote:
>>
>> As one of the two new maintainers of all Puppetlabs modules I can tell 
>> you for sure that our intent is to make sure everything in init.pp
inherits
>> out of params.pp instead of declaring them directly in the main class,
and
>> if you''re kind enough and can throw a github issue up for any
cases you
>> notice where that''s not true we can fix them.
>>
>> I never liked the params.pp pattern myself but there''s no
great solution
>> to "where do I store all my weird logic to make the rest of my
classes
>> simple".  We''re standardizing on keeping all params
defined in params.pp
>> and inheriting that in init.pp so that they can be overridden.
>>
>> I can''t claim it''s the best pattern, but
we''re at least going to strive
>> for consistency.
>>
>> (For background, each puppetlabs module was written by a different
person
>> with their own views on this stuff and we had no unifying style guide
or
>> guidelines to work from.  We''re working on fixing these, but
it takes time
>> and we don''t want to barge in rewriting everything and
upsetting current
>> users).
>>
>>
>> On Tue, Aug 13, 2013 at 5:32 PM, Ellison Marks <gty...@gmail.com>
wrote:
>>
>>> So, I''ve been looking into the params pattern for writing
modules, ie.
>>> having a params.pp file that init.pp inherits from as a place to
use custom
>>> logic to set variables, and it seems very useful. I do have one
question
>>> that I''m hoping someone can answer. If, for example, I
look at an example42
>>> module, everything is in params.pp. On the other hand, looking at,
say,
>>> puppetlabs modules, there''s some mixing, with the case
statements
>>> determining variable contents living in params.pp, but with
straightforward
>>> string and boolean values stored between params.pp and the argument
list in
>>> init.pp, with seemingly little logic dictating what goes where.
>>>
>>> Basically, what''s people thoughts on the value of having
every single
>>> variable defined in params.pp, vs only the complex, logicky ones,
and also,
>>> in the case that I''m being dense, can someone explain the
logic behind the
>>> puppetlabs modules.
>>>  
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Puppet Users" group.
>>> To unsubscribe from this group and stop receiving emails from it,
send
>>> an email to puppet-users...@googlegroups.com.
>>> To post to this group, send email to puppet...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/puppet-users.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>
>>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.