Wow, this was a long time ago :)
I can not speak to the deep bits on why I was seeing hiera files based on
Puppet Facts not having correct file names when processing puppet lookup.
What I can say is that I was referencing a class params like
$::test::dconf_default_config,
but I had not defined dconf_default_conf in the init.pp's class params...
class test(
...
String $dconf_default_config, # This was missing, adding it fixed the
issue.
...
) {
...
}
Before adding the line, I just had the default value for that param defined
in a fact driven hieradata file. It all produced a very strange behavior
though.
On Wednesday, September 19, 2018 at 12:14:47 PM UTC-4,
[email protected] wrote:
>
> Hi Sean,
>
> I'm having the same issue, and I see what you said, I'm just too new to
> puppet. Would it be possible for you (or others) to expand on how you
> fixed this (with and example)?
>
> Chris
>
> On Wednesday, November 29, 2017 at 11:15:49 AM UTC-6, Sean wrote:
>>
>> Thanks to PuppetLab's Mr. Lindberg who helped get my troubleshooting
>> focused in the right direction.
>>
>> Basically, I forgot to add my new parameters to the class parameter
>> definitions in the module's init.pp.
>>
>> DOH!
>>
>> On Tuesday, November 28, 2017 at 4:53:42 PM UTC-5, Sean wrote:
>>>
>>> Hi,
>>> I'm quite confused about how I could have created this problem. I have
>>> a module we'll call it "test" which has been using Hiera v5 module data for
>>> the last couple of releases...this works great on either puppet 4 or 5...as
>>> expected.
>>>
>>> Last week added a feature, which involved adding 1 new manifest file
>>> (which creates concat::fragment resources), 2 parameters to a hiera data
>>> file, and adding 2 concat file resources, each named by one of those
>>> parameters, to an existing manifest file (existing.pp below). Fairly
>>> simple and straight forward change. The parser passes the syntax checks
>>> for everything involved in the change.
>>>
>>> I have tested on both puppet 4 and 5 using a pair of centos7 vms, both
>>> produce the same result.
>>>
>>> # puppet apply -e "include test"
>>> Warning: Unknown variable: 'test::dconf_default_config'. at
>>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>>> Error: Evaluation Error: Missing title. The title expression resulted in
>>> undef at
>>> /etc/puppetlabs/code/environments/production/modules/test/manifests/existing.pp:186:12
>>>
>>> on node localhost.localdomain
>>>
>>> This parameter is the filename of the concat resource mentioned above.
>>> Running a puppet lookup (on either v4 or v5) produces this output for the
>>> module data section:
>>>
>>> Module "test" Data Provider (hiera configuration version 5)
>>> Using configuration
>>> "/etc/puppetlabs/code/environments/production/modules/test/hiera.yaml"
>>> Hierarchy entry "Full Version"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path: "%{facts.os.name}-%{facts.os.release.full}.yaml"
>>> Path not found
>>> Hierarchy entry "Major Version"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path: "%{facts.os.name}-%{facts.os.release.major}.yaml"
>>> Path not found
>>> Hierarchy entry "Distribution Name"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>>> Original path: "%{facts.os.name}.yaml"
>>> Path not found
>>> Hierarchy entry "Operating System Family + Major Version"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
>>> Original path:
>>> "%{facts.os.family}-%{facts.os.release.major}.yaml"
>>> Path not found
>>> Hierarchy entry "Operating System Family"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
>>> Original path: "%{facts.os.family}.yaml"
>>> Path not found
>>> Hierarchy entry "common"
>>> Path
>>> "/etc/puppetlabs/code/environments/production/modules/test/data/common.yaml"
>>> Original path: "common.yaml"
>>> No such key: "test::dconf_default_config"
>>>
>>>
>>> See how all the Hierarchy Paths have bad file names? This leads me to
>>> think that somehow Hiera has lost the ability to parse facts in my feature
>>> branch of this module. If I check the master branch out for the "test"
>>> module then Hiera produces the correct datafile names.
>>>
>>> How can that be?
>>>
>>
--
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/513321ac-6867-4693-8789-1d10d14ce1e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.