I think it's kind of amazing that hiera works at all on 2.6--it's pretty
deeply unsupported. Why not upgrade?
Is there a redmine bug number describing the bizarre behavior?
On Friday, July 26, 2013 8:34:13 AM UTC-7, GregC wrote:
>
> What puppet master version are you running? I also seem to see this
> bizarre behavior in 2.6.11 and no one at puppet labs has responded to this
> hiera issue it just goes unanswered, I've also read that the catalog gets
> compile in random order on each run prior to 2.7, this explains some weird
> results i've seen in the past.
>
> As stated earlier switch and put common last in the hiera.yaml file.
>
> As a test try this. change yaml file like so:
>
>
> :backends:
> - yaml
>
> :hierarchy:
> - common
> #- '%{env_name}'
> :yaml:
> :datadir: /var/lib/hiera/data
>
> put the class or module info you have from your envXX.yaml file in the
> common.yaml file.
>
> If catalog run is successful then you are dealing with the weird hiera
> bug. WOuld be interested to know your results, good luck.
>
> On Thursday, July 25, 2013 1:49:56 PM UTC-4, Ellison Marks wrote:
>>
>> Not sure exactly, but in general you want common to be searched last, as
>> hiera by default bails when it finds an answer, so your hierarchy in the
>> conf file is backwards. You'd want the env_name fact above common.
>>
>> On Thursday, July 25, 2013 7:27:26 AM UTC-7, chengkai liang wrote:
>>>
>>> So something doesn't look right for me when running puppet apply -e
>>> 'include ...' for looking heria via facter fact.
>>>
>>> I have hiera configure as this,
>>>
>>> :backends:
>>> - yaml
>>>
>>> :hierarchy:
>>> - common
>>> - '%{env_name}'
>>>
>>> :yaml:
>>> :datadir: /var/lib/hiera/data
>>>
>>> and, a file envXX.yaml store in the datadir, and I can run *hiera xyz
>>> env_name=envXX* to get the the value of abc associate with xyz.
>>>
>>> Yet, if I export the value variable env_name by *export FACTER_env_name=
>>> *envXX, and run:
>>>
>>> *puppet apply -e 'include my_module
>>>
>>> *
>>> puppet will complaint that it can't find data store in envXX.yaml. From
>>> the debug output,
>>>
>>> debug: importing
>>> '/Users/cliang/.puppet/modules/puppet_flux2_config/manifests/init.pp' in
>>> environment production
>>> debug: Automatically imported puppet_flux2_config from
>>> puppet_flux2_config into production
>>> debug: hiera(): Hiera YAML backend starting
>>> debug: hiera(): Looking up host_header_url in YAML backend
>>> debug: hiera(): Looking for data source common
>>> Could not find data item host_header_url in any Hiera data file and no
>>> default supplied at
>>> /Users/cliang/.puppet/modules/puppet_flux2_config/manifests/init.pp:4 on
>>> node m-mba.local
>>>
>>> It seems that it stop looking right after common, while running with *hiera
>>> xyz env_name=envXX* *--debug *shows,
>>>
>>> DEBUG: Thu Jul 25 07:24:48 -0700 2013: Hiera YAML backend starting
>>> DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking up host_header_url in
>>> YAML backend
>>> DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking for data source common
>>> DEBUG: Thu Jul 25 07:24:48 -0700 2013: Looking for data source *envXX*
>>> DEBUG: Thu Jul 25 07:24:48 -0700 2013: Found xyz in *envXX*
>>>
>>> So why puppet apply won't look further into envXX.yaml file? Anybody
>>> can help on this?
>>>
>>>
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.
