I would like to delegate access to puppet to other teams in our company. It has to be possible for them to: - create new recipes - doing some sort of check if their recipes / templates work. How should I do this without giving other teams the ability to create havoc? -- 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.
Pieter Baele wrote:> I would like to delegate access to puppet to other teams in our company. > > It has to be possible for them to: > - create new recipes > - doing some sort of check if their recipes / templates work. > > How should I do this without giving other teams the ability to create havoc? >Version control potentially combined with Puppet environments works well for this. Cheers James Turnbull -- James Turnbull Puppet Labs 1-503-734-8571 -- 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 Jan 31, 2011 9:10 AM, "James Turnbull" <james@puppetlabs.com> wrote:> Pieter Baele wrote: > > I would like to delegate access to puppet to other teams in our company. > > > > It has to be possible for them to: > > - create new recipes > > - doing some sort of check if their recipes / templates work. > > > > How should I do this without giving other teams the ability to createhavoc?> > > > Version control potentially combined with Puppet environments works well > for this.At my previous job we did this: using a testing environment where the ops team could proof the "code" beforevit went to production, combined with code review worked at our scale. All the changes ended up merged in by an ops team member; today, I would probably use git and pull/merge from the other teams repo. Once you start to trust the other teams not to blow too much up, I would just trust them - but make sure the only route to production is through the *immutable* VCS history, and that everyone knows that. There is a lot of social encouragement not to blow things up when folks know that every change they make can be unambiguously tracked back to them. Regards, Daniel -- Puppet Labs Developer –http://puppetlabs.com Daniel Pittman <daniel@puppetlabs.com> Contact me via gtalk, email, or phone: +1 (877) 575-9775 Sent from a mobile device. Please forgive me if this is briefer than usual. -- 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 Mon, Jan 31, 2011 at 3:05 AM, Pieter Baele <pieter.baele@gmail.com> wrote:> I would like to delegate access to puppet to other teams in our company. > > It has to be possible for them to: > - create new recipes > - doing some sort of check if their recipes / templates work. > > How should I do this without giving other teams the ability to create havoc?As others have said, this is pretty easy to do with environments and modulepaths. You should be able to implement whatever access control your version control system has such that only authorized people can commit to various locations. There are a few gotchas. * Pluginsync will sync all plugins from a given modulepath. For facts, these will all execute. If you have a particularly locked down environment, you may want to implement pre-commit hooks to restrict plugins to a single location that is tightly curated. * It is possible to inherit from a class (or use the ''spaceship'' operator) and override resource declarations. This may not be what you want, and currently pre-commit hooks are the only real way to prevent this (other than tight curation of approvals). http://projects.puppetlabs.com/issues/4627 may be of interest to you. I''ve suggested the idea of being able to disable resources from being overriden, e.g. final class foo { ... } and any resources declared within foo would not be able to be overridden by any means. In any case it sounds like you want some pre-commit hooks to run --parseonly on the manifests to check they parse, and you''re going to want to split up the modulepaths such that different groups have different permissions.> > -- > 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, We are starting to get a lot of modules in our system. I am looking to add a version number to the modules when they are checked out of our revision control system and moved into each environment. Has anyone come up with a standard way/place to store the version number of the module? Also we would want to be able to query the version number in some way to find out which versions are installed on which servers, maybe through facter custom fact. Don''t want to reinvent the wheel if this is already be worked on. -chrisl Christopher Lee -- 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 Mon, Jan 31, 2011 at 11:45 AM, Christopher Lee <chrisl@spiralweb.com> wrote:> Hello, > > We are starting to get a lot of modules in our system. I am looking to add a version number to the modules when they are checked out of our revision control system and moved into each environment. Has anyone come up with a standard way/place to store the version number of the module? Also we would want to be able to query the version number in some way to find out which versions are installed on which servers, maybe through facter custom fact. Don''t want to reinvent the wheel if this is already be worked on.Checkout out puppet-module gem tool used for forge. It supports metadata json file that contains version info. Since this is server side, it will need to be a custom function rather than a fact. If you manage the entire puppet modules in a repository, you might also be interested in the config_version option to log version info. Thanks, Nan -- 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 1 February 2011 08:05, Nan Liu <nan@puppetlabs.com> wrote:> On Mon, Jan 31, 2011 at 11:45 AM, Christopher Lee <chrisl@spiralweb.com> > wrote: >> If you manage the entire puppet modules in a repository, you might > also be interested in the config_version option to log version info. >config_version has issues - especially with environments. I''ve had to abandon using it for the specific case described here. Official ticket is http://projects.puppetlabs.com/issues/3692 (background reading http://projects.puppetlabs.com/issues/3043 & https://projects.puppetlabs.com/issues/4640) John -- 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 1 February 2011 04:29, Nigel Kersten <nigel@puppetlabs.com> wrote: In any case it sounds like you want some pre-commit hooks to run> --parseonly on the manifests to check they parse, and you''re going to > want to split up the modulepaths such that different groups have > different permissions. >parseonly hasn''t been working for 2.6.x - https://projects.puppetlabs.com/issues/5081 Will be fixed when 2.6.5 comes out John -- 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 Jan 31, 3:05 am, Pieter Baele <pieter.ba...@gmail.com> wrote:> - doing some sort of check if their recipes / templates work.A stronger check than --parseonly is to use a tool like cucumber- puppet. It''s very simple to verify that a nodes catalog can actually compile, not just parse. Additionally you can do things like inspect final resources to verify any required parameters. -- 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.