Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
PUP 4.5.2
-
None
-
RHEL 7 Master and Agent
Copy default production environment to "development"
Have console refresh modules
Create development environment group in classifier, pin the agent
Configure agent to include "environment = development" in the main section of puppet.conf
Do puppet runs to everyones satisfactionRHEL 7 Master and Agent Copy default production environment to "development" Have console refresh modules Create development environment group in classifier, pin the agent Configure agent to include "environment = development" in the main section of puppet.conf Do puppet runs to everyones satisfaction
-
Night's Watch
-
2
-
NW - 2021-06-30, NW - 2021-07-14
-
Normal
-
2 - 5-25% of Customers
-
2 - Annoyance
-
1 - ?
-
-
Bug Fix
-
Previously, running `puppet resource` with an invalid environment would fail the run. Now, the application will fall back to the default environment if the given one does not exist.
Description
See also https://tickets.puppetlabs.com/browse/PUP-6048
Given a traditional Prod, Dev, Test scenario, and a desire to use MCollective
Given the desire to configure an environment in the agent's puppet.conf to cut down on log messages
Given the need to put the environment setting in [main] and not [agent] so that MCollective also knows the environment
If one manually runs puppet commands on a non-production node, such as puppet resource, one gets an error:
[root@dev-node ~]# puppet resource service puppet ensure=running enable=true
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in `get!': Could not find a directory environment named 'development' anywhere in the path: /etc/puppetlabs/code/environments. Does the directory exist? (Puppet::Environments::EnvironmentNotFound)
from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in `push_application_context'
from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:337:in `run'
from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:128:in `run'
from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in `execute'
from /usr/local/bin/puppet:5:in `<main>'
However, if one impersonates the production environment, it works as expected:
[root@dev-node ~]# puppet resource service puppet ensure=running enable=true --environment production
Notice: /Service[puppet]/ensure: ensure changed 'stopped' to 'running'
service
This inconsistency is frustrating to customers, regardless of the reasoning behind it. It requires retraining of their staff doing manual operations and lots of comments in their cron jobs, etc.