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 <[email protected]<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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
