Issue #3910 has been updated by Patrick Carlisle.
Nick Fagerlund wrote: > Something I just noticed which is unrelated to the above conversation: > > The "exec" node terminus ALWAYS inserts an environment into the node object; > if the ENC script doesn't return one, it inserts "`&id001 production`". (Note > that the "plain" terminus will return node objects with no environment, so it > should be possible for ENC nodes to have no environment specified; it just > wasn't implemented that way.) I haven't tested what the ldap node terminus > does. > > That behavior seems worth reconsidering -- not specifying an environment on > the server should mean "let the client's environment win," not "force every > client into 'production'." > > I took a quick look at the acceptance tests, and none of them would catch > that. The `test_name "Agent should use agent environment if there is no > enc-specified environment"` test is using the plain terminus; there should be > another test that checks the exact same thing but uses the exec terminus with > a script that leaves the environment key out. Thanks. I've added this in my branch. It seems to work, I am seeing the catalog come back with the agent-specified environment instead of production. Take a look at <https://github.com/pcarlisle/puppet/commit/d0012efe141c37f22aabd4d5c1bd2ae6b821dc11> and see if that does what you think it should, since it seems different from the results you were reporting. ---------------------------------------- Bug #3910: Server is not authoritative over client environment when specified in an ENC https://projects.puppetlabs.com/issues/3910#change-57731 Author: Nigel Kersten Status: Code Insufficient Priority: Urgent Assignee: Patrick Carlisle Category: plumbing Target version: Telly Affected Puppet version: 0.25.4 Keywords: Branch: https://github.com/puppetlabs/puppet/pull/569 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.
