Issue #3910 has been updated by Jerome Loyet.
Hi
just a question:
In the case the environment set in the client is different from the environment
returned from the ENC. The client is switching to the environment set by ENC:
`Warning: Local environment: "production" doesn't match server specified node
environment "mutu_ads__puppet_server", switching agent to
"mutu_ads__puppet_server".`
this works as expected. But if I want to use the $environment variable in any
of my manifest, it's then equal to the agent environment (aka production in my
example). I've added the following line in the node definition to demonstrate
it:
`notify{"Environment var seen in the manifest: ${environment}":}`
And when it executes, $environment equals "production" instead of the
environment returned by the ENC.
`Environment var seen in the manifest: production`
It's like the $environment variable is overrided by the environment value
returned from facter.
To fix this, I've used the following workaround: my ENC also returns a
parameter "real_environment" so that I can use the $real_environment variable
in my manifests. I'm using it to generate the file /etc/puppet/puppet.conf to
avoid the warning.
Is this a bug or a feature ? If it's a feature, how can I retrieve the
environment from the ENC without passing it as a parameter extra variable ?
thx for the answer.
++ fat
----------------------------------------
Bug #3910: Server is not authoritative over client environment when specified
in an ENC
https://projects.puppetlabs.com/issues/3910#change-69799
Author: Nigel Kersten
Status: Merged - Pending Release
Priority: Urgent
Assignee: Patrick Carlisle
Category: plumbing
Target version: 3.0.0
Affected Puppet version: 0.25.4
Keywords:
Branch: https://github.com/puppetlabs/puppet/pull/691
See:
http://groups.google.com/group/puppet-dev/browse_thread/thread/b609965e377392ec
To summarize, when the client specifies one environment and the classifier
specifies another, classes are evaluated from the server-specified environment,
and yet files are retrieved from the client-specified environment.
3 environments defined, each with a single class "base".
*/etc/puppet/puppet.conf*
<pre>
<...snip...>
[one]
modulepath = /etc/puppet/environments/one/modules
[two]
modulepath = /etc/puppet/environments/two/modules
[three]
modulepath = /etc/puppet/environments/three/modules
</pre>
*/etc/puppet/environments/one/modules/base/manifests/init.pp*
<pre>
class base {
notify { "hardwired one": }
notify { "variable $environment": }
file { "/tmp/environment_test":
source => "puppet:///base/tester",
}
}
</pre>
*/etc/puppet/environments/two/modules/base/manifests/init.pp*
<pre>
class base {
notify { "hardwired two": }
notify { "variable $environment": }
file { "/tmp/environment_test":
source => "puppet:///base/tester",
}
}
</pre>
*/etc/puppet/environments/three/modules/base/manifests/init.pp*
<pre>
class base {
notify { "hardwired three": }
notify { "variable $environment": }
file { "/tmp/environment_test":
source => "puppet:///base/tester",
}
}
</pre>
<pre>
$ cat /etc/puppet/environments/{one,two,three}/modules/base/files/tester
one
two
three
</pre>
Right? So we have two notify resources and a file resource.
- The "hardwired" notify is to illustrate which class is being loaded.
- The "variable" notify is to illustrate what $environment evaluates to
in the manifests.
- The file source is to illustrate which file is being sourced.
I also have an external node classifier that always returns this:
<pre>
---
classes:
- base
environment: one
</pre>
So our classifier always includes base, and always sets the environment.
I then invoke a puppet run on a client, specifying the environment to be
*different* to the classifier.
Between all of these runs I delete cached client yaml info on the server.
(find /var/puppet/yaml -type f -delete)
<pre>
# puppetd -t --environment two
notice: hardwired one
notice: //base/Notify[hardwired one]/message: defined 'message' as
'hardwired one'
notice: variable two
notice: //base/Notify[variable two]/message: defined 'message' as 'variable
two'
notice: Finished catalog run in 0.18 seconds
# cat /tmp/environment_test
two
</pre>
*So we have the class being evaluated in environment "one", but the file
being sourced coming from environment "two" ! *And less importantly,
$environment evaluates to "two".
*
*
Now, to throw the big spanner in the works.... we try not specifying an
environment at all.
<pre>
# puppetd -t
notice: hardwired one
notice: //base/Notify[hardwired one]/message: defined 'message' as
'hardwired one'
notice: variable production
notice: //base/Notify[variable production]/message: defined 'message' as
'variable production'
err: //base/File[/tmp/environment_test]: Failed to retrieve current state of
resource: Error 400 on SERVER: Not authorized to call find on
/file_metadata/base/tester Could not retrieve file metadata for
puppet:///base/tester: Error 400 on SERVER: Not authorized to call find on
/file_metadata/base/tester at
/etc/puppet/environments/one/modules/base/manifests/init.pp:6
notice: Finished catalog run in 0.08 seconds
</pre>
As we don't have an environment "production" defined at all, the server
tries to read the metadata from a non-existent environment and fails.
--
You have received this notification because you have either subscribed to it,
or are involved in it.
To change your notification preferences, please click here:
http://projects.puppetlabs.com/my/account
--
You received this message because you are subscribed to the Google Groups
"Puppet Bugs" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-bugs?hl=en.
