Issue #3910 has been updated by Alan Barrett.
Nigel Kersten wrote: > We have a setting for whether the master is authoritative over the client > environment. Why do you need such a setting? It seems to add needless complexity. Here's my proposal. >From the client's perspective: 1. The client/server interaction always begins with the client asking the server "I think my environment should be <client_env>, and here are my facts and certificates and stuff; what do you think my environment should be?" 2. In response to (1), the server informs the client of what environment to use. The server is free to believe the client's environment, or not, according to server configuration, which the client doesn't need to know about. 3. The environment reported by the server to the client in (2) above is always authoritative. If the client doesn't like it, then its only recourse is to fail. >From the server's perspective: 1. No new configuration settings are needed. 2. If there's an external node classifier, and if it specifies an environment, then that wins. 3. The external node classifier should have access to the client's idea of the environment, and all the facts (see issue #2834), so the external node classifier is free to let the client's idea of the environment win, or not, according to arbitrarily complex conditions. 4. If there's no external node classifier, or if the external node classifier is silent about the environment, then the client's environment is used, but if the client didn't specify an environment, then the server's default environment is used. >From the administrator's perspective: 1. If you want the client's environment to win, then don't use an external node classifier, or use an external node classifier that doesn't override the client's idea of the environment. 2. If you want the server's environment to win, then use an external node classifier that overrides the client's environment. 3. If you have more complex requirements, then use a more complex external node classifier. ---------------------------------------- Bug #3910: Class/File source mismatch when client/node classifier disagree on environment. https://projects.puppetlabs.com/issues/3910 Author: Nigel Kersten Status: Needs design decision Priority: High Assignee: Nigel Kersten Category: plumbing Target version: Statler Affected Puppet version: 0.25.4 Keywords: Branch: 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.
