hiera - multiple backends - failure to lookup value in only one backend.

[Brett Swift]

I've found the time to deliver a multiple hiera backend for our ops guys, and I'm seeing some weird behaviour.

With a single backend, it works great - add host level configs in the host hierarchy,  and common stuff in what we had a 'role' hierarchy.

I have since split the backends, so there is one .git repo (we call it hostdata) holding the 'hosts' tier,   and the main hieradata repo holding other tiers. (For us this made sense as our Ops guys almost never modify anything other than at the host level). 

The Problem: What I'm seeing, is sometimes hiera doesn't find what it should be finding, and I am trying to figure out some odd behaviour.   I'll try to demonstrate this below: 

I use eyaml without a key, in order to get two yaml backends.   Hacky, but it should work... 

---

:backends:

  - eyaml

  - yaml

:hierarchy:

  - "host/%{::hostname_lower}"

  - "cluster/%{::cluster}/%{role}"

  - "roles/%{role}"

  - "project/%{::project}"

  - "subnet/%{::subnet}"

  - common

  - users

:yaml:

   :datadir: /etc/puppetlabs/puppet/environments/%{::environment}/hieradata

:eyaml:

   :datadir: /etc/puppetlabs/puppet/hostdata/master

   :extension: yaml

hostdata as it's host specific doesn't use environments.  It's just a single branch.   You'll see the folders here: 

[bswift@devcorepptl900 puppet]$ ls -gG  /etc/puppetlabs/puppet/environments/the900/hieradata

drwxrwxr-x 4 4096 Mar 17 10:14 cluster

-rw-rw-r-- 1 3286 Mar 18 07:31 common.yaml

drwxrwxr-x 2 4096 Mar 17 10:14 project

drwxrwxr-x 2 4096 Mar 18 07:31 roles

drwxrwxr-x 2 4096 Mar 17 10:14 subnet

-rw-rw-r-- 1 5238 Mar 17 10:14 users.yaml

[bswift@devcorepptl900 puppet]$ ls -gG /etc/puppetlabs/puppet/hostdata/master

drwxrwxr-x 2 12288 Mar 18 07:30 host

puppet.conf snippet:

environment = the900

The strange behaviour I've been noticing is that if a param is set in hiera in the first backend,  it finds it.   If it's in the second one, it doesn't... but only sometimes. 

One param it won't find if it's in the second backend.  But if I put it in the host level backend it finds it..    but then this causes other params to fail their lookups. 

I see this by running puppet master --compile  and looking at the hiera lookups, as well by notify's in my module manifests. 

Specifically my module has a `puppet::puppet_type` which is master or agent. 

my environment is set to 'the900'  and hiera.yaml  eyaml datadir is directed to hostdata/the900 as well. (not master for this one - off test). 

[bswift@devcorepptl900 puppet]$ cat environments/the900/hieradata/roles/puppetmaster.yaml

puppet::puppet_type: master

puppet::puppet_type  doesn't resolve. 

but if I move puppet::puppet_type:  to  hostdata, the other backend..  in the appropriate host file..  it does resolve. 

What is going on here? 

[Brett Swift]

and to add one more thing - I do see some values coming out of the  second backend - out of the "role" level.. but not everything.   I don't know how this could be getting some but not all..   

Maybe I have my wires crossed on something, but I think everything is in place...   

[jcbollinger]

On Wednesday, March 18, 2015 at 4:40:38 PM UTC-5, Brett Swift wrote:

I've found the time to deliver a multiple hiera backend for our ops guys, and I'm seeing some weird behaviour.

With a single backend, it works great - add host level configs in the host hierarchy,  and common stuff in what we had a 'role' hierarchy.

I have since split the backends, so there is one .git repo (we call it hostdata) holding the 'hosts' tier,   and the main hieradata repo holding other tiers. (For us this made sense as our Ops guys almost never modify anything other than at the host level). 

In the split, did you change any hierarchy levels or data in any way, other than moving some of the data files to the appropriate location for a different backend?

 

The Problem: What I'm seeing, is sometimes hiera doesn't find what it should be finding, and I am trying to figure out some odd behaviour.   I'll try to demonstrate this below: 

