>
> I would really love to have a public repo (and if I'm allowed, I would love
> to publish our manifests) I know that there was a try to get a public repo -
> is it still around?
>
I know about:
http://projects.reductivelabs.com/projects/show/pcm
But I haven't seen much action with this yet.
>
> The structure itself is complicated, however the usage is quite simple if
> you understand the structure. nevertheless, if you have any
> better/simpler idea - I would really love to hear it..
I'm starting to look into what other users of Puppet are doing before
I draw any conclusions/re
On Wed, Feb 4, 2009 at 2:28 AM, Matt wrote:
> Hi Nigel,
>
> I gather you run puppet --parseonly for each new file that svn is going to
> commit. Do you have your pre-hook to share?
It's actually perforce, not subversion... and is kind of integrated
into some custom infrastructure here.
Basical
On Sun, Feb 8, 2009 at 9:59 AM, Larry Ludwig wrote:
>
> Hmm some comments to this...
>
> This sounds like a bear to maintain, while I think it's important to
> do in a complex environment like you have.
>
The structure itself is complicated, however the usage is quite simple if
you understand t
> module_dir { "/etc/puppet/env/global_puppetmaster":}
>
> # Stable service modules #
> modules { "PP-host-base": module => "host-base", site =>
> "global_puppetmaster", type => "services", version => "0.12"}
> modules { "PP-sudo": module => "sudo", site =>
> "global_puppe
I'm now running puppet --parseonly for every .pp in subversion. I'm
running it via CI so the configs aren't updated until they pass that
test. Also just discovered the TextMate bundle which allows you to
validate your manifests before you check in. Priceless.
J.
2009/2/4 Matt :
> Hi Nigel,
>
>
Hi Nigel,
I gather you run puppet --parseonly for each new file that svn is going to
commit. Do you have your pre-hook to share?
Thanks,
Matt
2009/1/7 Nigel Kersten
> We use environments for a release process, so we can test releases before
> pushing them to our stable environments.
> You ca
If it's not been already mentioned..
http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments
may help
On Fri, Jan 9, 2009 at 5:01 AM, Ohad Levy wrote:
> Ok - I'll try to make it as simple as I can...
>
> ***Modules***
>
> We define 3 types of modules (its just our internal definiti
Ok - I'll try to make it as simple as I can...
***Modules***
We define 3 types of modules (its just our internal definition):
1. host type - this module is the only class that the node would have and
its it primary function of the host (e.g. you can't use more than one host
type module in one no
> since many times, a given node has uses many different modules (which are
> managed by different people) we decided to tag our "stable" modules (e.g.
> associate it with a version) and generate an environment out of tested
> combination of the stable modules.
Would you be willing to describe th
Using Modules, environments and version control you can really scale up.
We currently manage a lot of environments with puppet, with a lot of
different sys-admins, each group responsible to a different set of modules.
since many times, a given node has uses many different modules (which are
manag
We use environments for a release process, so we can test releases before
pushing them to our stable environments.
You can also get puppet to check manifests for syntax validity with
--parseonly, which we and a lot of other people use as commit hooks in
version control so that at least the syntax i
12 matches
Mail list logo
