Aaron Grewell writes: > Technically true, but administratively confusing IMHO.
We put our all our Puppet data (but not the puppetmaster config) in a Subversion repository. Everyone does editing in their own working copy checked out from that Subversion repository. Commits to the repository trigger a post-commit hook that checks out the new version on the puppetmaster, updating files only under /etc/puppet/manifests and /etc/puppet/modules (the main puppet config files in /etc/puppet itself are not touched). The puppetmaster then picks up the changes so that clients will pull updated manifests and resources on their next check. No one is ever to edit files directly under /etc/puppet/manifests or /etc/puppet/modules on the puppetmaster hosts; those files are essentially just another working copy from Subversion's point of view, but edits there would just produce checkout conflicts. We also have an /etc/puppet/development subdirectory containing a development branch of the Puppet files that can be applied to hosts in the development environment. This is all quite straightforward and easily allows multiple people to work concurrently on (non-conflicting) Puppet updates. Conflicts are detected and resolved with Subversion checkins rather than when a checkout is made on the puppetmaster. We're doing this with over 200 nodes and 150 modules. > On Thu, Sep 1, 2011 at 1:08 PM, Scott Smith <sc...@ohlol.net> wrote: > > > A directory is a directory. That a directory has a parent directory in > > which other files exist is pretty moot. > > > > On Thu, Sep 1, 2011 at 12:13 PM, Aaron Grewell > > <aaron.grew...@gmail.com>wrote: > > > >> We don't put our manifests under /etc/puppet at all. It's convenient for > >> small installations but as we scaled up I found mixing configs (local, > >> managed by Puppet) and manifests (kept under version control) to be > >> problematic. > >> On Sep 1, 2011 11:58 AM, "Russell Van Tassell" <russel...@gmail.com> > >> wrote: > >> > I'm currently in the same position, and the solution I've proposed (and > >> am > >> > currently working on) involves using a central repository (likely git). > >> The > >> > puppet client (running on the master) simply checks the current master > >> > branch on the remote repository -- if the revisions are not the same, it > >> > just pulls a new copy. > >> > > >> > While I've not implemented this, yet ... I'm guessing it should work. > >> Anyone > >> > have any better ideas -- perhaps a check-in hook to trigger at export? > >> > > >> > Regards, > >> > Russell > >> > > >> > > >> > On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang > >> > <doug.garst...@gmail.com>wrote: > >> > > >> >> I have a real-world, best practices, procedural question. > >> >> > >> >> How do you manage the he puppet master, under /etc/puppet, where > >> multiple > >> >> people may be editing files? The /etc/puppet directory is a working > >> copy, > >> >> and each user has read access to files created by other users. However, > >> if > >> >> one person adds a module directory to svn, the lock files that are > >> created > >> >> by svn are owned by that person, and the next person that comes along > >> can't > >> >> do svn updates etc. Similarly I can't write to files created by a > >> different > >> >> user. > >> >> > >> >> Yes, sure, the 'right way' to do this may be to have all the files > >> owned by > >> >> the puppet user, and users don't edit files directly in /etc/puppet, > >> and a > >> >> script is responsible for performing the svn update, but we're not > >> there > >> >> yet. > >> >> > >> >> Ideas? > >> >> > >> >> Doug. > >> >> > >> >> -- > >> >> 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. > >> >> > >> > > >> > -- > >> > 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. > >> > > >> > >> -- > >> 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. > >> > > > > -- > > 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. > > > > -- > 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. > -- 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.
