I had a similar problem, i use Git, and i though i could use branches and
Git tricks, but it does not mixes well with Puppet environments. What i do
below permits to use many puppet code branches, while having my puppetmaster
serve all different branches at the same time using environments
In my case, my puppetmaster does not checkout/pull from a code repo, but
could, it does not matter. So in my case, i do a rsync --delete of my
current workingdir from my workstation to the puppetmaster
/etc/puppet/environments/{manifests,modules}. My puppetmaster has
environments configured, so it can have test environments for the work in
progress, and the production environment. The environments permits to have
many copies of my puppet manifests and modules for the staging or testing
puppet clients, while still being able to serve a Production environment to
the prod puppet clients
On my workstation, i commit only when i am sure and everything is tested,
and this completely independant from what is on the puppetmaster. As an
improvement and for better traceability, i might setup my Production puppet
environment as a code repo checkout of my master branch or some tag. I would
not do it for the test environments, because like you, i do not want to have
to commit many small commits to be able to checkout/pull on the puppetmaster
My puppet environments are rsynced like this. I have a script (which i will
probably put on github once i have time, along with all my recipes) which
creates a environments/directory and rsyncs directly into it, and change the
/etc/puppet.conf to set the environment (from an puppet.conf.erb)
# ls -ld /etc/puppet/environments/*
lrwxrwxrwx. 1 root puppet 11 Jul 25
14:47*/etc/puppet/environments/production -> /etc/puppet
*
drwxr-xr-x. 4 root root 4096 Aug 7 07:45
/etc/puppet/environments/alex
drwxr-xr-x. 4 root root 4096 Sep 26 11:58
/etc/puppet/environments/alextest
drwxr-xr-x. 4 root root 4096 Aug 19 07:51
/etc/puppet/environments/staging
# find -type d /etc/puppet/
/etc/puppet/
/etc/puppet/modules
/etc/puppet/modules/java
/etc/puppet/modules/java/manifests
/etc/puppet/modules/bluepill
/etc/puppet/modules/bluepill/files
/etc/puppet/modules/bluepill/manifests
/etc/puppet/modules/mongodb
(...)
/etc/puppet/manifests
/etc/puppet/manifests/nodes
/etc/puppet/manifests/classes
(...)
/etc/puppet/environments
/etc/puppet/environments/staging
/etc/puppet/environments/staging/modules
/etc/puppet/environments/staging/modules/java
/etc/puppet/environments/staging/modules/java/manifests
/etc/puppet/environments/staging/modules/bluepill
/etc/puppet/environments/staging/modules/bluepill/files
/etc/puppet/environments/staging/modules/bluepill/manifests
/etc/puppet/environments/staging/modules/mongodb
(...)
/etc/puppet/environments/staging/manifests
/etc/puppet/environments/staging/manifests/nodes
/etc/puppet/environments/staging/manifests/classes
(...)
/etc/puppet/environments/alextest
/etc/puppet/environments/alextest/modules
/etc/puppet/environments/alextest/modules/java
/etc/puppet/environments/alextest/modules/java/manifests
/etc/puppet/environments/alextest/modules/bluepill
/etc/puppet/environments/alextest/modules/bluepill/files
/etc/puppet/environments/alextest/modules/bluepill/manifests
(...)
/etc/puppet/environments/alextest/manifests
/etc/puppet/environments/alextest/manifests/nodes
/etc/puppet/environments/alextest/manifests/classes
(...)
/etc/puppet/environments/alex
/etc/puppet/environments/alex/modules
/etc/puppet/environments/alex/modules/mongodb
/etc/puppet/environments/alex/modules/mongodb/manifests
(...)
2011/10/18 Andreas Paul <a.p...@enbw.com>
> Hi,
>
> we are currently managing our puppet modules with one SVN workspace for
> each admin.
> The post commit hook script updates /etc/puppet/ directory and triggers the
> puppet kick of the correct server.
>
> The problem we have with this solution is that sometimes there are many
> small checkins to one change, because the admin forgot to change small
> details in the config file, e.g. forgot to change the access logfile name of
> the vHost, forgot a redirect, misspelling in the comments etc.
>
> What we end up with are many micro checkins, which can be used to tell
> every small mistake the admin has done.
>
> What we want is a solution which lets the admin test his changes on one
> server without checking these changes into the "main" SVN repository.
> So that the SVN repository only contains the final releases of the changes.
>
>
> I have to say that we also manage the dev and QA servers with this
> puppetmaster. Would dividing of these different stages into puppet
> environments help us?
> What I really want to know is, do you understand my problem and if you had
> the same problem, how did you solve it? SVN branches? Multiple
> puppetmasters, one to test with a dedicated test SVN repository?
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/FLNYwiOI1fwJ.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
