Jira (PUP-6554) Can't run puppet resource on agent with environment specified in main section

50 views
Skip to first unread message

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:33:04 AM7/27/16
to puppe...@googlegroups.com
Paul Anderson created an issue
 
Puppet / Bug PUP-6554
Can't run puppet resource on agent with environment specified in main section
Issue Type: Bug Bug
Assignee: Unassigned
Created: 2016/07/27 6:32 AM
Priority: Normal Normal
Reporter: Paul Anderson
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v6.4.13#64028-sha1:b7939e9)
Atlassian logo

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:34:05 AM7/27/16
to puppe...@googlegroups.com

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:49:04 AM7/27/16
to puppe...@googlegroups.com
Paul Anderson updated an issue
 
Change By: Paul Anderson
Affects Version/s: PUP 4.5.2
Environment: 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 satisfaction
CS Impact: When these three things are true, the customer can't use puppet client commands on their nodes as expected:
1. Code manager with separate environments
2. Nodes in an environment other than production
3. Mcollective in use
4. environment=[non-production] specified in [main] section of puppet.conf


The have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work.
Component/s: Breaking Change
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 client, 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 lies about the 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 { 'puppet':
  ensure => 'running',
  enable => 'true',
}

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. 

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:53:03 AM7/27/16
to puppe...@googlegroups.com
Paul Anderson updated an issue
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 client, 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  lies about  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 { 'puppet':
  ensure => 'running',
  enable => 'true',
}

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. 

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:56:03 AM7/27/16
to puppe...@googlegroups.com

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:57:03 AM7/27/16
to puppe...@googlegroups.com
Paul Anderson updated an issue
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  client  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 { 'puppet':
  ensure => 'running',
  enable => 'true',
}

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. 

Paul Anderson (JIRA)

unread,
Jul 27, 2016, 9:58:03 AM7/27/16
to puppe...@googlegroups.com
Paul Anderson updated an issue
Change By: Paul Anderson
CS Impact: When these  three  four  things are true, the customer can't use puppet client commands on their nodes as expected:

1. Code manager with separate environments
2. Nodes in an environment other than production
3. Mcollective in use
4. environment=[non-production] specified in [main] section of puppet.conf

The have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work.

Henrik Lindberg (JIRA)

unread,
Jul 27, 2016, 10:11:03 AM7/27/16
to puppe...@googlegroups.com

Paul Anderson (JIRA)

unread,
Jul 29, 2016, 12:53:05 PM7/29/16
to puppe...@googlegroups.com
Paul Anderson updated an issue
Change By: Paul Anderson
CS Impact: When these four things are true, the  customer  user  can't use puppet client commands on their nodes as expected:

1. Code manager with separate environments
2. Nodes in an environment other than production
3. Mcollective in use
4. environment=[non-production] specified in [main] section of puppet.conf

The have to do mental gymnastics to understand why they must add --environment production to every puppet help, puppet resource, etc. command to make it work.

David Kramer (JIRA)

