Hi All, In our environment, we use the $::environment variable extensively to determine if the host should have one set of mounts (e.g. production) or a different set of mounts (e.g. qa). This is just one example, but there are many others where the $::environment variable comes into play. The problem is that I have a number of puppet changes that I want to test before merging into the production tree, so I''ve created a staging environment.... however, given the importance of the $::environment variable throughout the manifests, this won''t work well. Any suggestions? I''d like to point a number of production nodes at a secondary puppet server using --noop to see what would change, but then I run into SSL issues. Would be great if I could use puppet over cleartext http for this test, but I''m not sure if that''s possible. Thanks in advance for any feedback. Gonzalo -- 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 19/09/12 06:11, Gonzalo Servat wrote:> Hi All, > > In our environment, we use the $::environment variable extensively to > determine if the host should have one set of mounts (e.g. production) > or a different set of mounts (e.g. qa). This is just one example, but > there are many others where the $::environment variable comes into play. > > The problem is that I have a number of puppet changes that I want to > test before merging into the production tree, so I''ve created a > staging environment.... however, given the importance of the > $::environment variable throughout the manifests, this won''t workI think the only way to get around this problem is to copy $::environment to $::my_environment or some such, and then change all the references to use $::my_environment. Then you could have a selective case in ''staging'' where it forcefully sets $my_environment to either ''prod'' or ''qa'' in your case.> Any suggestions? I''d like to point a number of production nodes at a > secondary puppet server using --noop to see what would change, but > then I run into SSL issues. Would be great if I could use puppet over > cleartext http for this test, but I''m not sure if that''s possible. >If you set up a second Puppet Master and synchronise the CA and all the signed certificates from your primary to your "slave" Master, it should work. I would forcefully turn certificate signing off on your "slave" in puppet.conf. Dan Bode wrote a great article ages ago about multi-master Puppet which you might want to reference: http://bodepd.com/wordpress/?p=7> Thanks in advance for any feedback. > Gonzalo > -- > 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.-- Luke Bigum Senior Systems Engineer Information Systems Ph: +44 (0) 20 3192 2520 luke.bigum@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved. The information in this email is not directed at residents of the United States of America or any other jurisdiction where trading in CFDs and/or FX is restricted or prohibited by local laws or regulations. The information in this email and any attachment is confidential and is intended only for the named recipient(s). The email may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not the intended recipient please notify the sender immediately and delete any copies of this message. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. LMAX operates a multilateral trading facility. Authorised and regulated by the Financial Services Authority (firm registration number 509778) and is registered in England and Wales (number 06505809). Our registered address is Yellow Building, 1A Nicholas Road, London, W11 4AN. -- 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 Wednesday, September 19, 2012 12:11:24 AM UTC-5, Gonzalo wrote:> > Hi All, > > In our environment, we use the $::environment variable extensively to > determine if the host should have one set of mounts (e.g. production) or a > different set of mounts (e.g. qa). This is just one example, but there are > many others where the $::environment variable comes into play. > > The problem is that I have a number of puppet changes that I want to test > before merging into the production tree, so I''ve created a staging > environment.... however, given the importance of the $::environment > variable throughout the manifests, this won''t work well. > > Any suggestions? I''d like to point a number of production nodes at a > secondary puppet server using --noop to see what would change, but then I > run into SSL issues. Would be great if I could use puppet over cleartext > http for this test, but I''m not sure if that''s possible. >I tend to think that the $::environment fact is not a very good choice for testing your Puppet configuration, for pretty much the reason you already described. Setting up a secondary master for testing is exactly what I would recommend. There are a number of ways that you could work out the SSL issues. The brute force way, for example, would involve synchronizing the masters'' SSL directories (both directions), and probably playing some games with name servers. It would be more elegant to set up a central CA on which the masters and clients all rely, though synchronization of client certs between the masters would probably still be needed. In a pinch, you might be able to enlist your existing production master as the central CA. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/k0EStMzrmB0J. 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.
Use heira. Heira can load a config file based on the environment. Setting this up is as simple as creating a hiera definition such as... (environment).yaml ... And then creating the following files: production.yaml and staging.yaml that contain your environment specific configs. Install the puppet-hiera gem, then you can lookup the appropriate command inside puppet using heira_lookup(param_name). For an example, checkout the vagrant-hiera project on github. If your unfamiliar with vagrant, you''ll need to install that to run the example. It''s a great tool for doing local puppet testing. Even if you don''t want to install vagrant, looking at the source of that project will show you a quick example of how to use hiera. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/YlJx3dHegBsJ. 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.
Hi All,
Thanks for your feedback. While writing the original email, the subject
sounded familiar and that''s because I had written about it in the past:
https://groups.google.com/d/topic/puppet-users/twLhIwsCRu4/discussion
Apologies to those involved in the other thread for not replying, but thank
you for your feedback. I ended up doing what Pablo F suggested, which is to
run a puppetmasterd instance as a user, that way I use a copy of the
/var/lib/puppet directory and the certificates work fine.
Glenn, I like the hiera idea (currently I''m using extlookup) but I
think I
would run into the same problem. In some of my erb templates, settings are
set depending on the environment. For example, in my.cnf (for MySQL), we
set the innodb buffer pool size to different sizes depending on the
environment. How would I set specific settings depending on the environment
here?
Cheers
Gonzalo
On Thu, Sep 20, 2012 at 8:04 AM, Glenn Poston <gposton1040@gmail.com>
wrote:
> Use heira. Heira can load a config file based on the environment.
> Setting this up is as simple as creating a hiera definition such as...
>
> (environment).yaml
>
> ... And then creating the following files: production.yaml and
> staging.yaml that contain your environment specific configs.
>
> Install the puppet-hiera gem, then you can lookup the appropriate command
> inside puppet using heira_lookup(param_name).
>
> For an example, checkout the vagrant-hiera project on github. If your
> unfamiliar with vagrant, you''ll need to install that to run the
example.
> It''s a great tool for doing local puppet testing. Even if you
don''t want
> to install vagrant, looking at the source of that project will show you a
> quick example of how to use hiera.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/YlJx3dHegBsJ.
> 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 9/19/12 4:53 PM, Gonzalo Servat wrote:> Hi All, > > Thanks for your feedback. While writing the original email, the subject > sounded familiar and that''s because I had written about it in the past: > > https://groups.google.com/d/topic/puppet-users/twLhIwsCRu4/discussion > > Apologies to those involved in the other thread for not replying, but > thank you for your feedback. I ended up doing what Pablo F suggested, > which is to run a puppetmasterd instance as a user, that way I use a > copy of the /var/lib/puppet directory and the certificates work fine.No need at all to use a different puppet master, you could just use environments[1]. When you want to test a system again a different environment, staging in this example, you can run `puppet agent -t --environment=staging`.> Glenn, I like the hiera idea (currently I''m using extlookup) but I think > I would run into the same problem. In some of my erb templates, settings > are set depending on the environment. For example, in my.cnf (for > MySQL), we set the innodb buffer pool size to different sizes depending > on the environment. How would I set specific settings depending on the > environment here? > > Cheers > GonzaloHiera[2] is meant to solve this. You might have staging.yaml and production.yaml that specify values for mysql_innodb_buffer_pool_size. In your code you could have $innodb_buffer_pool_size = hiera(''mysql_innodb_buffer_pool_size'') and then use <%= innodb_buffer_pool_size %> in a template for your my.cnf. -g [1] - http://docs.puppetlabs.com/guides/environment.html [2] - https://github.com/puppetlabs/hiera-puppet/blob/master/README.md -- Garrett Honeycutt 206.414.8658 http://puppetlabs.com -- 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 20, 2012 at 3:37 PM, Garrett Honeycutt <garrett@puppetlabs.com>wrote:> No need at all to use a different puppet master, you could just use > environments[1]. When you want to test a system again a different > environment, staging in this example, you can run `puppet agent -t > --environment=staging`. >Yep, I need to move towards this. I guess this means I need to go through all my templates and put hiera variables for everything.> Hiera[2] is meant to solve this. You might have staging.yaml and > production.yaml that specify values for mysql_innodb_buffer_pool_size. > > In your code you could have > > $innodb_buffer_pool_size = hiera(''mysql_innodb_buffer_pool_size'') > > and then use <%= innodb_buffer_pool_size %> in a template for your my.cnf. >Can one call hiera() from within the ERB templates? - Gonzalo -- 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 20, 2012 at 3:37 PM, Garrett Honeycutt <garrett@puppetlabs.com>wrote:> Hiera[2] is meant to solve this. You might have staging.yaml and > production.yaml that specify values for mysql_innodb_buffer_pool_size. >Another scenario I''ve found is that we also add certain users if $::environment is production, and a different set of users if it''s qa, etc. How would you work with that using hiera? One idea that comes to mind is that within hiera I set a special environment variable called $::env or something, which is what I would evaluate instead of $::environment, that way I can have any puppet environment setting $::env to whatever I want. - Gonzalo -- 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 9/19/12 10:43 PM, Gonzalo Servat wrote:> On Thu, Sep 20, 2012 at 3:37 PM, Garrett Honeycutt > <garrett@puppetlabs.com <mailto:garrett@puppetlabs.com>> wrote: > > No need at all to use a different puppet master, you could just use > environments[1]. When you want to test a system again a different > environment, staging in this example, you can run `puppet agent -t > --environment=staging`. > > > Yep, I need to move towards this. I guess this means I need to go > through all my templates and put hiera variables for everything. > > > Hiera[2] is meant to solve this. You might have staging.yaml and > production.yaml that specify values for mysql_innodb_buffer_pool_size. > > In your code you could have > > $innodb_buffer_pool_size = hiera(''mysql_innodb_buffer_pool_size'') > > and then use <%= innodb_buffer_pool_size %> in a template for your > my.cnf. > > > Can one call hiera() from within the ERB templates? > > - GonzaloNo, you call it from the manifests. Recommend reading the hiera documentation. Also you can see an example with my dnsclient module[1]. [1] - https://github.com/ghoneycutt/puppet-dnsclient/tree/new_design_pattern_with_hiera -g -- Garrett Honeycutt 206.414.8658 http://puppetlabs.com -- 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 seem to be missing something here. The OP''s problem is that part of what he wants to test is his code''s environment-dependent behavior. I maintain that no solution requiring a different environment to be declared than the one he wants to test can in fact test such behavior adequately. I don''t see how hiera into the mix changes that in any way. The same considerations apply to a lesser extent to using some different data to distingish environment-A-testing from environment-A-production: when you want to transition the test code and data to production, it can really be quite tricky to make the latter act exactly as the former did, but when fed with different data. Environments are fine for a lot of things, including configuring test environments for other software, but they are not so good for testing Puppet itself. I maintain that the best approach is to stand up test manifests and data in a separate master, leveraging your SCM system to put that code and data into production when the time comes. That way you can be confident that you have tested the scenarios that will actually be encountered when your code goes live. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/2P1W_Br_FpYJ. 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.