Hi @all,
I''ve started rewriting some of my modules to achieve separation of
logic
and data. So I did some standard layout with init.pp and params.pp for
default values and parametrized classes for individual configuration like
this:
class example (
$parameter1 = hiera(''example::parameter1'',
$example::params::parameter1),
$parameter2 = hiera(''example::parameter2'',
$example::params::parameter2))
inherits example::params {
# Some coding
}
I
s this approach generic enough or will a different coding style be a
better approach with more use cases in mind? What do you think, any
suggestions?
Regards Thomas
--
Linux ... enjoy the ride!
--
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.
Strangely enough, I lately started to move my params out of params classes and into the init class. I really prefer to have example::param1 in my hiera instead of the example::params::param1. Will be glad to hear what the params class actually buys you as a pattern. For me the params class makes more sense when you don''t have hiera or ENC in place. I remember using it because it was used as a standard and I found it as a "nice" pattern on the internet. Will be glad to hear more on this one too so +1 -- Nikola On Thu, Apr 04, 2013 at 12:38:47PM +0200, Thomas Bendler wrote:> Hi @all, > > I''ve started rewriting some of my modules to achieve separation of logic > and data. So I did some standard layout with init.pp and params.pp for > default values and parametrized classes for individual configuration like > this: > > class example ( > $parameter1 = hiera(''example::parameter1'', $example::params::parameter1), > $parameter2 = hiera(''example::parameter2'', $example::params::parameter2)) > inherits example::params { > # Some coding > } > > I > s this approach generic enough or will a different coding style be a > better approach with more use cases in mind? What do you think, any > suggestions? > > > Regards Thomas > > -- > Linux ... enjoy the ride! > > -- > 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 Thursday, April 4, 2013 5:38:47 AM UTC-5, thbe wrote:> > Hi @all, > > I''ve started rewriting some of my modules to achieve separation of logic > and data. So I did some standard layout with init.pp and params.pp for > default values and parametrized classes for individual configuration like > this: > > class example ( > $parameter1 = hiera(''example::parameter1'', $example::params::parameter1 > ), > $parameter2 = hiera(''example::parameter2'', $example::params::parameter2 > )) > inherits example::params { > # Some coding > } > > I > s this approach generic enough or will a different coding style be a > better approach with more use cases in mind? What do you think, any > suggestions? > >Code following that template should work equally well in any Puppet from v2.6 onward, provided that hiera is installed. (Hiera is built-in for Puppet 3, but it is a separate add-on to Puppet 2). However, if you are going to go so far as to specify explicit hiera() calls for your default values, then I would recommend you just dump class parameterization altogether, and if you do so then you can also avoid class inheritance (or use it, where needed, for its real purpose): class example { include ''example::params'' $parameter1 = hiera(''example::parameter1'', $example::params::parameter1) $parameter2 = hiera(''example::parameter2'', $example::params::parameter2) # Some coding } That loses you the alternative of expressing class data directly in your class declarations, but doing so is problematic and always has been. As for whether default values should be drawn from a separate class in the first place, that''s partially a question of the usage and meaning of those parameters. If no other class relies on them then I don''t see what is gained by extracting them to a separate class -- as far as I''m concerned, that just obfuscates. And in most cases probably no other class SHOULD rely on those defaults: what they really want is more likely to be $example::parameter1, etc.. And that may itself be a reason to prefer the non-parameterized form if compatibility with Puppet 2 is desired: it is my vague (and possibly wrong) recollection that in some versions of Puppet class parameters could not be accessed from other classes (unlike ordinary class variables). If you don''t care about Puppet 2, on the other hand, then explicit hiera calls for your parameter defaults are overkill, and possibly even redundant. The non-parameterized form, on the other hand, is no better or worse in Puppet 3 than in Puppet 2. 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.
2013/4/4 jcbollinger <John.Bollinger@stjude.org>> [...] > Code following that template should work equally well in any Puppet from > v2.6 onward, provided that hiera is installed. (Hiera is built-in for > Puppet 3, but it is a separate add-on to Puppet 2). > > However, if you are going to go so far as to specify explicit hiera() > calls for your default values, then I would recommend you just dump class > parameterization altogether, and if you do so then you can also avoid class > inheritance (or use it, where needed, for its real purpose): > > class example { > include ''example::params'' > $parameter1 = hiera(''example::parameter1'', $example::params::parameter1) > $parameter2 = hiera(''example::parameter2'', $example::params::parameter2 > ) > # Some coding > } > > That loses you the alternative of expressing class data directly in your > class declarations, but doing so is problematic and always has been. >the idea behind this example was to write a module that could be used with Puppet v2.6 and above and that should be able to run in nearly every environment without modifications. So, if I only look at my infrastructure, we are talking about ENC provided by foreman. But when I rewrite my classes I have the goal to write classes that could work in any other environment as well, regardless if ENC is used or something different. [...]> > If you don''t care about Puppet 2, on the other hand, then explicit hiera > calls for your parameter defaults are overkill, and possibly even > redundant. The non-parameterized form, on the other hand, is no better or > worse in Puppet 3 than in Puppet 2. > [...] >So from this perspective I would tend to drop hiera completely for now and thing about hiera support later on again. So I would simply go for an approach like this: class example ( $parameter1 = $example::params::parameter1, $parameter2 = $example::params::parameter2) inherits example::params { # Some coding } which should give me the maximum of flexibility at this point in time. So predefined values in a separate params class (all configuration at one point) that could be touched directly if necessary or that could be overwritten by an ENC. Are there any mistakes in my thoughts or is it a good and valid approach? Regards Thomas -- Linux ... enjoy the ride! -- 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.