Project

General

Profile

Actions

Bug #2205

closed

Environment doesn't exist in Puppet 3+ facts YAML

Added by Paul O'Connor over 11 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Facts
Target version:
-
Difficulty:
Triaged:
Fixed in Releases:
Found in Releases:

Description

Using Puppet 3 on client nodes results in Foreman setting/overriding the environment set for nodes.

Environment is set properly while using Puppet 2.7


Related issues 1 (1 open0 closed)

Related to Foreman - Feature #15972: Foreman fact name used for 'update_environment_from_facts' should be parametrizableNew08/03/2016Actions
Actions #1

Updated by Dominic Cleal over 11 years ago

  • Subject changed from Environment doesn't exist in Puppet 3+ reports to Environment doesn't exist in Puppet 3+ facts YAML
  • Category changed from External Nodes to Facts
  • Assignee deleted (Ohad Levy)

Paul's setup has enc_environment = false and update_environment_from_facts = true, so the ENC isn't authoritative over the environment, instead the agents are. In Puppet 3, the facts YAML that's stored on the master and uploaded into Foreman via the ENC node.rb doesn't contain the $environment, while on 2.x it did. This means the environment isn't correctly set on the host in Foreman.

The environment is present in the reports, but:
a) we don't set the host's environment from a report
b) it's too late for the ENC process

Almost certainly a puppet bug or change, but it's possible we should also import environment from reports.

Actions #2

Updated by Anonymous almost 11 years ago

just a quick "me too"...
could this be added to 1.2? If not, a possible workaround would also be to establish a custom fact "environment" on Puppet 3.x clients.

Actions #3

Updated by Dominic Cleal almost 11 years ago

  • Target version set to 1.3.0

Michael Moll wrote:

just a quick "me too"...
could this be added to 1.2? If not, a possible workaround would also be to establish a custom fact "environment" on Puppet 3.x clients.

Probably not, since it would involve adding a new setting I think to control setting environments from reports and new code to handle it (currently in RC phase).

A custom fact sounds like a good plan, provided Puppet doesn't filter ones called "environment" out. It was probably removed because at that point in the agent process, the environment could still be overridden by the puppetmaster (if enc_environment were true, anyway).

Actions #4

Updated by Anonymous almost 11 years ago

OK, here is my custom fact, which I just verified to work:

require 'puppet'

if Facter.value(:puppetversion).to_i >= 3
  Facter.add(:environment) do
    setcode do
      Puppet[:environment]
    end
  end
end

Actions #5

Updated by Lukas Zapletal over 10 years ago

  • Description updated (diff)
  • Target version changed from 1.3.0 to 1.4.0
Actions #6

Updated by Greg Sutcliffe over 10 years ago

  • Target version deleted (1.4.0)
Actions #7

Updated by Boyan Tabakov about 10 years ago

Are there any plans to implement updating host environment based on reports (and setting to control this)? I think this would be very useful, especially in situations where people use Foreman only for reporting/stats. I was thinking of implementing this, if work hasn't already been starter.

Actions #8

Updated by Dominic Cleal about 10 years ago

Nobody's started, I think that'd be appreciated, thanks.

Actions #9

Updated by David Goldsmith over 9 years ago

Michael, I'm using Puppet 3.7.3 on CentOS 7.0 and just tried your facter snippet and it did not work. My client is currently in an environment named yum_test (set in [agent] section of /etc/puppet/puppet.conf). My results are:

[root@puppetdb21a ~]# puppet agent -t
Info: Retrieving pluginfacts
Info: Retrieving plugin
Notice: /File[/var/lib/puppet/lib/facter/environment.rb]/ensure: defined content as '{md5}ac9d6b73454314a1da95e227eb9fdbbc'
Info: Loading facts
Info: Caching catalog for puppetdb21a.sans.org
Info: Applying configuration version '1417450699'
Notice: Finished catalog run in 2.76 seconds
[root@puppetdb21a ~]# puppet agent --configprint environment
yum_test
[root@puppetdb21a ~]# facter -p environment
production

If I replace the "Puppet[:environment]" line with "Facter::Util::Resolution.exec('puppet agent --configprint environment ')" then it works.

But given that "puppet agent --configprint environment" is returning the actual value, where might "Facter[:environment]" be getting "production" from?

Actions #10

Updated by Anonymous over 9 years ago

David, I didn't use that fact for a long time now, but still would expect it to work, when used with "puppet agent --test". Could you check that? It probably never worked for the facter -p case.

Actions #11

Updated by David Goldsmith over 9 years ago

Ok, I tried again and it does work, mainly.

I am using the theforeman/puppet and the theforeman/foreman modules to setup my servers. The puppet module dynamically rebuilds the puppet.conf file each run if there are any changes, including something like the command line argument "--environment yum_test". I'm also changing the setting update_environment_from_facts to true in Foreman with the goal of seeing what environment the servers are really in as I am not using Foreman as the ENC and classifying from within.

With your code snippet restored, it did actually update the host status within Foreman and more importantly, when I run "puppet agent -t" on a box in a different environment, it is picking up the new environment's hieradata directory which is the desired behavior. "factor -p environment" still shows "production" on the server even if it is in a different environment, even after multiple puppet agent runs.

When I had tried with my exec statement, it was updating the environment info displayed by "factor -p" but it was also overriding the command-line "--environment" argument which meant I could not dynamically switch environments. I had to edit /etc/puppet/puppet.conf and change the environment there manually, then run puppet and it picked up the "new" environment setting and used the appropriate hieradata.

Given that other facts that I have written show up in the output of "factor -p", why would this one not? (using your snippet)

Actions #12

Updated by Anonymous over 9 years ago

That's a Puppet question, as Foreman is out of the whole picture there, but anyway, here we go.. :)

That "require 'puppet'" (which might be too much anyway) in the custom fact's code is loading the necessary code portion from Puppet into facter, but it doesn't do any Puppet agent related initialization, so if you just run "facter -p" it will run with all the defaults from the Puppet code, which is e.g. production for the environment, as the -p switch to my knowledge just extends facter's library path to also include e.g. /var/lib/puppet/lib/facter/ so you can use the facts coming from pluginsync via Puppet.

When running under the Puppet agent, however, facter is spawned under the whole Puppet agent, so all the initialization was already done.

Actions #13

Updated by Robert Heinzmann almost 8 years ago

  • Related to Feature #15972: Foreman fact name used for 'update_environment_from_facts' should be parametrizable added
Actions #14

Updated by Anonymous almost 8 years ago

As this is a Puppet change, Foreman can nothing do about, I'm leaning towards closing this issue. Opinions?

Actions #15

Updated by Anonymous over 7 years ago

  • Status changed from New to Resolved

closing, as this is a Puppet issue.

Actions

Also available in: Atom PDF