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
> On Mar 19, 2015, at 07:30, jcbollinger <john.bollin...@stjude.org> wrote:
>
>
>
>> 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 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+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.
--
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/5C76036E-3A7F-4F72-8FF5-0B2C0DACBDDF%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
