puppet module testing to produtcion deployment

[Evan Hisey]

Pete-
This is interesting, it could solve a problem I have with basicly
having to develop my puppet recipes in the production enviroment ( No
budget for a dev env) . I was trying to figure out a way to make the
seperation clean. This looks like the way to go, but if you could give
a more wordy over view of how the setup is done and handled, it would
make life easier.

Evan

On Mon, Mar 31, 2008 at 11:41 AM, Peter Meier <peter...@immerda.ch> wrote:
>
> Hi
>
>
> > How do people test config changes that puppet is managing.
>
> maybe you're interested in a setup like that:
> http://reductivelabs.com/trac/puppet/wiki/CommonModules
>
> This let you test it on one (by using the environment testing) and the
> push it to all the other by commiting it to production.
>
> greets pete
>
>
>
> >
>

[Peter Meier]

Hi

> This is interesting, it could solve a problem I have with basicly
> having to develop my puppet recipes in the production enviroment ( No
> budget for a dev env) . I was trying to figure out a way to make the
> seperation clean. This looks like the way to go, but if you could give
> a more wordy over view of how the setup is done and handled, it would
> make life easier.

well not really more than it documented on the site. ;)

But I try to phrase it a bit more and if you see things unclear within
this page please ask or (if you see what you can clarify) edit the wikipage!
The main goal of a splitted setup like this is that puppet can run
different sources (of modules, manifests etc. ) for different
environments on the same master. See more here:
http://reductivelabs.com/trac/puppet/wiki/ConfigurationReference
You can use this possibility to have a stable and a testing branch of
your manifests and modules (I really recommend you to use a scm for your
modules and manifests). You then can work on the testing branch, commit
it to the repo and so on. If you then want to test this setup you can
choose one of your servers as (as you stated that you have no testing
environment) and maybe take it out of loadbalancing or whatever, run:

puppetd --test --environment=development #(this is a normal puppetrun
from cli, with the environment set to development)

and see if all your changes apply. if they do, merge them into your
production branch and then they will be applied to all your production
hosts.

if you can't take a server out for testing, you might just apply it to
one (which might break only one, but hey often running it once again in
production environment will fix your problems (maybe)) or you could run
it on one with the --noop flag. which won't change anything, but which
won't ensure that everythings goes well.

hope this is a bit more wordy?! If I just might have told nuts, please
correct me.

greets Pete

[Evan Hisey]

Peter-
Thsi was perfect. I was what I though the wiki said but in a better
to understand method. Now I understand how what the wiki was saying to
do is oging to work :)

Evan

P.S.>> Going to put it all in SVN when i get enough of it working to deploy it
.