Firstly, forgive me if I get my terminology mixed up. Being sold on
the virtues of TDD, I have a growing itch to test our puppet
manifests. Now by this I dont mean testing, say, the mechanics of a
define to test that the right things *happen*, I mean being able to
say that given a collection of cla
With a manifest like so:
class base {
$myvar = '1234'
file {
'/tmp/foo':
content => template('test.erb')
}
}
class newbase inherits base {
$myvar = '5678'
}
node default {
include newbase
}
And test.erb with <%= myvar %>
/tmp/foo contains 1234, when I would expect it to con
e issues with
> 2.6 http://projects.puppetlabs.com/issues/4409) .
>
> I would recommend either:
>
> 1. trying your use case with 2.6
> 2. keep a single copy of your plugins in the puppetmaster's modulepath.
>
> hope this helps,
>
> Dan
>
> On Wed, Aug 18, 201
Hey folks,
I have just created a puppet environment called testing by adding the
following to puppet.conf on the puppetmaster:
[testing]
manifest = /etc/puppet/testing/manifests/site.pp
modulepath = /etc/puppet/testing/modules
We are collecting all our customisations into a module, let
Hey folks,
We're on the verge of deploying puppet into production so have changed
from using webrick to mongrel with an apache reverse proxy. The nodes
were behind a NAT firewall under webrick but it didnt seem to mind,
however something isnt right with my reverse proxy configuration and I
cant fi
