On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote: > > > > On Friday, June 21, 2013 6:21:22 PM UTC-5, Alessandro Franceschi wrote: >> >> >> >> On Friday, June 21, 2013 5:05:20 PM UTC+2, jcbollinger wrote: >>> >>> 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. >> >> > > None of my modules have any parameterized classes, but I am not at liberty > to publish them. I can derive an example from someone else's module -- > maybe yours -- and I will do so if you're actually interested. However, > you have now said at least twice that that's not what you want to talk > about, and I'm not inclined to do the work if you're not interested in the > result. >
I'm still interested in seeing how this can be done, so any sample code useful to understand the approach would be extremely welcomed. Just an example, then we can move on. I'm not interested in sticking the discussion on that, also because I feel like we might have found the right "communication frequency" > > Either way, whether such modules are common is altogether beside the (my) > point, which is about whether conventions such as you wish to develop and > promote should *require* modules' API classes to be parameterized. I > will oppose that aspect of any such effort. > > The more fundamental idea of a common mapping of data and data types to > names (i.e. a data "ontology"), on the other hand, is an outstanding idea. > If the discussion is at that level then it will certainly keep my interest, > and it may attract my active participation. > Good. Then consider that all the name for "parameters" in: https://docs.google.com/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA/edit?usp=sharing may either refer to class' parameters or to hiera variables. For example a parameter "ensure" on the module apache, would map to hiera('apache::ensure'). What of those parameters/hiera variables could be considered useful enough to be recommended? What would be their names? -- 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.
