Issue #22274 has been updated by Charlie Sharpsteen. Status changed from Unreviewed to Needs More Information Assignee set to Igor Galić
Igor Galić wrote: > My question is simple: If this is a feature, it needs to be documented some > place. This is indeed the expected behavior, and the order of precedence for class parameters is documented in the ["Automatic Parameter Lookup" section](http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookup) of "Using Hiera with Puppet" in the Hiera docs: > Parameters can be set several ways, and Puppet will try each of these ways in > order when the class is declared or assigned by an ENC: > > 1. If it was a [resource-like declaration/assignment][resource_like], Puppet > will use any parameters that were explicitly set. These always win if they > exist. > 2. **Puppet will automatically look up parameters in Hiera,** using `<CLASS > NAME>::<PARAMETER NAME>` as the lookup key. (E.g. `myclass::parameter_one` in > the example above.) > 3. If 1 and 2 didn't result in a value, Puppet will use the default value > from the class's [definition][class_definition]. (E.g. `"default text"` in > the example above.) > 4. If 1 through 3 didn't result in a value, fail compilation with an error. In your case, the values provided by the `hiera_array` function occupy step 3 in the order of precedence and are therefore overruled by values retrieved from automatic parameter lookup in step 2. The [limitations](http://docs.puppetlabs.com/hiera/1/puppet.html#limitations) section notes that automatic parameter lookup does not perform hash or array merging and just returns the first match found in the hierarchy. Does the documentation contain the information you were looking for, or are there areas we could improve it? ---------------------------------------- Bug #22274: Automatic hiera lookup triggered despite explicit override https://projects.puppetlabs.com/issues/22274#change-96858 * Author: Igor Galić * Status: Needs More Information * Priority: Normal * Assignee: Igor Galić * Category: * Target version: * Affected Puppet version: 3.2.4 * Keywords: documentation hiera * Branch: ---------------------------------------- I managed to reproduce on a very small scale an issue that's I've debugged for hours yesterday. if we have a class: <pre> class foo ( $bar = hiera_array('foo::bar', $foo::params::bar), ) inherits foo::params { notify{ "foo::bar: ${bar}": } } class foo::params { # so we know if we're hitting defaults, or actually hiera! $bar = 'bar' } </pre> and a hierachiy: <pre> %{::fqdn} %{::common} </pre> with the values: <pre> --- # ::fqdn foo::bar: baz </pre> and <pre> --- # ::common foo::bar: quux </pre> then hiera -a will deliever [ 'baz', 'quuux' ], but our notify will give us 'baz'. Now, if we change the class: <pre> class foo ( $_bar = hiera_array('foo::bar', $foo::params::bar), ) inherits foo::params { notify{ "foo::bar: ${_bar}": } } </pre> we'll get the expected result, that is, notify will print: <pre> Notice: /Stage[main]/Foo/Notify[foo::bar: bazquux]/message: defined 'message' as 'foo::bar: bazquux' </pre> My question is simple: If this is a feature, it needs to be documented some place. -- 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 unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
