FAQ
I've been having to write (and modify) a lot of modules lately, and I've so
far moved to the following pattern. I'd appreciate comments and feedback
about my approach, particularly in light of the changes to name scoping
(all my modules are currently deployed under 2.7).


    1. mod::defaults (defaults.pp)
       - does *not* inherit from anywhere
       - 'include mod::settings'
       - references module variables with $mod::settings::varname
    2. mod::base (base.pp)
       - 'inherits mod::defaults'
       - 'include mod'
       - 'include mod::settings'
       - any other things which apply to all classes in the module
       3. mod::settings (settings.pp)
       - does *not* inherit from anywhere
       - has responsibility for resolving and normalising any global or
       mod() class variables into sane values
       4. mod (init.pp)
       - 'inherits mod::defaults'
       - 'include mod::settings'
       - imports all $mod::settings::<varname> definitions into the $mod
       namespace
       - if it's a multi-function module (*i.e.*, classes may be selectively
       called out for use), this is all it does.
       - if it's a single-purpose module, the rest of its work can go here
       -- or in other classes it includes
    5. all other classes
       1. 'inherits mod::defaults'
       2. 'include mod::base'
       3. does whatever else it's suppposed to do.

The ideas I'm working from are to abstract all the parameter selectors and
such into one class, resource declaration defaults into another, and the
module top-level namespace and every-class-needs-this stuff into a third.
Does this make sense, or is it completely lame? Or are there better
patterns (that don't require hiera nor puppetdb) I should consider?

Thanks!

--
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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Gerardo Santana Gómez Garrido at May 6, 2013 at 7:36 pm
    Hi Ken,

    I'm not sure I fully understood the purpose of each class, and until then
    I'm not pointing out issues. But if my interpretation is correct then you
    may get something useful from this other pattern:

    # it's probaby your mod::defaults and mod::settings together
    class mod::params {
       $setting1 = 1
       $setting2 = 'a'
    }

    # entry point
    class mod(
       $setting1 = $mod::params::setting1,
       $setting2 = $mod::params::setting2
    ) {
       class {'mod::install': } ->
       class {'mod::config':} ~>
       class {'mod::service':} ->
       Class['mod']
    }

    # the classes below reference parameters
    # as $mod::setting1
    class mod::install {
    }

    class mod::config {
    }

    class mod::service {
    }

    this can be expanded to more than one entry point.

    Hope that helps.

    El lunes, 6 de mayo de 2013 12:25:30 UTC-5, Ken Coar escribió:
    I've been having to write (and modify) a lot of modules lately, and I've
    so far moved to the following pattern. I'd appreciate comments and
    feedback about my approach, particularly in light of the changes to name
    scoping (all my modules are currently deployed under 2.7).


    1. mod::defaults (defaults.pp)
    - does *not* inherit from anywhere
    - 'include mod::settings'
    - references module variables with $mod::settings::varname
    2. mod::base (base.pp)
    - 'inherits mod::defaults'
    - 'include mod'
    - 'include mod::settings'
    - any other things which apply to all classes in the module
    3. mod::settings (settings.pp)
    - does *not* inherit from anywhere
    - has responsibility for resolving and normalising any global or
    mod() class variables into sane values
    4. mod (init.pp)
    - 'inherits mod::defaults'
    - 'include mod::settings'
    - imports all $mod::settings::<varname> definitions into the $mod
    namespace
    - if it's a multi-function module (*i.e.*, classes may be
    selectively called out for use), this is all it does.
    - if it's a single-purpose module, the rest of its work can go here
    -- or in other classes it includes
    5. all other classes
    1. 'inherits mod::defaults'
    2. 'include mod::base'
    3. does whatever else it's suppposed to do.

    The ideas I'm working from are to abstract all the parameter selectors and
    such into one class, resource declaration defaults into another, and the
    module top-level namespace and every-class-needs-this stuff into a third.
    Does this make sense, or is it completely lame? Or are there better
    patterns (that don't require hiera nor puppetdb) I should consider?

    Thanks!
    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ken Coar at May 7, 2013 at 3:42 pm

    On Monday, May 6, 2013 3:36:06 PM UTC-4, Gerardo Santana Gómez Garrido wrote:

    Hi Ken,

    I'm not sure I fully understood the purpose of each class, and until then
    I'm not pointing out issues. But if my interpretation is correct then you
    may get something useful from this other pattern:

    # it's probaby your mod::defaults and mod::settings together
    class mod::params {
    $setting1 = 1
    $setting2 = 'a'
    }

    # entry point
    class mod(
    $setting1 = $mod::params::setting1,
    $setting2 = $mod::params::setting2
    ) {
    class {'mod::install': } ->
    class {'mod::config':} ~>
    class {'mod::service':} ->
    Class['mod']
    }

    # the classes below reference parameters
    # as $mod::setting1
    class mod::install {
    }

    class mod::config {
    }

    class mod::service {
    }

    this can be expanded to more than one entry point.
    Hmm. That seems.. confusing.. to me, probably because I'm a
    beginning-to-intermediate user. I'm not even sure what the hell is going
    on, in fact. :-)

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Gerardo Santana Gómez Garrido at May 7, 2013 at 4:13 pm
    Find a better explanation here:
    http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php

    El martes, 7 de mayo de 2013 10:42:47 UTC-5, Ken Coar escribió:


    On Monday, May 6, 2013 3:36:06 PM UTC-4, Gerardo Santana Gómez Garrido
    wrote:
    Hi Ken,

    I'm not sure I fully understood the purpose of each class, and until then
    I'm not pointing out issues. But if my interpretation is correct then you
    may get something useful from this other pattern:

    # it's probaby your mod::defaults and mod::settings together
    class mod::params {
    $setting1 = 1
    $setting2 = 'a'
    }

    # entry point
    class mod(
    $setting1 = $mod::params::setting1,
    $setting2 = $mod::params::setting2
    ) {
    class {'mod::install': } ->
    class {'mod::config':} ~>
    class {'mod::service':} ->
    Class['mod']
    }

    # the classes below reference parameters
    # as $mod::setting1
    class mod::install {
    }

    class mod::config {
    }

    class mod::service {
    }

    this can be expanded to more than one entry point.
    Hmm. That seems.. confusing.. to me, probably because I'm a
    beginning-to-intermediate user. I'm not even sure what the hell is going
    on, in fact. :-)
    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan White at May 7, 2013 at 1:22 am
    This looks great.
    Some constructive criticism:

    I think “defaults" and “settings” are redundant.
    Use one.
    I kind of like the term “params”, but they all do the same thing.
    On May 6, 2013, at 1:25 PM, Ken Coar wrote:

    I've been having to write (and modify) a lot of modules lately, and I've so far moved to the following pattern. I'd appreciate comments and feedback about my approach, particularly in light of the changes to name scoping (all my modules are currently deployed under 2.7).

    mod::defaults (defaults.pp)
    does not inherit from anywhere
    'include mod::settings'
    references module variables with $mod::settings::varname
    mod::base (base.pp)
    'inherits mod::defaults'
    'include mod'
    'include mod::settings'
    any other things which apply to all classes in the module
    mod::settings (settings.pp)
    does not inherit from anywhere
    has responsibility for resolving and normalising any global or mod() class variables into sane values
    mod (init.pp)
    'inherits mod::defaults'
    'include mod::settings'
    imports all $mod::settings::<varname> definitions into the $mod namespace
    if it's a multi-function module (i.e., classes may be selectively called out for use), this is all it does.
    if it's a single-purpose module, the rest of its work can go here -- or in other classes it includes
    all other classes
    'inherits mod::defaults'
    'include mod::base'
    does whatever else it's suppposed to do.
    The ideas I'm working from are to abstract all the parameter selectors and such into one class, resource declaration defaults into another, and the module top-level namespace and every-class-needs-this stuff into a third.
    Does this make sense, or is it completely lame? Or are there better patterns (that don't require hiera nor puppetdb) I should consider?

    Thanks!

    --
    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?hl=en.
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Wolf Noble at May 7, 2013 at 4:02 am
    Hi Ken,

    I'm happy to give my $.02, FWIW.

    I've found immense benefit from the overall paradigm described in Craig
    Dunn's blog post here:
    http://www.craigdunn.org/2012/05/239/

    That paradigm, combined with modules which have all of their variables
    placed as module::variable_name parameters which default to
    module::params::variable_name allows for much flexibility:

    - easy unit test creation. (avoiding trying to get hiera to work with unit
    tests made this incredibly attractive to us)

    - clear delineation between 'do-stuff' modules and 'implementation of the
    do-stuff module in my environment' profiles.

    This makes the 'do-stuff' modules more re-usable and generally communally
    consumable, as there are as few as possible environment-specific bits in
    the 'do-stuff' modules.

    Depending on the environment, this can also serve as a line in the sand as
    to which modules can be shared with the world and which contain secret
    sauce.


    This also has the added benefit of creating tiers of complication.
    You can allow your more junior people to orchestrate role modules onto
    servers, and provision servers.
    You can have your intermediate admins write, or improve profile modules.
    A select few can work on your do-stuff modules and help fill out other
    needs as they arise.

    This, again, is just my $.02. I'm sure there are many others whose opinions
    are equally as interesting and may contain more relevant suggestions for
    your specific implementation.




    On Mon, May 6, 2013 at 8:22 PM, Dan White wrote:

    This looks great.
    Some constructive criticism:

    I think “defaults" and “settings” are redundant.
    Use one.
    I kind of like the term “params”, but they all do the same thing.

    On May 6, 2013, at 1:25 PM, Ken Coar wrote:

    I've been having to write (and modify) a lot of modules lately, and I've
    so far moved to the following pattern. I'd appreciate comments and
    feedback about my approach, particularly in light of the changes to name
    scoping (all my modules are currently deployed under 2.7).


    1. mod::defaults (defaults.pp)
    - does *not* inherit from anywhere
    - 'include mod::settings'
    - references module variables with $mod::settings::varname
    2. mod::base (base.pp)
    - 'inherits mod::defaults'
    - 'include mod'
    - 'include mod::settings'
    - any other things which apply to all classes in the module
    3. mod::settings (settings.pp)
    - does *not* inherit from anywhere
    - has responsibility for resolving and normalising any global or
    mod() class variables into sane values
    4. mod (init.pp)
    - 'inherits mod::defaults'
    - 'include mod::settings'
    - imports all $mod::settings::<varname> definitions into the $mod
    namespace
    - if it's a multi-function module (*i.e.*, classes may be
    selectively called out for use), this is all it does.
    - if it's a single-purpose module, the rest of its work can go here
    -- or in other classes it includes
    5. all other classes
    1. 'inherits mod::defaults'
    2. 'include mod::base'
    3. does whatever else it's suppposed to do.

    The ideas I'm working from are to abstract all the parameter selectors and
    such into one class, resource declaration defaults into another, and the
    module top-level namespace and every-class-needs-this stuff into a third.
    Does this make sense, or is it completely lame? Or are there better
    patterns (that don't require hiera nor puppetdb) I should consider?

    Thanks!

    --
    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?hl=en.
    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?hl=en.
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ken Coar at May 7, 2013 at 3:49 pm

    On Tuesday, May 7, 2013 12:02:11 AM UTC-4, Wolf Noble wrote:
    I'm happy to give my $.02, FWIW.

    I've found immense benefit from the overall paradigm described in Craig
    Dunn's blog post here:
    http://www.craigdunn.org/2012/05/239/
    I'll check it out in light of your comments. Thanks!

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ken Coar at May 7, 2013 at 3:48 pm

    On Monday, May 6, 2013 9:22:36 PM UTC-4, Ygor wrote:
    This looks great.
    Mine, or Gerardo's?

    Some constructive criticism:
    I think “defaults" and “settings” are redundant.
    Use one.
    Actually, though, IMHO they're not. 'Defaults' are what you get if they
    aren't overridden. 'Settings' are what you use in the main code; they
    might be the default values, or they might be explicitly overridden/set.

    I kind of like the term “params”, but they all do the same thing.
    >

    'params' *versus* 'settings'.. yah, could go either way. Except I
    personally think of 'params' as things that are explicitly passed in to
    something, and 'settings' being more in the environment.

    Thanks for the feedback!

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at May 7, 2013 at 2:25 pm

    On Monday, May 6, 2013 12:25:30 PM UTC-5, Ken Coar wrote:
    I've been having to write (and modify) a lot of modules lately, and I've
    so far moved to the following pattern. I'd appreciate comments and
    feedback about my approach, particularly in light of the changes to name
    scoping (all my modules are currently deployed under 2.7).


    I think there's a great advantage to using a consistent module structure,
    whatever that happens to be. Of course, some structures are more helpful
    than others. I'm still trying to wrap my head around the particulars you
    present, but I'll see what I can come up with.


    1. mod::defaults (defaults.pp)
    - does *not* inherit from anywhere
    - 'include mod::settings'
    - references module variables with $mod::settings::varname
    2. mod::base (base.pp)
    - 'inherits mod::defaults'
    - 'include mod'
    - 'include mod::settings'
    - any other things which apply to all classes in the module
    3. mod::settings (settings.pp)
    - does *not* inherit from anywhere
    - has responsibility for resolving and normalising any global or
    mod() class variables into sane values
    4. mod (init.pp)
    - 'inherits mod::defaults'
    - 'include mod::settings'
    - imports all $mod::settings::<varname> definitions into the $mod
    namespace
    - if it's a multi-function module (*i.e.*, classes may be
    selectively called out for use), this is all it does.
    - if it's a single-purpose module, the rest of its work can go here
    -- or in other classes it includes
    5. all other classes
    1. 'inherits mod::defaults'
    2. 'include mod::base'
    3. does whatever else it's suppposed to do.

    The ideas I'm working from are to abstract all the parameter selectors and
    such into one class,

    Not to be dense, but that class is mod::settings?


    resource declaration defaults into another,

    And that one is mod::defaults?


    and the module top-level namespace and every-class-needs-this stuff into a
    third.

    And mod::base? Or is this mod?


    Does this make sense, or is it completely lame? Or are there better
    patterns (that don't require hiera nor puppetdb) I should consider?
    That resource defaults are so important to you that you make special
    provision for them in your standard module structure seems a bit
    questionable to me. Given reliance on module-wide resource defaults, I
    guess having classes inherit those from a parent class is a decent
    approach, but I would advise you to avoid defaults as much as possible in
    the first place. If you do so then few, if any, modules should need
    classes for resource defaults.

    Which, if any, of these classes are parameterized? Not mod::defaults, I
    presume, because parameterized base classes are not supported (though they
    don't automatically fail). Are any of the others allowed to be
    parameterized? This makes a great difference to the analysis.

    If class 'mod' is going to declare any other classes of the module, then
    those particular classes cannot follow your "all other classes" pattern.
    Otherwise, you would have a parse-order dependency loop: mod::other ==> mod
    ==> mod::base ==> mod::other. If catalog compilation nevertheless
    succeeds, you probably will not get the results you expect. I think that
    pattern is suitable only for external-facing classes of a "multi-function"
    module.

    Class mod::base is confusingly named. It undoubtedly makes sense to you,
    but to me it strongly suggests a base class for class inheritance. If your
    module structure needs to be easy for anyone other than you to grasp, now
    or in the foreseeable future, then I recommend choosing a different name.

    Or possibly, just dispense with class mod::base altogether. I'm not sure
    what the "any other things" that it provides for might tend to be, but I'm
    guessing little, if anything. And what there is could be moved to class
    'mod' without disturbing your scheme, since mod::base includes mod. That
    leaves just

        - inheriting mod::defaults, which does not help other classes because
        they inherit mod::defaults themselves
        - including class 'mod', which is a possible problem in some modules, as
        discussed above
        - including mod::settings, which is not harmful, but also not useful,
        because parent class mod::defaults also includes mod::settings.

    Thus, I'd either remove class mod::base, or restructure its pattern. If
    you make class mod include mod::base instead of the other way around, then
    perhaps mod::base could have a role in keeping the pattern consistent
    between single-function and multi-function modules. Even then, however,
    I'm not seeing much advantage.

    I think it might help to re-cast your pattern categories. In particular,
    "all other classes" is probably too broad a category, and class 'mod' may
    not deserve to be in a category by itself. It might be to your advantage
    to draw the line between outward-facing classes and other classes, instead.


    John

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ken Coar at May 7, 2013 at 4:12 pm

    On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote:
    I think there's a great advantage to using a consistent module structure,
    whatever that happens to be.

    D'accord! Hence this attempt.
    1. mod::defaults (defaults.pp)
    - does *not* inherit from anywhere
    - 'include mod::settings'
    - references module variables with $mod::settings::varname
    2. mod::base (base.pp)
    - 'inherits mod::defaults'
    - 'include mod'
    - 'include mod::settings'
    - any other things which apply to all classes in the module
    3. mod::settings (settings.pp)
    - does *not* inherit from anywhere
    - has responsibility for resolving and normalising any global or
    mod() class variables into sane values
    4. mod (init.pp)
    - 'inherits mod::defaults'
    - 'include mod::settings'
    - imports all $mod::settings::<varname> definitions into the $mod
    namespace
    - if it's a multi-function module (*i.e.*, classes may be
    selectively called out for use), this is all it does.
    - if it's a single-purpose module, the rest of its work can go
    here -- or in other classes it includes
    5. all other classes
    1. 'inherits mod::defaults'
    2. 'include mod::base'
    3. does whatever else it's suppposed to do.

    The ideas I'm working from are to abstract all the parameter selectors
    and such into one class,

    Not to be dense, but that class is mod::settings?
    Correct.

    resource declaration defaults into another,
    And that one is mod::defaults?
    Correct.

    and the module top-level namespace and every-class-needs-this stuff into a
    third.
    And mod::base? Or is this mod?
    A combination. The namespacing is both (since mod::base includes mod), and
    the 'common stuff' is mod::base.

    That resource defaults are so important to you that you make special
    provision for them in your standard module structure seems a bit
    questionable to me.
    I understand. However, there are some significantly involved resource
    declarations that only change a few parameters (if any) in other classes --
    but to retain the defaults means using 'inherits'. (I first started
    messing about with 'inherits' to get the variables from mod::settings
    imported into the top -- and each class local -- namespace, but I was shown
    some problems there.

    Which, if any, of these classes are parameterized? Not mod::defaults, I
    presume, because parameterized base classes are not supported (though they
    don't automatically fail). Are any of the others allowed to be
    parameterized? This makes a great difference to the analysis.
    In the current iteration, only mod might be parameterised -- and it usually
    isn't. Hence all sorts of selectors in mod::settings to derive operating
    values from the global scope (node manifest, facts), defaults, and possibly
    parameters to mod if they're supported.

    Moving from global parameters in the node manifests to parameterised
    classes is in the plan.

    If class 'mod' is going to declare any other classes of the module, then
    those particular classes cannot follow your "all other classes" pattern.
    I don't do any class-defines-other-classes stuff. I prefer (because I
    understand and hence am more comfortable with) one class *per* file.

    Class mod::base is confusingly named. It undoubtedly makes sense to you,
    but to me it strongly suggests a base class for class inheritance. If your
    module structure needs to be easy for anyone other than you to grasp, now
    or in the foreseeable future, then I recommend choosing a different name.
    Good point.

    Or possibly, just dispense with class mod::base altogether. I'm not sure
    what the "any other things" that it provides for might tend to be, but I'm
    guessing little, if anything. And what there is could be moved to class
    'mod' without disturbing your scheme, since mod::base includes mod.
    Not exactly; other modules might need settings from module mod. Explicitly
    including it or letting it be autoloaded will get the settings without any
    side-effect actions being taken.

    That leaves just

    - inheriting mod::defaults, which does not help other classes because
    they inherit mod::defaults themselves
    - including class 'mod', which is a possible problem in some modules,
    as discussed above
    - including mod::settings, which is not harmful, but also not useful,
    because parent class mod::defaults also includes mod::settings.

    mod::defaults includes mod::settings so that aspects of the resource
    defaults can be overridden by values determined by mod::settings. That's
    the only reason.

    I think it might help to re-cast your pattern categories. In particular,
    "all other classes" is probably too broad a category, and class 'mod' may
    not deserve to be in a category by itself. It might be to your advantage
    to draw the line between outward-facing classes and other classes, instead.
    Thanks, I'll ruminate on that.

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at May 7, 2013 at 7:59 pm

    On Tuesday, May 7, 2013 11:05:55 AM UTC-5, Ken Coar wrote:
    On Tuesday, May 7, 2013 10:25:05 AM UTC-4, jcbollinger wrote:

    If class 'mod' is going to declare any other classes of the module, then
    those particular classes cannot follow your "all other classes" pattern.
    I don't do any class-defines-other-classes stuff. I prefer (because I
    understand and hence am more comfortable with) one class *per* file.

    I commend you on that approach, but it's not what I was talking about. To
    "declare" a class is to use the 'include' function, the 'require' function,
    or a paramterized-style class declaration to assign it to the target node.
    This is something you say class 'mod' may do in a single-function module,
    but you cannot rely on it to work correctly if the declared (included)
    class follows your "all other classes" pattern.


    Class mod::base is confusingly named. It undoubtedly makes sense to you,
    but to me it strongly suggests a base class for class inheritance. If your
    module structure needs to be easy for anyone other than you to grasp, now
    or in the foreseeable future, then I recommend choosing a different name.
    Good point.

    Or possibly, just dispense with class mod::base altogether. I'm not sure
    what the "any other things" that it provides for might tend to be, but I'm
    guessing little, if anything. And what there is could be moved to class
    'mod' without disturbing your scheme, since mod::base includes mod.
    Not exactly; other modules might need settings from module mod.
    Explicitly including it or letting it be autoloaded will get the settings
    without any side-effect actions being taken.

    Ok, though that's only relevant to multi-function modules. I do think you
    may be overengineering this a bit. My gut feeling is that you have at
    least one class too many in your model framework.


    That leaves just

    - inheriting mod::defaults, which does not help other classes because
    they inherit mod::defaults themselves
    - including class 'mod', which is a possible problem in some modules,
    as discussed above
    - including mod::settings, which is not harmful, but also not useful,
    because parent class mod::defaults also includes mod::settings.

    mod::defaults includes mod::settings so that aspects of the resource
    defaults can be overridden by values determined by mod::settings. That's
    the only reason.

    So I guessed. I'm not saying mod:defaults should not include
    mod::settings, nor either that mod::base should not do so. I am merely
    saying that that aspect of mod::base does nothing to help other classes
    that themselves inherit from mod::defaults and include mod::base, according
    to the pattern you set out. Overall, my point is that mod::base isn't
    really doing much for you at all.


    Cheers,

    John

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at May 7, 2013 at 10:12 pm

    On Tuesday, May 7, 2013 11:05:55 AM UTC-5, Ken Coar wrote:
    [...]
    In the current iteration, only mod might be parameterised -- and it
    usually isn't. Hence all sorts of selectors in mod::settings to derive
    operating values from the global scope (node manifest, facts), defaults,
    and possibly parameters to mod if they're supported.

    Moving from global parameters in the node manifests to parameterised
    classes is in the plan.

    [...]
    Or possibly, just dispense with class mod::base altogether. I'm not sure
    what the "any other things" that it provides for might tend to be, but I'm
    guessing little, if anything. And what there is could be moved to class
    'mod' without disturbing your scheme, since mod::base includes mod.
    Not exactly; other modules might need settings from module mod.
    Explicitly including it or letting it be autoloaded will get the settings
    without any side-effect actions being taken.

    Considering this area further, I don't think that use is feasible if class
    mod is parameterized, as some of yours already are, and as you say more
    eventually will be. One module cannot then safely reference class mod
    without either assuming that it has already been declared (with correct
    parameters) or assuming that it must be declared (in which case the needed
    parameters must be provided). Neither assumption is safe in general unless
    you put in a lot of work to make it so.

    That's more an indictment of the state of parameterized classes in Puppet
    2.7 than of your architecture, but you should nevertheless take it into
    account as you plan how your modules will be structured.


    John

    --
    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?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedMay 6, '13 at 5:25p
activeMay 7, '13 at 10:12p
posts12
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase