You may also want to consider looking at the concat module that R.I. Pienaar has on github. It should allow you to easily do the fragments on a common file like you described. https://github.com/ripienaar/puppet-concat
As for the way you expose the configuration properties as class parameters for the services, are you saying the actual names of $foo/$bar/$baz, for instance, would inform as to what information they need except it is not consistent between services which values go in which file? I suppose you could hide the detail of which property to which file if needed, however, parameterized classes do not work like functions. The parameters, at declaration time, can be declared in any order. Additionally, even if you could enforce the order in which they were passed, simply ordering them does not seem very intuitive still. Your best bet is to expose parameters with meaningful names, and document if it still is not very clear. -- Tom Linkin Professional Services Engineer http://puppetlabs.com/ twitter: @trlinkin On Sunday, December 16, 2012 at 9:41 AM, Jason Slagle wrote: > > > On 12/16/2012 01:09 AM, Roman Shaposhnik wrote: > > Hi! > > > > I would appreciate any advice on the best practices > > on how to model a collection of services that each > > has its own configuration file, but also share a common > > one. > > > > Now, the trouble is, that the common configuration file > > is not *really* just a place for the common configuration > > to reside, but also may have sections dedicated to holding > > properties of a particular service (just like /etc/puppet/puppet.conf > > has [main] [agent] and [master] sections). > > > > Thus, in reality, the configuration properties are > > per service and whether they need to go into a common > > configuration file or a service-specific one is NOT cleanly > > partitioned and is pretty awkward to remember. Which > > means I really don't want to expose the common config > > explicitly to the end user. > > > > Instead, I'd like to expose the natural hierarchy of: > > > > class service1($foo, $bar, $baz) { > > } > > ..... > > class serviceN($qoo, $zoo) { > > } > > > > but the question then becomes -- how can I model a > > common configuration file behind user's back so that > > $foo, $bar and $qoo end up there. > > > > At first I was thinking that I could utilize a singleton > > non-parameterized class and include it multiple > > times in all of the serviceX class definitions, but it > > seems I can't pass any values into it. > > > > I suppose I can still do that and create a skeleton > > of the common config in that singleton class > > that would later be manipulated either by augeas or > > concat patterns, but this seems to be pretty heavyweight. > > > > What would you, guys, recommend? > > This is a pattern I feel augeas is awesome at. I just did a similar > thing for puppet.conf on my end. > > Make the common configuration file virtual. Give it a default "dummy" > configuration file with replace = false (I do this because creating a > file with augeas seems a bit shaky to me). > > Then have each of the other services realize the common configuration > file and use augeas to add their own specific configuration elements. > > If the file is an inifile style, creating a lens is pretty trivial - you > can see the puppet file lens (Which is in > /usr/share/augeas/lenses/dist/puppet.aug on ubuntu) for an example. > > Jason > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
