On Mon, Dec 17, 2012 at 10:47:36PM -0800, Roman Shaposhnik wrote:
On Mon, Dec 17, 2012 at 6:46 AM, Nikola Petrov nikol...@gmail.com wrote:
You have a bunch of options for this if I understand you well. You can
one of the following:
* use augeas with virtual resources
* use the concat
You have a bunch of options for this if I understand you well. You can
one of the following:
* use augeas with virtual resources
* use the concat module
* use the standard template function with multiple arguments; look at
http://docs.puppetlabs.com/guides/templating.html and scroll down to
On Mon, Dec 17, 2012 at 6:46 AM, Nikola Petrov nikol...@gmail.com wrote:
You have a bunch of options for this if I understand you well. You can
one of the following:
* use augeas with virtual resources
* use the concat module
Understood. I'm leaning heavily towards augeas at this point
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
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
On Sun, Dec 16, 2012 at 1:39 PM, Tom Linkin tho...@puppetlabs.com 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
On Sun, Dec 16, 2012 at 6:41 AM, Jason Slagle raist...@tacorp.net wrote:
This is a pattern I feel augeas is awesome at. I just did a similar thing
for puppet.conf on my end.
Yup. Using augeas is my #1 design choice ATM. Btw, have you had
any experience with the XML lens? Those config files are
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
