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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Sep 01, 2011 at 11:58:04AM -0700, Russell Van Tassell 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.Once your organisation grows you want some release management: in GIT: - everybody has a local Git - all work is done in new branches - all finished branches are pushed back to a central GIT - the releasemanager mergens everything, and does testing (either by looking or running a test suite) - after testing has finished a tag is applied - the tag is checked out on the puppetmaster(s) -- __________________________________________________ "Nothing is as subjective as reality" Reinoud van Leeuwen reinoud.v@n.leeuwen.net http://reinoud.van.leeuwen.net kvk 27320762 __________________________________________________ -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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" <russellvt@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.garstang@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 arecreated>> by svn are owned by that person, and the next person that comes alongcan''t>> do svn updates etc. Similarly I can''t write to files created by adifferent>> user. >> >> Yes, sure, the ''right way'' to do this may be to have all the files ownedby>> the puppet user, and users don''t edit files directly in /etc/puppet, anda>> 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+unsubscribe@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 topuppet-users+unsubscribe@googlegroups.com.> For more options, visit this group athttp://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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Sep 01, 2011 at 09:07:37PM +0200, Reinoud van Leeuwen wrote:> On Thu, Sep 01, 2011 at 11:58:04AM -0700, Russell Van Tassell 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.In subversion, have a separate working copy on the puppetmaster host. Then to ensure that you have no local cruft on the puppetmaster your script will: cd /etc/puppet svn revert -R . svn up Your script can check for any files added/modified and touch site.pp to ensure that puppetmaster starts serving the changes.> Once your organisation grows you want some release management: > in GIT: > - everybody has a local Git > - all work is done in new branches > - all finished branches are pushed back to a central GIT > - the releasemanager mergens everything, and does testing (either by > looking or running a test suite) > - after testing has finished a tag is applied > - the tag is checked out on the puppetmaster(s) > > > -- > __________________________________________________ > "Nothing is as subjective as reality" > Reinoud van Leeuwen reinoud.v@n.leeuwen.net > http://reinoud.van.leeuwen.net kvk 27320762 > __________________________________________________ > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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.grewell@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" <russellvt@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.garstang@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang <doug.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Technically true, but administratively confusing IMHO. On Thu, Sep 1, 2011 at 1:08 PM, Scott Smith <scott@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.grewell@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" <russellvt@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.garstang@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Also, setgid directories with umask 002 can help if you don''t want to use a VCS. On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang <doug.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
I can''t say I''ve ever met someone who had trouble with this. On Thu, Sep 1, 2011 at 1:10 PM, Aaron Grewell <aaron.grewell@gmail.com>wrote:> Technically true, but administratively confusing IMHO. > > On Thu, Sep 1, 2011 at 1:08 PM, Scott Smith <scott@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.grewell@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" <russellvt@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.garstang@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Was that in reply to my original post, or a subsequent reply? You did see where I said /etc/puppet was a working copy, right? Doug. On Thu, Sep 1, 2011 at 1:09 PM, Scott Smith <scott@ohlol.net> wrote:> http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control > > On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang <doug.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- Regards, Douglas Garstang http://www.linkedin.com/in/garstang Email: doug.garstang@gmail.com Cell: +1-805-340-5627 -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
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 <scott@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.grewell@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" <russellvt@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.garstang@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
You asked for best practices and that document describes them, essentially. If your process is broken it should be fixed. On Thu, Sep 1, 2011 at 1:28 PM, Douglas Garstang <doug.garstang@gmail.com>wrote:> Was that in reply to my original post, or a subsequent reply? You did see > where I said /etc/puppet was a working copy, right? > > Doug. > > On Thu, Sep 1, 2011 at 1:09 PM, Scott Smith <scott@ohlol.net> wrote: > >> http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control >> >> On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang < >> doug.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/puppet-users?hl=en. >> > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garstang@gmail.com > Cell: +1-805-340-5627 > > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang writes: > Was that in reply to my original post, or a subsequent reply? You did see > where I said /etc/puppet was a working copy, right? It sounds like you need to get to the point where no one does their edits under /etc/puppet on the puppetmaster, because you''re obviously running into the problems that result when people edit there rather than in local working copies. Once you actually start using the features of a distributed version control system in the way it''s intended to work, you won''t have those problems. > Doug. > > On Thu, Sep 1, 2011 at 1:09 PM, Scott Smith <scott@ohlol.net> wrote: > > > http://projects.puppetlabs.com/projects/1/wiki/Puppet_Version_Control > > > > On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang <doug.garstang@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+unsubscribe@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+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > > > > > > -- > Regards, > > Douglas Garstang > http://www.linkedin.com/in/garstang > Email: doug.garstang@gmail.com > Cell: +1-805-340-5627 > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Sep 1, 2011 at 1:35 PM, Steven VanDevender <stevev@uoregon.edu>wrote:> Douglas Garstang writes: > > Was that in reply to my original post, or a subsequent reply? You did > see > > where I said /etc/puppet was a working copy, right? > > It sounds like you need to get to the point where no one does their > edits under /etc/puppet on the puppetmaster, because you''re obviously > running into the problems that result when people edit there rather than > in local working copies. Once you actually start using the features of > a distributed version control system in the way it''s intended to work, > you won''t have those problems. > > >That''s exactly what I told them. There''s best practices, and then there''s current reality. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Thu, Sep 1, 2011 at 1:35 PM, Steven VanDevender <stevev@uoregon.edu>wrote:> Douglas Garstang writes: > > Was that in reply to my original post, or a subsequent reply? You did > see > > where I said /etc/puppet was a working copy, right? > > It sounds like you need to get to the point where no one does their > edits under /etc/puppet on the puppetmaster, because you''re obviously > running into the problems that result when people edit there rather than > in local working copies. Once you actually start using the features of > a distributed version control system in the way it''s intended to work, > you won''t have those problems. > >Editing files locally under /etc/puppet as an individual user is not mutually exclusive with editing files in a distributed working copy owned by the same user. 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Douglas Garstang writes: > On Thu, Sep 1, 2011 at 1:35 PM, Steven VanDevender <stevev@uoregon.edu>wrote: > > > Douglas Garstang writes: > > > Was that in reply to my original post, or a subsequent reply? You did > > see > > > where I said /etc/puppet was a working copy, right? > > > > It sounds like you need to get to the point where no one does their > > edits under /etc/puppet on the puppetmaster, because you''re obviously > > running into the problems that result when people edit there rather than > > in local working copies. Once you actually start using the features of > > a distributed version control system in the way it''s intended to work, > > you won''t have those problems. > > Editing files locally under /etc/puppet as an individual user is not > mutually exclusive with editing files in a distributed working copy owned by > the same user. Except, of course, that editing the working copy under /etc/puppet causes problems and editing a working copy somewhere else doesn''t (assuming you''re otherwise using proper version control procedures). If your process is broken, you have to fix it. Everyone on your system administration team has to agree to use the same proper processes for their work. -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Sep 1, 2011, at 2:01 PM, Douglas Garstang wrote:> > Editing files locally under /etc/puppet as an individual user is not mutually exclusive with editing files in a distributed working copy owned by the same user.If it''s not, then there''s no point in asking for help: your environment is screwed and there is nothing anyone here can do about it other than suggest that we can''t help you until you help yourself. The nice thing about "current reality" is that it''s generally easy to point out why it sucks and why it needs to be fixed. If you team can''t handle change, then either *you* need to accept that status quo, or else you should find another team to work with. The only solution to your problem is to fix the problem. Pointing in other directions and saying "that doesn''t work in my current environment" is the moral equivalent of asking for help and then immediately sticking your fingers in your ears and yelling "LALALALALALALAICAN''THEARYOU". -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[image: 6a012876c6c7fb970c014e88d6f658970d-800wi.png] On Thu, Sep 1, 2011 at 2:09 PM, Brian Gallew <geek@gallew.org> wrote:> > On Sep 1, 2011, at 2:01 PM, Douglas Garstang wrote: > > > > > Editing files locally under /etc/puppet as an individual user is not > mutually exclusive with editing files in a distributed working copy owned by > the same user. > > If it''s not, then there''s no point in asking for help: your environment is > screwed and there is nothing anyone here can do about it other than suggest > that we can''t help you until you help yourself. The nice thing about > "current reality" is that it''s generally easy to point out why it sucks and > why it needs to be fixed. If you team can''t handle change, then either > *you* need to accept that status quo, or else you should find another team > to work with. The only solution to your problem is to fix the problem. > Pointing in other directions and saying "that doesn''t work in my current > environment" is the moral equivalent of asking for help and then immediately > sticking your fingers in your ears and yelling > "LALALALALALALAICAN''THEARYOU". > > -- > 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+unsubscribe@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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hello, Steven VanDevender wrote,> Douglas Garstang writes: > > On Thu, Sep 1, 2011 at 1:35 PM, Steven VanDevender <stevev@uoregon.edu>wrote: > > > > > Douglas Garstang writes: > > > > Was that in reply to my original post, or a subsequent reply? You did > > > see > > > > where I said /etc/puppet was a working copy, right? > > > > > > It sounds like you need to get to the point where no one does their > > > edits under /etc/puppet on the puppetmaster, because you''re obviously > > > running into the problems that result when people edit there rather than > > > in local working copies. Once you actually start using the features of > > > a distributed version control system in the way it''s intended to work, > > > you won''t have those problems. > > > > Editing files locally under /etc/puppet as an individual user is not > > mutually exclusive with editing files in a distributed working copy owned by > > the same user. > > Except, of course, that editing the working copy under /etc/puppet > causes problems and editing a working copy somewhere else doesn''t > (assuming you''re otherwise using proper version control procedures). > > If your process is broken, you have to fix it. Everyone on your system > administration team has to agree to use the same proper processes for > their work.At my place, we do something like below: - Puppet master manifests are hosted in svn repo - A change review process using bugzilla. A peer has to "ack" the bug containing the diff. The rules of peer review is "common sense" :) - All SVN commits have to refer the associated Bugzilla ticket. Svn commit emails is lined to bugzilla to make it easier - The SVN is checked out every 1min on a node under /home/puppet - This node uses atomic-rsync to replicate the directory into every puppet master, we have one per colo at this time. - The local colo puppet master use --confdir=/home/puppet at startup The only pending todo is to have a pre-commit svn hook which does puppet --parseonly. Otherwise, things have been very manageable as far as accountability is concerned. The team which actually does commits is around 10 so far. Hth. -- http://shankerbalan.net/ -- 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+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.