I also tested hiera recursive lookup and seems to work. Here is an example:
*rdeck_port_default: '4441'rdeck_configdir_default:
'/etc/rundeck'rundeck::rdeck_jvm: java.security.auth.login.config:
"%{hiera('rdeck_configdir_default')}/jaas-loginmodule.conf"
server.http.port: "%{hiera('rdeck_port_default')}"*
So in your case the problem might be the old software. There is however a
question: is this practice aligned with puppet/hiera best practices? I have
seen that the official documentation recommends using facts and top-scope
variables or variables from an ENC in interpolation but it doesn't say
anything about hiera defined variables.
On Wednesday, January 14, 2015 at 10:49:27 PM UTC+2, James Oden wrote:
>
> I think that is the answer. Probably when we go to Fedora 21
> (because I'm lazy and don't want to rebuild or go past what is in the
> Fedora repos) we probably see this feature come in. For now I've
> hard coded the data, and left a note to fix it.
>
> So ultimately this isn't a bug to be reported, it's just old software?
>
> Thanks...James
>
> On Wed, Jan 14, 2015 at 2:53 PM, Tony Thayer <tony....@gmail.com
> <javascript:>> wrote:
> > Are you running PE 3.4.2? I don't think it came with Hiera 1.3 bundled
> (the
> > version that supports nested Hiera calls). Calling hiera from the
> command
> > line won't necessarily use the same hiera gem PE is using. This bit me a
> few
> > times when I was exploring using PE last year.
> >
> >
> > On Tuesday, January 13, 2015 at 7:09:19 AM UTC-8, James Oden wrote:
> >>
> >> I had two puppet modules that needed the same data, so I tried to
> define
> >> the data once in hiera and then refer to the first definition via the
> >> hiera() function. When I did this as soon as puppet began loading the
> >> module that used one of these variables it hung. I checked using the
> >> hiera CLI and it could actually resolve the variables just fine. When
> I
> >> changed the the hiera file to not use variables but instead copied the
> >> actual strings wherever needed it, puppet worked just fine. Also, I
> did a
> >> mixed solution where one of the modules had static data and the other
> did
> >> the hiera lookup, and it got further but hung on the module that was
> doing
> >> the lookups.
> >>
> >> Here is the hiera data I'm referring too:
> >>
> >> dns1: '10.135.82.132'
> >> dns2: '10.35.249.52'
> >> dns3: '10.35.249.41'
> >> dns_search1: 'us.blah.com'
> >> dns_search2: 'labs.nc.blather.com'
> >> resolvconf::nameserver:
> >> - "%{hiera('dns1')}"
> >> - "%{hiera('dns2')}"
> >> - "%{hiera('dns3')}"
> >> resolvconf::search:
> >> - "%{hiera('dns_search1')}"
> >> - "%{hiera('dns_search2')}"
> >> vagrant-dns::device: 'enp0s3'
> >> vagrant-dns::dns1: "%{hiera('dns1')}"
> >> vagrant-dns::dns2: "%{hiera('dns2')}"
> >> vagrant-dns::dns3: "%{hiera('dns3')}"
> >> vagrant-dns::search: "%{hiera('dns_search1')}
> %{hiera('dns_search2')}"
> >>
> >> I am using puppet 3.4.2.
> >>
> >> Is this a known problem? Am I doing something stupid? I tried
> >> googling for this but came up nil.
> >>
> >> Thanks...James
> >
> > --
> > 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 puppet-users...@googlegroups.com <javascript:>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-users/d1bf8974-0a41-43cb-8704-af230990832e%40googlegroups.com.
>
>
> >
> > For more options, visit https://groups.google.com/d/optout.
>
--
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/9f09c158-47de-4c7f-ada2-3c89e5538aa9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