I use eyaml without a key, in order to get two yaml backends.   Hacky, but it should work... 

---

:backends:

  - eyaml

  - yaml

:hierarchy:

  - "host/%{::hostname_lower}"

  - "cluster/%{::cluster}/%{role}"

  - "roles/%{role}"

  - "project/%{::project}"

  - "subnet/%{::subnet}"

  - common

  - users

:yaml:

   :datadir: /etc/puppetlabs/puppet/environments/%{::environment}/hieradata

:eyaml:

   :datadir: /etc/puppetlabs/puppet/hostdata/master

   :extension: yaml

Have you verified that all those Puppet variables you're interpolating have the right values at the time and place of the affected lookups?

 

hostdata as it's host specific doesn't use environments.  It's just a single branch.   You'll see the folders here: 

[bswift@devcorepptl900 puppet]$ ls -gG  /etc/puppetlabs/puppet/environments/the900/hieradata

drwxrwxr-x 4 4096 Mar 17 10:14 cluster

-rw-rw-r-- 1 3286 Mar 18 07:31 common.yaml

drwxrwxr-x 2 4096 Mar 17 10:14 project

drwxrwxr-x 2 4096 Mar 18 07:31 roles

drwxrwxr-x 2 4096 Mar 17 10:14 subnet

-rw-rw-r-- 1 5238 Mar 17 10:14 users.yaml

[bswift@devcorepptl900 puppet]$ ls -gG /etc/puppetlabs/puppet/hostdata/master

drwxrwxr-x 2 12288 Mar 18 07:30 host

puppet.conf snippet:

environment = the900

The strange behaviour I've been noticing is that if a param is set in hiera in the first backend,  it finds it.   If it's in the second one, it doesn't... but only sometimes. 

One param it won't find if it's in the second backend.  But if I put it in the host level backend it finds it..    but then this causes other params to fail their lookups. 

I see this by running puppet master --compile  and looking at the hiera lookups, as well by notify's in my module manifests. 

It would be worthwhile to test whether this is really associated with the order of the backends, or whether it is tied directly to the backends themselves.  So for instance, if you deconfigure the eyaml backend, leaving only the yaml, then do you still get unexpected lookup failures for keys that the yaml backend should be able to provide data for?  Also, if you swap the order of yaml and eyaml, do the problems stick to the yaml backend?  Do they move to the eyaml backend?  Does anything change if you keep the backend order, but swap which data are served by which backend?

Also, do your results depend on the type of lookup you are performing?  Your example seems to be describing a problem with automated data binding, which would be a priority lookup (like calling the plain hiera() function).  Where you see contradictory results, are they associated with array-merge and/or hash-merge lookups?

Specifically my module has a `puppet::puppet_type` which is master or agent. 

my environment is set to 'the900'  and hiera.yaml  eyaml datadir is directed to hostdata/the900 as well. (not master for this one - off test). 

[bswift@devcorepptl900 puppet]$ cat environments/the900/hieradata/roles/puppetmaster.yaml

puppet::puppet_type: master

puppet::puppet_type  doesn't resolve. 

but if I move puppet::puppet_type:  to  hostdata, the other backend..  in the appropriate host file..  it does resolve. 

What is going on here? 

I don't know yet, but I suspect either a problem with your variables $::cluster, $::role, etc., an issue associated with data layout (possibly file or directory permissions), or possibly unexpected behavior of the eyaml backend.  I doubt the issue is inherently tied to use of multiple backends, but I don't have enough information to be confident about that.


John

[brett...@gmail.com]

Just figured this out this morning.  It was the $::role. It's a variable declared in site.pp inside a node block. ( poor man's role classification)

$role seems to have fixed things 

Hopefully this release is smooth now! 

Thanks 

Brett

Sent from my iPhone 

--
You received this message because you are subscribed to a topic in the Google Groups "Puppet Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/puppet-users/yUFxZy7yK24/unsubscribe.
To unsubscribe from this group and all its topics, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/89ba2e51-2541-4bae-9769-c2599a317f35%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.