Issue #3910 has been updated by Nigel Kersten.
"What worries me most about this current line of discussion is that it is based on entirely practical concerns of load avoidance rather than approaching the core issue of configuration management." I think it's actually the other way around Oliver. The current code as I understand it will deal with an environment mismatch between agent and server by throwing away the catalog that was compiled using the agent environment, and instead re-doing the whole process of pluginsync + catalog retrieval with the server specified environment. I am concerned about load here however, particularly in situations where the agent doesn't specify an environment (and thus defaults to 'production') and the server sets a different environment. It feels like a better approach would be to do something like: * agent requests catalog with environment "A". * agent pluginsyncs with environment "A" * server notes the mismatch as it is assigning environment "B" * agent re-does pluginsync with environment "B" * server delivers catalog with environment "B" so we still maintain the server being able to operate as an authoritative source of truth, but remove the second catalog compilation. It's entirely possible I'm missing something here, so I'll chat to Patrick today. ---------------------------------------- Bug #3910: Server is not authoritative over client environment when specified in an ENC https://projects.puppetlabs.com/issues/3910#change-56550 Author: Nigel Kersten Status: In Topic Branch Pending Review 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.
