Puppet users - May 2013 - Feedback on module pattern?

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.

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.

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.

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 <ygor@comcast.net> 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.

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.

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.

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.

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.

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.

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.

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.

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.