Hello, I have a production puppet environment that is working well. Now more people are developing modules for it we are using a test environment using environment=test in the puppet.conf file. This prevents changes to modules in the production environment being affected by changes in the test environment. So far so good. By module I mean class, in case it''s the wrong class. 1. I need to test a change to a single module on a production server, without breaking all other production servers. I could put this single production server into the test environment, but this has the danger of pulling in changes from other people''s modules as well. Should I create yet another environment to do this? 2. Can I define certain modules as being taken from another environment, the "test" environment, for example? Thanks in advance, -- James Patterson jamespatterson@operamail.com -- http://www.fastmail.fm - Same, same, but different... -- 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.
James, If the modules are in your modulepath and environments are defined in puppet.conf, you can actually use puppet apply to declare classes from the command line. For example, if you just wanted to test the nginx::config class you could run: puppet apply -v -e ''include nginx::config'' This (specifically the -e flag with the code you want to pass in quotes) allows you to ''test'' a specific class out-of-band from your regular Puppet runs. DO NOTE, HOWEVER, that ''test'' in this sense means that it will ACTUALLY DECLARE THE CLASS AND PERFORM THE ACTION! If this is not what you want, you''ll still need to add the --noop flag to SIMULATE the code. You can also create individual files in your modules ''tests'' directory and declare them with puppet apply too (if you need more than just one line to test your code - a la Defined Resource Types). Note that you can ALSO pass the environment from the command line with ''--environment test''. Does this help? On Thu, Apr 12, 2012 at 7:00 AM, James Patterson < jamespatterson@operamail.com> wrote:> Hello, > > I have a production puppet environment that is working well. > > Now more people are developing modules for it we are using a test > environment using environment=test in the puppet.conf file. > This prevents changes to modules in the production environment being > affected by changes in the test environment. So far so good. > > By module I mean class, in case it''s the wrong class. > > 1. I need to test a change to a single module on a production server, > without breaking all other production servers. > I could put this single production server into the test environment, but > this has the danger of pulling in changes from other people''s modules as > well. > Should I create yet another environment to do this? > > 2. Can I define certain modules as being taken from another environment, > the "test" environment, for example? > > Thanks in advance, > > -- > James Patterson > jamespatterson@operamail.com > > -- > http://www.fastmail.fm - Same, same, but different... > > -- > 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. > >-- Gary Larizza Professional Services Engineer Puppet Labs -- 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.
Thanks for your reply. I do not have reliable access to an internet connection at the moment. Just to flesh out my problem a bit more: I need to update my sendmail module, but want to test it first. I have two puppet environments (dev and prod), but mail is critical in both. Ideally I would choose a single host on which to test if my changes worked, then push it everywhere if everything works. I tried your puppet apply command, but this failed (probably because I only have the modules on the puppet master, and modulepath is empty). Copying the puppet module to a specific host seems like I am going in the wrong direction. I considered adding testing flag to my module, which would pull in "module::testing" instead of "module", but this seems hacky and a replacement for versioning (does puppet do module versioning?). So I suppose I am asking for a nicer way to do what you suggest, or am I approaching this from the wrong direction? Thanks. -- James Patterson [1]jamespatterson@operamail.com On Thu, Apr 12, 2012, at 10:10 AM, Gary Larizza wrote: James, If the modules are in your modulepath and environments are defined in puppet.conf, you can actually use puppet apply to declare classes from the command line. For example, if you just wanted to test the nginx::config class you could run: puppet apply -v -e ''include nginx::config'' This (specifically the -e flag with the code you want to pass in quotes) allows you to ''test'' a specific class out-of-band from your regular Puppet runs. DO NOTE, HOWEVER, that ''test'' in this sense means that it will ACTUALLY DECLARE THE CLASS AND PERFORM THE ACTION! If this is not what you want, you''ll still need to add the --noop flag to SIMULATE the code. You can also create individual files in your modules ''tests'' directory and declare them with puppet apply too (if you need more than just one line to test your code - a la Defined Resource Types). Note that you can ALSO pass the environment from the command line with ''--environment test''. Does this help? On Thu, Apr 12, 2012 at 7:00 AM, James Patterson <[2]jamespatterson@operamail.com> wrote: Hello, I have a production puppet environment that is working well. Now more people are developing modules for it we are using a test environment using environment=test in the puppet.conf file. This prevents changes to modules in the production environment being affected by changes in the test environment. So far so good. By module I mean class, in case it''s the wrong class. 1. I need to test a change to a single module on a production server, without breaking all other production servers. I could put this single production server into the test environment, but this has the danger of pulling in changes from other people''s modules as well. Should I create yet another environment to do this? 2. Can I define certain modules as being taken from another environment, the "test" environment, for example? Thanks in advance, -- James Patterson [3]jamespatterson@operamail.com -- [4]http://www.fastmail.fm - Same, same, but different... -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to [5]puppet-users@googlegroups.com. To unsubscribe from this group, send email to [6]puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at [7]http://groups.google.com/group/puppet-users?hl=en. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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. References 1. mailto:jamespatterson@operamail.com 2. mailto:jamespatterson@operamail.com 3. mailto:jamespatterson@operamail.com 4. http://www.fastmail.fm/ 5. mailto:puppet-users@googlegroups.com 6. mailto:puppet-users%2Bunsubscribe@googlegroups.com 7. http://groups.google.com/group/puppet-users?hl=en -- http://www.fastmail.fm - Send your email first class -- 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.
In your situation I would set up a virtual machine on my laptop where I would merrily munge mail service at will. (Or a VM anywhere else for similar fun.) If you break something you can roll back to your known good snapshot and try again. On Mon, Apr 23, 2012 at 06:10:59AM -0700, James Patterson wrote:> Thanks for your reply. I do not have reliable access to an internet > connection at the moment. > > Just to flesh out my problem a bit more: I need to update my sendmail > module, but want to test it first. I have two puppet environments (dev and > prod), but mail is critical in both. Ideally I would choose a single host > on which to test if my changes worked, then push it everywhere if > everything works. > > I tried your puppet apply command, but this failed (probably because I > only have the modules on the puppet master, and modulepath is empty). > Copying the puppet module to a specific host seems like I am going in the > wrong direction. > > I considered adding testing flag to my module, which would pull in > "module::testing" instead of "module", but this seems hacky and a > replacement for versioning (does puppet do module versioning?). > > So I suppose I am asking for a nicer way to do what you suggest, or am I > approaching this from the wrong direction? > > Thanks. > > -- > James Patterson > [1]jamespatterson@operamail.com > > > On Thu, Apr 12, 2012, at 10:10 AM, Gary Larizza wrote: > > James, > > If the modules are in your modulepath and environments are defined in > puppet.conf, you can actually use puppet apply to declare classes from > the command line. For example, if you just wanted to test the > nginx::config class you could run: puppet apply -v -e ''include > nginx::config'' This (specifically the -e flag with the code you want > to pass in quotes) allows you to ''test'' a specific class out-of-band > from your regular Puppet runs. DO NOTE, HOWEVER, that ''test'' in this > sense means that it will ACTUALLY DECLARE THE CLASS AND PERFORM THE > ACTION! If this is not what you want, you''ll still need to add the > --noop flag to SIMULATE the code. You can also create individual files > in your modules ''tests'' directory and declare them with puppet apply too > (if you need more than just one line to test your code - a la Defined > Resource Types). Note that you can ALSO pass the environment from the > command line with ''--environment test''. > > Does this help? > > On Thu, Apr 12, 2012 at 7:00 AM, James Patterson > <[2]jamespatterson@operamail.com> wrote: > > Hello, > > I have a production puppet environment that is working well. > > Now more people are developing modules for it we are using a test > environment using environment=test in the puppet.conf file. > This prevents changes to modules in the production environment being > affected by changes in the test environment. So far so good. > > By module I mean class, in case it''s the wrong class. > > 1. I need to test a change to a single module on a production server, > without breaking all other production servers. > I could put this single production server into the test environment, > but > this has the danger of pulling in changes from other people''s modules > as > well. > Should I create yet another environment to do this? > > 2. Can I define certain modules as being taken from another > environment, > the "test" environment, for example? > > Thanks in advance, > > -- > James Patterson > [3]jamespatterson@operamail.com > > -- > [4]http://www.fastmail.fm - Same, same, but different... > > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to [5]puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > [6]puppet-users+unsubscribe@googlegroups.com. > For more options, visit this group at > [7]http://groups.google.com/group/puppet-users?hl=en. > > > > -- > > Gary Larizza > Professional Services Engineer > Puppet Labs > > > > -- > 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://www.fastmail.fm - Send your email first class > > -- > 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. > > References > > Visible links > 1. mailto:jamespatterson@operamail.com > 2. mailto:jamespatterson@operamail.com > 3. mailto:jamespatterson@operamail.com > 4. http://www.fastmail.fm/ > 5. mailto:puppet-users@googlegroups.com > 6. mailto:puppet-users%2Bunsubscribe@googlegroups.com > 7. 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.