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 [email protected]. 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.
