Issue #3910 has been updated by Daniel Pittman.
After talking to Nigel today, we are agreed that the double compilation is undesirable - and that we are generally happy to ask the ENC, before we begin, what the environment should be. This is motivated, in part, by the fact that the stored facts that the ENC references would be *wrong* - drawn from the pluginsync facts in the incorrect environment - in the current model. It is also motivated by the performance costs that people highlight here. The current proposal is: 1. In 2.7 we changed the authentication rules to allow an agent to query the ENC for node definition, for itself. We can use that to perform an initial, and relatively inexpensive, query to determine what the environment should be. 2. We will then proceed as defined: use the current idea of the environment - updated by step 1 - to pluginsync. 3. We will then submit facts, which will trigger an ENC query after they are stored, and compile the catalog. This uses a less expensive operation to determine the correct environment, and means that even a cron driven "run and exit" agent with the wrong environment specified won't cost very much it terms of load on the master. There are two points of concern around this: It is possible that the ACL to allow the agent to query the ENC directly will be absent; in that case the effort to ask the master what the environment should be will fail. The proposal is to preserve the current behaviour - in most cases, we can avoid the restart, but if that is not possible we should eventually converge on the correct environment and succeed in running. It is possible that the ENC query is expensive, and doubling the number of queries there will cause trouble for external services. The proposal is to add a variable to the environment to indicate the type of ENC query: `ENC_QUERY_FOR` set to either `query` or `compile`. ---------------------------------------- Bug #3910: Server is not authoritative over client environment when specified in an ENC https://projects.puppetlabs.com/issues/3910#change-56705 Author: Nigel Kersten Status: Merged - Pending Release 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.
