On Wednesday, September 9, 2015 at 5:44:57 AM UTC-5, Fraser Goffin wrote:
>
> Puppet: v4.2.1
> Hiera: v3.0.1
> Facter: v3.0.2
> Ruby: 2.1.6p336
>
> Platform: Windows.
>
> Came across an interesting behaviour when using hiera that was unexpected
> (to me anyway). I don't necessarily think its a bug, but I thought it worth
> sharing for others who may come across it. Keep in mind that this is just
> an example to illustrate the behaviour and not a recommendation about how
> to write Puppet/Hiera (maybe its even an anti-pattern !)
>
> Lets say you have a class :
>
> class hiera_binding_test (
> $version,
> $install_folder) {
>
> notice("version is: ${version}")
> notice("install_folder is: ${install_folder}")
> }
>
> a hiera.yaml :-
>
> :hierarchy:
> - common
>
> :backends:
> - yaml
>
> :yaml:
> :datadir: E:/Temp/puppetTests/hiera_binding_test/hiera
>
> and a hiera common.yaml :-
>
> hiera_binding_test::version: '1.0'
> hiera_binding_test::install_folder:
> "c:/apps/myapp/%{hiera_binding_test::version}/bin"
>
> Note that in common.yaml that the 'install_folder' makes use of the
> 'version' class param.
>
> If when the hiera_binding_test class is called the 'version' param is
> passed explicitly (regardless of whether 'install_folder' is or not), the
> outcome is as expected :-
>
> Notice: Scope(Class[Hiera_binding_test]): version is: 1.0
> Notice: Scope(Class[Hiera_binding_test]): install_folder is: c:/apps/myapp
> /1.0/bin
>
> However, if we just use 'include' (which is obviously the patern we want
> to use by preference) :-
>
> include hiera_binding_test
>
> the outcome is NOT correct (version is not available) :-
>
> Notice: Scope(Class[Hiera_binding_test]): version is: 1.0
> Notice: Scope(Class[Hiera_binding_test]): install_folder is: c:/apps/myapp
> //bin
>
> So, even though the 'version' param was resolved by automatic parameter
> binding (as we can see from the first line) that value is NOT available to
> the the hiera expression for install_folder:
> c:/apps/myapp/%{hiera_binding_test::version}/bin
>
>
I hadn't heard about this one before, but I can't say it's very
surprising. This looks like a variation on the longstanding issue that
class parameter defaults cannot safely rely on the values of other
parameters of the same class. Doing so works as desired in some cases, but
not in others. It basically comes down to evaluation order, the details of
which are unspecified in this area. I don't expect any change in this
area, so I'd go along with your anti-pattern theory.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4b26b2ea-ac43-4a10-aa53-1e24bac40683%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
