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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
