Ask Your Question

Hiera not using ENC to traverse hierarchy

asked 2016-09-06 00:11:19 -0500

This problem has been driving me crazy.

I'm using the roles and profiles design pattern, and I want to give data to my classes based on role (among other things). Thus, I have a hiera hierarchy that looks like this:

  - json
  :datadir: /etc/puppet/hiera
  - "host/%{::hostname}"
  - "role/%{::role}/common"
  - "role/%{::role}/%{::location}"
  - "common"

The idea is that the 'role' and 'location' are going to be set by an external node classifier. The problem is it doesn't work. For now, I just have a simple ENC script that spits out the following yaml for my one host:

 - roles::webserver::init
  role: "webserver"
  location: "dc1"

Now, I have the following hiera tree structure:

├── common.json
├── host
└── role
    └── webserver
        └── common.json

3 directories, 2 files

For testing purposes, I wrote the following module and added it to the list of classes for my node:

class iama($hieratest="default", $hierarole="default") {
  file { '/root/iama':
    ensure  => 'present',
    owner   => 'root',
    group   => 'root',
    mode    => 0600,
    content => "Role: ${role}\nhieratest: ${hieratest}\nhierarole: ${hierarole}\n",

Then I populated common.json with the following setting:

{ "iama::hierarole": "%{::role}" }

and the webserver/common.json with this:

{ "iama::hieratest": "itworks!" }

The goal is that the file /root/iama would be populated with this:

role: webserver
hieratest: itworks!
hierarole: webserver

Of course, if for some reason the role variable wasn't making it to hiera, I would expect 'hieratest' and 'hierarole' to both be set to 'default'. But what's actually happening is quite strange -- I'm getting the following output:

role: webserver
hieratest: default
hierarole: webserver

To me this suggests the following: puppet is calling hiera with the "role" variable in the top level scope. hiera is not using this variable in the hierarchy, but is using it for interpolation in the data files themselves. On the other hand, when I run hiera from the command line, everything is fine:

$ hiera -c hiera.yaml "iama::hieratest" ::role=webserver

I've tried everything: I've tried just putting "role" instead of "::role" in many places and vice-versa. I've double-checked that everything is spelled correctly. I've been at this a long time. Any ideas?

References to others who have struggled with this:!top...

edit retag flag offensive close merge delete



(this doesn't help you with your problem at all, but you probably want to put role/%{::role}/common below role/%{::role}/%{::location} in your hierarchy, specific should win over 'common')

DarylW gravatar imageDarylW ( 2016-09-06 11:52:00 -0500 )edit

Thanks for catching that.

Rosen Moore gravatar imageRosen Moore ( 2016-09-07 02:00:42 -0500 )edit

no problem! I remember having the same ordering in my hierarchy and it biting me later!

DarylW gravatar imageDarylW ( 2016-09-07 08:28:45 -0500 )edit

1 answer

Sort by » oldest newest most voted

answered 2016-09-07 02:02:13 -0500

Turns out it was a permissions problem -- the puppet user didn't have access to the 'role' folder. I feel pretty disappointed that puppet and hiera didn't give any reasonable error message for this situation, even in debug mode. They should have said, "look pal, you asked for this data source in the hierarchy, and it's there, but I don't have permissions on it".

edit flag offensive delete link more


There are a few places with disappointing/unhelpful error messages. Using hiera-eyaml, if it can't decrypt a value, it throws an exception(bad decrypt, but no filename) and aborts the whole puppet run instead of just not parsing that file. That is probably the better' fail fast' mentality though

DarylW gravatar imageDarylW ( 2016-09-07 08:30:17 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2016-09-06 00:11:19 -0500

Seen: 45 times

Last updated: Sep 07 '16