Environments: Limitations of environments
Included in Puppet Enterprise 2016.2. A newer version is available; see the version menu above for details.
Environments solve a lot of problems in a convenient way, but they still have some limitations. Some of these are just features Puppet doesn’t have yet, and some of them are outside Puppet’s control. We want to fix all of them, but some may take a lot longer than others.
Plugins running on the Puppet master are weird
Puppet modules can contain Puppet code, templates, file sources, and Ruby plugin code (in the
lib directory). Environments work perfectly with most of those, but there’s a lingering problem with plugins.
The short version is: any plugins destined for the agent node (e.g. custom facts and custom resource providers) will work fine, but plugins to be used by the Puppet master (functions, resource types, report processers, indirector termini) can get mixed up, and you won’t be able to control which version the Puppet master is using. So if you need to do testing while developing custom resource types or functions, you may need to spin up a second Puppet master, since environments won’t be reliable.
This has to do with the way Ruby loads code, and we’re not sure if it can be fixed given Puppet’s current architecture. (Some of us think this would require separate Ruby Puppet master processes for each environment, which isn’t currently practical with the way Rack manages Puppet.)
If you’re interested in the issue, it’s being tracked as PUP-731.
For best performance, you might have to change your deploy process
The default value of the
environment_timeout setting has to be
0, because anything else risks frustrating new users. The only problem with that value is that it wastes a lot of effort on your Puppet master.
For best performance, you should set
environment_timeout = unlimited, but this requires a change to your code deployment process, because you’ll need to refresh the Puppet master to make it notice the new code.
For more info, see the timeout section of the Configuring Environments page.
Hiera configuration can’t be specified per environment
Puppet will only use a global hiera.yaml file; you can’t put per-environment configs in an environment directory.
When using the built-in YAML or JSON backends, it is possible to separate your Hiera data per environment; you will need to interpolate the
$environment variable into the
:datadir setting. (e.g.
Exported resources can conflict or cross over
Nodes in one environment can accidentally collect resources that were exported from another environment, which causes problems — either a compilation error due to identically titled resources, or creation and management of unintended resources.
Right now, the only solution is to run multiple Puppet masters if you heavily use exported resources. We’re working on making PuppetDB environment-aware, which will fix the problem in a more permanent way.