Douglas Garstang wrote:
> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang
> <doug.garst...@gmail.com> wrote:
>
>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <r...@devco.net> wrote:
>>
>>> hello,
>>>
>>> ----- "Douglas Garstang" <doug.garst...@gmail.com> wrote:
>>>
>>>
>>>> I'd like to be able to split out my puppet production and test
>>>> environments so that I can continue to develop puppet
>>>> modules/manifests without breaking production. How are people doing
>>>> this? Puppet environments may be one way. I guess I'd have a
>>>> main(prod) environment and a test one. When I was finished with
>>>> testing, I could rsync the files over to the prod environment. Is
>>>> this
>>>> how others are doing it?
>>>>
>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php
>>>
>>> That's how I do it, aim is to avoid many copies of the same module just
>>> because we have multiple environments, but still have the ability to create
>>> those versions during the dev cycle.
>>>
>>> not for everyone, but maybe it help you in the right direction.
>>>
>> Thanks to everyone for the replies.
>>
>> Are you using multiple environments though? And, if using multiple
>> environments, how do you structure it? The puppet documentation is a
>> bit vague on the subject. For instance, it's not clear to me if you
>> would structure it so that you have a top level dir ABOVE puppet
>> called prod, test etc, or if you would create subdirs BELOW manifests,
>> modules etc called prod, test.
>>
>> The next question is, where do you branch? If you have a top level dir
>> above puppet, I guess that's pretty easy, but if you have multiple
>> dirs below manifests, modules etc, then you'd need to branch each
>> which becomes more complex.
>>
>
> Hmmm. I'm not following this here. At the moment I have /etc/puppet,
> which is a working copy. Every now and then I commit my changes. I can
> add a dev environment to this working copy and safely use that to test
> modules and manifests on dev nodes, but there's still no way for me to
> roll those changes back to the production environment without some
> manual process.
>
> I could make a branch of /etc/puppet, and check it out, but then I'd
> need a second copy of puppetmaster running in a second location to
> test it against. I'm using passenger, so maybe I could fire up a
> second instance on another port, and maybe that would work.
>
> If I was to branch the prod dir inside puppet into a dev dir, then
> this is kind of where I get lost. If I was to branch /etc/puppet/dev
> or simialar, once again I'd need to check it out into a new location
> where I could work on it, and test it. This still needs a second copy
> of puppetmaster running, and it's actually worse this way because I
> don't have all the necessary puppet config from further up the tree.
>
> Grrrr.
> /
>
>
As I currently use SVN I prefer checking out the hole svn
(branches/tags/trunk) to something like /etc/puppetconfig (you may use
/usr/share/ or var or whatever you prefer) and create a symlink from
/etc/puppet.conf to /etc/puppetconfig/branches/production/puppet.conf.
The puppet.conf in trunk is usually used when changing server
configuration on a testing puppet master. Both of them describe the
production environtment as /etc/puppetconfig/branches/production and
development as blah/blah/blah/trunk. So for normal manifest change you
work with the production puppet master with environment development, but
for config changes of puppet master you work with a different computer
which uses the trunk config.
Good luck,
Silviu
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
