hiera can't find facts to read hierarchy files?

[Sean]

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?

[Sean]

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!

[ch...@fuzzyblender.com]

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

[Henrik Lindberg]

On 2018-09-19 17:41, ch...@fuzzyblender.com 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
>

I had responded to Sean in an email - reposting it here now:

How did you run `puppet lookup` ?
If you gave it a node with --node it will use the stored facts for that
node, otherwise you have to give it the facts to use for that node.
If not specifying a --node, lookup will use the facts for the host where
you are running `puppet lookup`.

Maybe that is what is tricking you?

Try running with `puppet apply --debug` when testing - that turns on
logging of --explain from all lookups including those made via APL.
When you do that, are the path's set?

Still having weird problems? Check your axioms - are you running the
expected file in the expected environment etc.

- henrik

> Module"test"DataProvider(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

> <http://facts.os.name>}-%{facts.os.release.full}.yaml"
> Pathnot found

> Hierarchy entry "Major Version"
> Path"/etc/puppetlabs/code/environments/production/modules/test/data/-.yaml"
> Original path:"%{facts.os.name

> <http://facts.os.name>}-%{facts.os.release.major}.yaml"
> Pathnot found

> Hierarchy entry "Distribution Name"
> Path"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"

> Original path:"%{facts.os.name <http://facts.os.name>}.yaml"
> Pathnot 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"

> Pathnot found

> Hierarchy entry "Operating System Family"
> Path"/etc/puppetlabs/code/environments/production/modules/test/data/.yaml"
> Original path:"%{facts.os.family}.yaml"

> Pathnot 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 puppet-users...@googlegroups.com
> <mailto:puppet-users...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/f97ce708-9ce8-43f4-bb92-2400cfaf9d82%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/f97ce708-9ce8-43f4-bb92-2400cfaf9d82%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

[Sean]

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.

[jcbollinger]

On Wednesday, September 19, 2018 at 11:14:47 AM UTC-5, ch...@fuzzyblender.com 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)?

I commented on your (I think) parallel query over at StackOverflow, which I saw first and where you provided more information.  In brief, my best guess is that your expectations are incorrect: it is my understanding that the puppet lookup command will not run Facter.  It can get facts for the specified node from puppetdb if any are recorded recorded there, and it can take facts specified on the command line.  You'll need to provide more details -- here, there, or both -- for us to answer confidently.

John