Here:
http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php
it explains that "modules that have configuration should be configurable in
a single way and single place",
and I agree.
However, as configuration grows in complexity, this means that the entry
point would have an enourmous list of parameters,
that need to be propagated down to its dependencies.
for instance, myapp takes a $jmxtrans_output, which it passes to tomcat,
which it passes to jmxtrans::connection.
and if I have more dependencies like this one, myapp would not take 4
parameters, but far too many.
what is a proper way to inject $jmxtrans_output to jmxtrans::connection
without requiring to declare it in myapp nor tomcat?
I could declare to do $jmxtrans_output a global variable, but that is ugly.
what if I have myapp1, and myapp2, which uses two differents
$jmxtrans_output?
node ''mynode'' {
$tomcat_conf = {
hostname => ''host1.example.com'',
port => 8080,
jmx_port => 9200,
jmx_username => ''my_tomcat_jmx_username'',
jmx_password => ''my_tomcat_jmx_password'',
}
$jmxtrans_output = {
host => ''graphite_dev.example.com'',
port => 2003,
username => ''my_graphite_username'',
password => ''my_graphite_password'',
}
class { myapp:
tomcat_conf => $tomcat_conf,
jmxtrans_output => $jmxtrans_output,
market => ''US'',
products => [''p1'', ''p2'',
''p3'']
}
}
class myapp($tomcat_conf, $jmxtrans_output, $market, $products) {
# it installs several packages, as tomcat, imagemagick... and
configuration files...
class { tomcat:
tomcat_conf => $tomcat_conf,
jmxtrans_output => $jmxtrans_output,
}
# package { imagemagik: ensure => installed }
# ...
}
class tomcat($tomcat_conf, $jmxtrans_output) {
# package { tomcat: ensure => installed }
# config file, using $tomcat_conf.{hostname, port, jmx_port,
jmx_username, jmx_password}
#...
$tomcat_jmx = {
host => $tomcat_conf[hostname],
port => $tomcat_conf[jmx_port],
username => $tomcat_conf[jmx_username],
password => $tomcat_conf[jmx_password],
}
jmxtrans::connection { $name:
input => $tomcat_jmx,
output => $jmxtrans_output,
template_source => "myapp/tomcat_jmxtrans.json.erb",
# require => Class[jmxtrans]
}
}
# todo: replace $template_source with $objects (the objects to be
monitored, instead of passing a full template)
define jmxtrans::connection ($input, $output, $template_source) {
notify {"jmxtrans::connection::input: $input": }
notify {"jmxtrans::connection::output: $output": }
file { "/tmp/jmxtrans_${hostname}_${name}.json":
content => "template that uses \ninput_host:
${input[host]}\ninput_port: ${input[port]}\ninput_username:
${input[username]}\ninput_password: ${input[password]}\noutput_host:
${output[host]}\noutput_port: ${output[port]}\noutput_username:
${output[username]}\noutput_password: ${output[password]}\n",
# content => template(template_source),
}
}
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/1e11d0f5-0b85-404a-a71c-e76fcce80eb1%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Wednesday, December 4, 2013 11:48:50 AM UTC-6, David Portabella wrote:> > Here: > http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php > it explains that "modules that have configuration should be configurable > in a single way and single place", > and I agree. > > However, as configuration grows in complexity, this means that the entry > point would have an enourmous list of parameters, > that need to be propagated down to its dependencies. > for instance, myapp takes a $jmxtrans_output, which it passes to tomcat, > which it passes to jmxtrans::connection. > and if I have more dependencies like this one, myapp would not take 4 > parameters, but far too many. > > what is a proper way to inject $jmxtrans_output to jmxtrans::connection > without requiring to declare it in myapp nor tomcat? > > I could declare to do $jmxtrans_output a global variable, but that is ugly. > what if I have myapp1, and myapp2, which uses two differents > $jmxtrans_output? > >You are running into one of the lesser evils of parameterized classes: they can lead you down the path of trying to push all your configuration data in at the front end. You should be writing classes that pull their configuration data from hiera or another external source, so that your classes do not normally need to accept data that is intended only to be passed on to other classes. Instead, each class pulls its own data and/or relies on data belonging to other classes and pulled by those. Indeed, I have long argued, for a variety of reasons, that although parameterized classes themselves are not inherently harmful, you should avoid declaring them via parameterized-style class declarations (leaving you relying on automated data binding for class parameter customization). 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/2a0937e8-9828-4068-ba64-e389794d321e%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
calling hiera from inside jmxtrans::connection would contradict the argument: "modules that have configuration should be configurable in a single way and single place", explained here: http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php I agree with that argument, because it makes clear what parameters a class needs, and it makes it easier to unit test, and it allows to have two apps, myapp1, and myapp2, which uses two differents $jmxtrans_outputs. and that''s not with case calling hiera from inside jmxtrans::connection. On Wednesday, December 4, 2013 10:26:11 PM UTC+1, jcbollinger wrote:> > > > On Wednesday, December 4, 2013 11:48:50 AM UTC-6, David Portabella wrote: >> >> Here: >> http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php >> it explains that "modules that have configuration should be configurable >> in a single way and single place", >> and I agree. >> >> However, as configuration grows in complexity, this means that the entry >> point would have an enourmous list of parameters, >> that need to be propagated down to its dependencies. >> for instance, myapp takes a $jmxtrans_output, which it passes to tomcat, >> which it passes to jmxtrans::connection. >> and if I have more dependencies like this one, myapp would not take 4 >> parameters, but far too many. >> >> what is a proper way to inject $jmxtrans_output to jmxtrans::connection >> without requiring to declare it in myapp nor tomcat? >> >> I could declare to do $jmxtrans_output a global variable, but that is >> ugly. >> what if I have myapp1, and myapp2, which uses two differents >> $jmxtrans_output? >> >> > > You are running into one of the lesser evils of parameterized classes: > they can lead you down the path of trying to push all your configuration > data in at the front end. You should be writing classes that pull their > configuration data from hiera or another external source, so that your > classes do not normally need to accept data that is intended only to be > passed on to other classes. Instead, each class pulls its own data and/or > relies on data belonging to other classes and pulled by those. > > Indeed, I have long argued, for a variety of reasons, that although > parameterized classes themselves are not inherently harmful, you should > avoid declaring them via parameterized-style class declarations (leaving > you relying on automated data binding for class parameter customization). > > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/04b8f22b-c263-4123-bd73-e7402d6a2016%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
----- Original Message -----> From: "David Portabella" <david.portabella@gmail.com> > To: puppet-users@googlegroups.com > Sent: Wednesday, December 4, 2013 9:35:05 PM > Subject: [Puppet Users] Re: dependency injection in puppet > > calling hiera from inside jmxtrans::connection would contradict the > argument: > "modules that have configuration should be configurable in a single way > and single place", > explained here: > http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.phpIt also says: "As before I will show a simple module for a common scenario. Rather than considering this module a blueprint for every module out there you should instead study its design and use it as a starting point when writing your own modules. You can build on it and adapt it but the basic approach should translate well to more complex modules." so if you feel your module has too many arguments, adjust the pattern but try to understand why it recommends what it does and try to stay within the overall goals you do not need to pass in all the arguments, your inner modules can reference like $jmxtrans::foo for example this removes a lot of the duplication if you go this route. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/600648432.1620.1386193359078.JavaMail.zimbra%40devco.net. For more options, visit https://groups.google.com/groups/opt_out.
David Portabella
2013-Dec-04 21:53 UTC
Re: [Puppet Users] Re: dependency injection in puppet
> so if you feel your module has too many arguments, adjust the pattern buttry to> understand why it recommends what it does and try to stay within theoverall goals sure, and again, what i like about it is that it allows to have two apps, myapp1, and myapp2, which uses two differents $jmxtrans_outputs. you mean something like this? again, this does not allow to have two apps, myapp1, and myapp2, with two differents $jmxtrans::outputs. node ''mynode'' { $tomcat_conf = { hostname => ''host1.example.com'', port => 8080, jmx_port => 9200, jmx_username => ''my_tomcat_jmx_username'', jmx_password => ''my_tomcat_jmx_password'', } class {jmxtrans::output: host => ''graphite_dev.example.com'', port => 2003, username => ''my_graphite_username'', password => ''my_graphite_password'', } class { myapp: tomcat_conf => $tomcat_conf, market => ''US'', products => [''p1'', ''p2'', ''p3''] } } class myapp($tomcat_conf, $market, $products) { # it installs several packages, as tomcat, imagemagick... and configuration files... class { tomcat: tomcat_conf => $tomcat_conf, } # package { imagemagik: ensure => installed } # ... } class tomcat($tomcat_conf) { # package { tomcat: ensure => installed } # config file, using $tomcat_conf.{hostname, port, jmx_port, jmx_username, jmx_password} #... $tomcat_jmx = { host => $tomcat_conf[hostname], port => $tomcat_conf[jmx_port], username => $tomcat_conf[jmx_username], password => $tomcat_conf[jmx_password], } jmxtrans::connection { $name: input => $tomcat_jmx, template_source => "myapp/tomcat_jmxtrans.json.erb", # require => Class[jmxtrans] } } # todo: replace $template_source with $objects (the objects to be monitored, instead of passing a full template) define jmxtrans::connection ($input, $template_source) { notify {"jmxtrans::connection::input: $input": } notify {"jmxtrans::connection::output: $jmxtrans::output": } file { "/tmp/jmxtrans_${hostname}_${name}.json": content => "template that uses \ninput_host: ${input[host]}\ninput_port: ${input[port]}\ninput_username: ${input[username]}\ninput_password: ${input[password]}\noutput_host: ${jmxtrans::output[host]}\noutput_port: ${jmxtrans::output[port]}\noutput_username: ${jmxtrans::output[username]}\noutput_password: ${jmxtrans::output[password]}\n", # content => template(template_source), } } class jmxtrans::output ($host, $port, $username, $password) { } On Wednesday, December 4, 2013 10:42:39 PM UTC+1, R.I. Pienaar wrote:> > > > ----- Original Message ----- > > From: "David Portabella" <david.po...@gmail.com <javascript:>> > > To: puppet...@googlegroups.com <javascript:> > > Sent: Wednesday, December 4, 2013 9:35:05 PM > > Subject: [Puppet Users] Re: dependency injection in puppet > > > > calling hiera from inside jmxtrans::connection would contradict the > > argument: > > "modules that have configuration should be configurable in a single > way > > and single place", > > explained here: > > > http://www.devco.net/archives/2012/12/13/simple-puppet-module-structure-redux.php > > It also says: > > "As before I will show a simple module for a common scenario. Rather than > considering this module a blueprint for every module out there you should > instead study its design and use it as a starting point when writing your > own modules. You can build on it and adapt it but the basic approach > should > translate well to more complex modules." > > so if you feel your module has too many arguments, adjust the pattern but > try to > understand why it recommends what it does and try to stay within the > overall goals > > > you do not need to pass in all the arguments, your inner modules can > reference > like $jmxtrans::foo for example this removes a lot of the duplication if > you > go this route. > >-- 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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/15579f6d-30d2-4237-a02a-855e7db8d2d8%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.