On Friday, June 21, 2013 5:05:20 PM UTC+2, jcbollinger wrote: > > > > On Thursday, June 20, 2013 10:14:09 AM UTC-5, Alessandro Franceschi wrote: >> >> >> >> On Thursday, June 20, 2013 4:12:46 PM UTC+2, jcbollinger wrote: >>> >>> >>> >>> On Wednesday, June 19, 2013 5:34:58 PM UTC-5, Alessandro Franceschi >>> wrote: >>> >>> >>>> *A really reusable module HAS to be parametrized*. >>>> >>> >>> >>> Utter hogwash. >>> >> >> Lol. Show me a real example of a reusable module without parametrized >> classes that at least manages a typical package/service/configuration file >> scenario. >> Give me proofs, not words that I have to search on a dictionary. >> >> > > > Anything you can configure with class parameters, you can configure > without them via external data. Generally speaking, I would turn to hiera > for that. If you want an ENC that surpasses hiera's built-in capabilities, > then it can be written in the form of a custom hiera back-end. > > On the other hand, if your criterion for a module being "reusable" is that > it can be used in every way exactly as a module based on parameterized > classes can be used, then the question is rigged. > > That hiera was not built-in to Puppet 2 does not alter my evaluation > here. It is readily available and widely used with that series. I have > always held that parameterized classes were not safe to use in Puppet 2 > anyway, so if the objective is modules that are reusable in Puppet 2 then I > would go beyond "parameterization is not required" to "parameterization of > API classes is forbidden". That leaves you with dynamic scoping and > extlookup() as your only built-in alternatives, and however suitable they > may be (or not) for Puppet 2, they are not suitable for Puppet > If the objective is for modules to be written so as to be usable in both > Puppet 2 and Puppet 3, then I think Hiera is the only viable alternative. > Classes belonging to module APIs must not be declared via the parameterized > style, and though avoiding that in Puppet 2 could be supported by using > hiera() calls for parameter default values, writing API classes that way > produces (i) worse compilation performance in Puppet 3, and (ii) the > opportunity for users to shoot themselves in the foot. >
Still words and no samples John. I show you again this one, then. https://github.com/example42/puppet-stdmod it does what we want. Automatic Hiera lookups if you have Puppet3, and I hope data bindings are here to stay. or parametrized classes declarations, which are finally getting some respect also from ENCs. You can use it how you want. And if you don't like how the module is done, as I presume, you can do a different version, like this: https://github.com/example42/puppet-stdmodalt or whatever other better layout you may want to produce. They are based on parametrized classes, incidentally. I'm still not able to make a truly reusable module in other ways. (And still don't see them around). But this is not the point. Are the parameters / hiera variables suggested useful? Can some of them be considered useful for the module's reusability? Which ones are good enough to be considered obvious and a logic? Which ones make sense enough to have a common name and be suggested as standard? Which other ones can be suggested? Now, really, I would prefer to discuss about that with* you,* if you want and most of all *eveybody * *t*hinks this might a good thing for the evolution of the modules' ecosystem in the next years. (Hello PuppetLabs?) -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
