On Sun, Dec 16, 2012 at 1:39 PM, Tom Linkin <[email protected]> wrote: > 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
Yup. This is the one I was looking at when I mentioned that I could've gone a concat route. It just feels a bit heavy. In fact, I'd love for Puppet to have a sort of a in-memory store that can be manipulated same way that concat manipulates files in the actual filesystem. Something like tmpfile resource. Has anything like that ever been considered? > 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? Only that it is not consistent (and you can't guess from a name) whether each one needs to go into the common or service-specific configuration file. > 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. I don't think this would be a problem. The names themselves are descriptive (and they are NOT order sensitive). The only problem with them is that you can't tell by just looking at a name where the property should go. Thanks, Roman. -- 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.
