On Mon, Dec 17, 2012 at 10:47:36PM -0800, Roman Shaposhnik wrote:
> On Mon, Dec 17, 2012 at 6:46 AM, Nikola Petrov 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
>
On Mon, Dec 17, 2012 at 6:46 AM, Nikola Petrov 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
(although I'm a bit
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 Sun, Dec 16, 2012 at 6:41 AM, Jason Slagle 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 XML :-(
> Make t
On Sun, Dec 16, 2012 at 1:39 PM, Tom Linkin 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 on
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 f
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
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
