On Tuesday, June 25, 2013 11:49:49 PM UTC+2, Alessandro Franceschi wrote: > > > > On Tuesday, June 25, 2013 9:16:20 PM UTC+2, jcbollinger wrote: >> >> >> >> On Monday, June 24, 2013 9:12:17 AM UTC-5, Alessandro Franceschi wrote: >>> >>> >>> >>> On Monday, June 24, 2013 3:57:55 PM UTC+2, jcbollinger wrote: >>>> >>>> >>>> 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. >>> >>> >> So, here is a version of puppet-stdmod without class parameterization: >> https://github.com/jcbollinger/puppet-stdmod . >> > > Ok, this is what I expected. > Thank you for your time. > I can definitively argue that this is not fully reusable > ("So please show me a reusable module without parameters and without > hiera functions inside, as that would not be reusable by whoever does not > use Hiera.") > but it's not relevant since with Puppet 3 data bindings we have the best > of both worlds. > Personally I see only good reasons to recommend, as patterns for the > future, modules designed with parametrized classes. > > >> All management capabilities of the original module are retained. >> Customization data are provided to it via Hiera (which the module calls >> explicitly), so the most significant change was simply to convert >> parameters to ordinary variables initialized vie Hiera. >> >> The conversion was not entirely mechanical, in that I had to accommodate >> some Hiera idiosyncrasies -- mainly that it cannot return either undef or >> (boolean) false. Inasmuch as one would like the parameterized version to >> be fully compatible with automatic parameter binding, however, I would >> account at least some of those adaptations as usability enhancements with >> respect to the parameterized version. >> >> I did not convert the tests. >> >> Also, I do not specially endorse stdmod's particular design (either >> version). I would write it at least a bit differently if doing so from >> scratch, but I think we've agreed to turn the discussion in a different >> direction. >> >> >> John >> > > Yes, > let's go on. > I guess the first steps should be to identify a coherent naming pattern, > even before single names and define more precisely what parameters might be > recommended, optional, or considered "extensions" . >
Talking about naming schemes, here are some possibilities (copied from: https://docs.google.com/a/lab42.it/document/d/1D4OqEI5iuGJe63ODU91N6rnFKcxVAg1sAWbaQrGBlWA ) we can discuss and improve. Given the sample names below, there are at least 2 different approaches that can be followed, and once defined all the parameters names can somehow emerge naturally: 1- Place a common suffix for any kind of parameter 2- Place suffixes for some specific params and leave more general names of general ones Examples for case 1 ensure package_name package_version service_name service_ensure file_path file_source file_template dir_path dir_source Examples for case 2 ensure package version service service_ensure file_path source template dir_path dir_source For both cases extra resources can be referred according to their name and type of resource, for example: server_package_name, master_file_path, controller_service_name and things like that. A general pattern could be: [name_of_resource]_<type_of_resource>_<resource_parameter> - For the “main” resources of a class (main/unique package, main/unique service, main configuration file...) the name_of_resource is omitted. - The type_of_resource reflects Puppet types (are “exceptions” like dir_ allowed?) - The resource_parameter tends to map to a typical Puppet resource parameter (exceptions like template, version, options?) -- 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.