unread,
Aug 31, 2016, 12:21:06 PM8/31/16
to puppe...@googlegroups.com
David Kramer updated an issue
Change By: David Kramer
Sprint: Client Triage
This message was sent by Atlassian JIRA (v6.4.14#64029-sha1:ae256fe)
Atlassian logo

David Kramer (JIRA)

unread,
Aug 31, 2016, 12:23:02 PM8/31/16
to puppe...@googlegroups.com
David Kramer commented on Bug PUP-6554
 
Re: Can't run puppet resource on agent with environment specified in main section

This behavior seems unexpected. We should figure out what is going on here and determine whether this needs to be better documented or if there is an issue to be fixed in the code.

Vadym Chepkov (JIRA)

unread,
Aug 31, 2016, 12:32:02 PM8/31/16
to puppe...@googlegroups.com
Vadym Chepkov commented on Bug PUP-6554

I want to chime in with some additional information.

We have to set 'environment' in [main] section, along with 'certname' and 'server', which under normal circumstances would be only relevant for an agent. But, pe-mcollective-metadata script (/opt/puppetlabs/puppet/bin/refresh-mcollective-metadata) doesn't use 'agent' section, it uses 'main', so if you have (like we do) facts based on any of those 3 settings, they will be out-of-sync, different from what agent sees, so we can't use any mco filters based on these facts.

Kenn Hussey (JIRA)

unread,
Sep 29, 2016, 2:59:14 PM9/29/16
to puppe...@googlegroups.com

Nicholas Fagerlund (JIRA)

unread,
May 16, 2017, 4:46:04 PM5/16/17
to puppe...@googlegroups.com

Nicholas Fagerlund (JIRA)

unread,
May 16, 2017, 4:51:03 PM5/16/17
to puppe...@googlegroups.com
Nicholas Fagerlund commented on Bug PUP-6554
 
Re: Can't run puppet resource on agent with environment specified in main section

In my judgment, this is a legit misbehavior, and we should fix it at some point. IDK if the way the code is laid out makes this complex, but conceptually, the fix is simple:

  • If non-default environment is set BUT is nonexistent: Puppet resource should switch to production environment (silent except for debug messages) and continue. Use case: normal puppet agent nodes that don't have r10k deploys, where puppet resource should only load custom types from the agent libdir.
  • If a non-default environment is set AND that environment exists, Puppet resource should go ahead and use that environment. (This is what it always does now.) Use case: standalone puppet apply nodes that have a full r10k deploy present, where puppet resource should load custom types from modules.

I think that combination of behaviors covers all use cases, wouldn't surprise any users, and would never do any meaningfully wrong things.

Nicholas Fagerlund (JIRA)

unread,
May 16, 2017, 4:52:03 PM5/16/17
to puppe...@googlegroups.com

Nicholas Fagerlund (JIRA)

unread,
May 16, 2017, 4:52:04 PM5/16/17
to puppe...@googlegroups.com

Paul Anderson (JIRA)

unread,
May 16, 2017, 5:00:09 PM5/16/17
to puppe...@googlegroups.com
Paul Anderson commented on Bug PUP-6554
 
Re: Can't run puppet resource on agent with environment specified in main section

Nicholas Fagerlund,

I've been watching traffic on this issue and related tickets for awhile. I'd like to point out two distinctions that I think the team would do well to be aware of:

1. The current behavior is a stack trace. That's bad and should get some sort of immediate triage. The tool should at least exit gracefully with an error message

2. Once that initial fatal error is resolved, then yes, the tool should work as it had previously done. Having an environment set (so as to not get the warning in your logs) and then running a local puppet command (where the environment directory doesn't exist) shouldn't be a problem.

Josh Cooper (JIRA)

unread,
Nov 30, 2017, 7:15:02 PM11/30/17
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-6554

Setting environment in the main section is a problem, because the setting controls different behavior depending on which application you're running. PUP-6739 will now generate a warning if you don't specify a section when setting the environment to prevent people from getting into this bad state.

We also no longer raise a fatal error if the environment doesn't exist when running puppet config or puppet help.

However, puppet resource may rely on types from modules in the current environment, so we really do need a valid environment to be specified. We should more gracefully handle when the get! call raises to indicate an environment with that name wasn't found. Most likely the environment setting needs to be moved to the agent section instead of main.

This message was sent by Atlassian JIRA (v7.0.2#70111-sha1:88534db)
Atlassian logo

Josh Cooper (JIRA)

unread,
Mar 16, 2018, 4:26:04 PM3/16/18
to puppe...@googlegroups.com
Josh Cooper updated an issue
 
Change By: Josh Cooper
Sub-team: Coremunity
This message was sent by Atlassian JIRA (v7.7.1#77002-sha1:e75ca93)
Atlassian logo

Josh Cooper (Jira)

unread,
Jun 5, 2020, 6:09:02 PM6/5/20
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Epic Link: PUP- 7563 10539
This message was sent by Atlassian Jira (v8.5.2#805002-sha1:a66f935)
Atlassian logo

Josh Cooper (Jira)

unread,
Oct 3, 2020, 12:44:03 AM10/3/20
to puppe...@googlegroups.com
Josh Cooper commented on Bug PUP-6554
 
Re: Can't run puppet resource on agent with environment specified in main section

We should probably warn if puppet config set environment is set in something other than agent, as it will cause problems when trying to run other puppet commands

Ciprian Badescu (Jira)

unread,
Jun 16, 2021, 4:55:01 AM6/16/21
to puppe...@googlegroups.com
Ciprian Badescu updated an issue
 
Change By: Ciprian Badescu
Story Points: 2
This message was sent by Atlassian Jira (v8.13.2#813002-sha1:c495a97)
Atlassian logo

Gabriel Nagy (Jira)

unread,
Jun 17, 2021, 12:27:03 PM6/17/21
to puppe...@googlegroups.com

Josh Cooper (Jira)

unread,
Jun 29, 2021, 2:41:02 PM6/29/21
to puppe...@googlegroups.com

Josh Cooper (Jira)

unread,
Jun 29, 2021, 2:41:02 PM6/29/21
to puppe...@googlegroups.com
Josh Cooper updated an issue
Change By: Josh Cooper
Fix Version/s: PUP 7.9.0
Fix Version/s: PUP 6.24.0

Ciprian Badescu (Jira)

unread,
Jun 30, 2021, 5:07:03 AM6/30/21
to puppe...@googlegroups.com

Josh Cooper (Jira)

unread,
Jul 2, 2021, 12:28:03 PM7/2/21
to puppe...@googlegroups.com

Claire Cadman (Jira)

unread,
Jul 13, 2021, 7:51:04 AM7/13/21
to puppe...@googlegroups.com
Reply all
Reply to author
Forward
0 new messages