email alias issue

[Amos Shapira]

On 19 July 2011 23:01, Tom Goren <tom at tomgoren.com> wrote:
>
> Why better?

Puppet is not a replacement for SVN per-se, I use SVN to keep our
(very extensive) puppet configuration versioned.

I mentioned Puppet in the context of setting up and running a system
in a way that you can repeat what you did for one system, or one
instance of a module, with many other instances.

E.g. we have multiple dev, QA, staging, testing and production
environments. The effort we put into teaching Puppet on how to install
and configure one piece of our software in one environment, or in one
instance (e.g. postgres database backup can be used in many different
scenarios of Postgress installation) can be tested in one environment
then we can trust it that when we use the same module to repeat the
installation in another environment then it will do exactly what we
told it to.

>
> puppet and version control can compliment each other, as puppet's versioning is hopelessly poor.

Pretty much agree, though I haven't got around to check their
Dashboard or other tools I expect to help manage their "old versions
repository".

> When was the last time you tried to roll back an update you deployed via puppet?
> There are no logs or inherent diffs or anything you can do - only a big mess of a hash tree you can maybe grep.

I don't know about you but when I run Puppet to update a system I get
an exact log with diff's of what changed in each file.

> Anyhow, don't take it from me - here it is on the official puppetlabs wiki:
> http://projects.puppetlabs.com/projects/1/wiki/Change_Management

Wrong link? Change Management is not exactly about Rolling Back but
more about approving the update. They point to "version control" to do
exactly what we do - get the puppet configuration change reviewed (we
treat it just like a code review) before pushing it out to the next
stage.

> Where the whole issue is still a philosophical one, not even any concrete solutions suggested.
> I would recommend simply having all of /etc/puppet in a svn/git repo, so you can manage your manifests as well as the actual config files for change management.

That's exactly what we do (/etc/puppet on the *puppetmaster* is pushed
out from subversion), and I say it's far better than having the entire
/etc or any other sub-directory of the *puppet client* in SVN, which
is the suggestion I responded to.

--Amos