FAQ
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.

Search Discussions

  • Ashley Penney at Aug 13, 2013 at 9:47 pm
    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 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.
  • Ellison Marks at Aug 13, 2013 at 11:08 pm
    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.
  • Alessandro Franceschi at Aug 14, 2013 at 8:34 am
    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 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedAug 13, '13 at 9:32p
activeAug 14, '13 at 8:34a
posts4
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase