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+unsubscr...@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.
