Dear Brian and John,

Thanks a lot for your replies. I was under the impression that site.pp had 
to be in the environment, which I now see it doesn't have to. =)

What I don't quite understand is though is the following:

There are four forbidden environment names:
>    
>    - main
>
>
>    - master
>
>
>    - agent
>
>
>    - user
>
> These names are already taken by the primary config 
> blocks<http://docs.puppetlabs.com/guides/configuring.html#config-blocks>. 
> If you are using Git branches for your environment names, this may mean 
> you’ll need to rename the master branch to something like production or 
> stable.


How can a git branch name (master) conflict with content in the puppet.conf 
file?

Hugs,
Sandra =)






On Friday, 16 August 2013 01:14:44 UTC+2, John Warburton wrote:
>
> On 16 August 2013 00:14, Sandra Schlichting <littles...@gmail.com<javascript:>
> > wrote:
>
>> Hello all =)
>>
>> What I would like is a way so multiple people can make changes to all 
>> files in /etc/puppet/, but only after they have tested their changes then 
>> they "git push" so /etc/puppet is updated. The git repo is in /etc/puppet. 
>> When I read about environments [1] I get the impression that is only for 
>> module development, is that correct?
>>
>> Ideally what I would like is each user to have their private environment 
>> where they can "git pull" to. E.g. 
>>
>  
>
>> Can something like this be done? And if so, what would my 
>> /etc/puppet/puppet.conf look like?
>>
>  
> This is exactly what we do - each admin has their own environment. We use 
> SVN, so substitute where required, but essentially we force a particular 
> directory structure for every admin and reflect that in the 
> puppetmaster.conf of our lab server. NB the SVN work spaces must be on the 
> same server as the lab puppet server for this to work
>
> # Replicate this, and change "username" as appropriate (one per line)
> #[Lusername]
> #    modulepath = /u1/username/svn-workspace/puppet/Lusername/modules
> #    manifest = 
> /u1/username/svn-workspace/puppet/Lusername/manifests/site.pp
> #    manifestdir = /u1/username/svn-workspace/puppet/Lusername/manifests
>
> Because we have different yum/pkg repos per environment, that capital L 
> for the environment allows us to do some generic regexp matching to 
> override to a single "lab" repo and not one per admin
>
> All changes are a feature 
> branch<http://nvie.com/posts/a-successful-git-branching-model/>, 
> and we wrap the creation of a JIRA ticket, new feature branch name based on 
> JIRA ticket number (UX-0000) and sym link 
> /u1/username/svn-workspace/puppet/Lusername to 
> /u1/username/svn-workspace/puppet/branches/UX-0000 in a script
>
> We then set the environment of whatever development VM/server we need to 
> develop/test the code - including full rebuilds and "it just works". We 
> have another script which checks for a valid peer review (reviewboard) then 
> merges the changes back into develop/trunk, and updates the JIRA ticket
>
> The only gotcha is if you have multiple feature branches at any time and 
> managing the sym link
>
> John
>

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to