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
--
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+unsubscr...@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.
