Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Won't Fix
-
PUP 5.5.8
-
None
-
None
-
Froyo
-
Needs Assessment
-
Needs Assessment
Description
This change in behaviour occurred between 5.4.0 and 5.5.0
If the hiera function is called on a module namespace
$a = hiera(module::foo)
before any lookup call
$ = lookup('module::bar)
on that same namespace then lookup_options on the module level data is never looked up.
All subsequent lookups (or hiera) can then be wrong.
Attached is a test case module.
bundle install
- The following command will fail tests
bundle exec rake test
- The following command will pass tests
PUPPET_VERSION=5.4.0 bundle update
PUPPET_VERSION=5.4.0 bundle exec rake test
The failing file is
class lookupparam::hierafirst {
|
$notusedhiera = hiera('lookupparam::notusedhiera',foobar)
|
$notusedlookup = lookup('lookupparam::notusedlookup',String,'first',foobar)
|
$testparam = lookup('lookupparam::testparam')
|
notify{$testparam:}
|
}
|
|
The call of hiera('lookupparam::notusedhiera') is enough to break all the other lookups and in particular in this case $testparam ignores the lookup_options which are present in the module level data.
In addition this hardly ever happens in real would since modules typically have parameters and that is enough to cause the lookup.
The particular case where we run into this was
class whatever (
|
$a = 'abc',
|
) inherits whatever::params {
|
...
|
}
|
|
class whatever::params {
|
$myvar = hiera('whatever::param')
|
}
|
Closing this won't fix is fine with me. To trigger this you must use
the deprecated hiera function and lookup_options in the same module and that
is probably a bad idea anyway.