On Tue, Oct 18, 2011 at 01:52:18AM -0700, Andreas Paul wrote:
> 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.
we use git branches. the master branch is _always_ production-ready.
for every issue, we:
* create a topic branch
* hack away
* push the topic branch to origin/$branch_name
* a post-push service hook creates, updates, or deletes
/opt/puppet/$branch_name
On the puppetmaster, puppet.conf has:
[main]
manifestdir = /opt/puppet/$environment
manifest = $manifestdir/site.pp
modulepath = $manifestdir/modules:/opt/puppet/3pp
We then test the topic branch via the puppet agent
by running 'puppet agent --environment $branch_name ...'
> 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.
Our topic branches have lots of these so-called micro-commits,
but that's ok. Once $branch_name is clean, we:
* squash the micro-commits
git rebase -i <hash>
# prepare a linear commit history
git fetch origin
git rebase origin/master
git checkout master
git merge $branch_name
# delete local and remote branch
git branch -d $branch_name
git push origin :$branch_name
* ship
git push origin
> 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.
The key is to use rebase to squash the micro-commits in the branch.
I'm not sure if svn has that capability yet, but a quick google
search showed at least one script that sort of simulated a rebase
with svn. Or perhaps you could try git-svn.
> 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?
We manage differences via parameterized modules.
For example:
class foo {
require foo::params
package {'fubar': ensure => $foo::params::fubar_version}
}
class foo::params {
$fubar_version = $fqdn ? {
# exceptions
something.qa.example.com => '2.1.0-1.f15',
# patterns
/^.*\.prod\.example\.com$/ => '1.2.3-4.el5',
/^.*\.qa\.example\.com$/ => '1.2.4-1.el5',
/^.*\.dev\.example\.com$/ => latest,
default => '1.2.3-4.el5',
}
}
The above is not perfect, but it allows us to keep our
node manifests under version control.
> 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?
We thought about multiple puppetmasters, but it's more important
to us to maintain a clean version control history in one place.
hth,
-paul
--
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.
