I worked out my problem.
I spelt hierarchy wrong in my hiera.yaml file...
On 7 December 2012 13:00, Peter Brown <rendhal...@gmail.com> wrote:
> On 7 December 2012 12:11, Ryan Cunningham <ryan.cunningham.xy...@gmail.com
> > wrote:
>
>> I'm actually having this exact same problem. In my hiera.yaml file I had
>> a hierarchy including two facts and then some strings derived from facter
>> facts.
>>
>
> Nice to know I am not completely insane.
>
> When I run puppet agent --test the hiera vars in files named for the
>> node's $fqdn, etc. aren't found, but if I puppet apply specifying my
>> site.pp manifest the variables contained in yaml files like $fqdn.yaml are
>> found and applied properly. I've gone as far as testing this with masters
>> running 3.0 and 2.7 but haven't seen any difference. For the sake of
>> clarity, the agent is being run on the master.
>>
>> I've tried several permutations of specifying a hierarchy including
>> quoting "%{fqdn}", using no quotes, using the syntax for a top-level
>> variable ${::fqdn}, etc. Each time running hiera from the CLI works as
>> expected but the master can't be coerced to behave as expected.
>>
>> A bit of pastebin
>> puppet apply (which works): http://pastebin.com/E5iBtt2t
>> puppet agent --test (doesn't work): http://pastebin.com/GsA81Eyx
>
>
> I didn't try using apply but it does look very similar to my problem.
>
> On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>>>
>>> On Dec 7, 2012 12:08 AM, "jcbollinger" <john.bo...@stjude.org> wrote:
>>> >
>>> >
>>> >
>>> > On Tuesday, December 4, 2012 8:10:00 PM UTC-6, Pete wrote:
>>> >>
>>> >>
>>> >> One last question.
>>> >> I use a node level variable to specify the location of a node.
>>> >> I use this for setting variables specific to that location like
>>> different puppet master ip and nagios ip for the office and such.
>>> >> I want to use that variable in hiera for the same purpose.
>>> >> I have this in my hiera.yaml file.
>>> >>
>>> >> ---
>>> >> :hierachy:
>>> >> - %{::clientcert}
>>> >> - %{::environment}
>>> >> - %{location}
>>> >> - virtual_%{::is_virtual}
>>> >> - common
>>> >> :backends: yaml
>>> >> :yaml:
>>> >> :datadir: /etc/puppet/hieradata
>>> >>
>>> >> it gets data from the common.yaml file but is seems to not get
>>> anything from any of the other files.
>>> >> it's definitely using the datadir because thats where the common.yaml
>>> file is as well as the rest of the data files.
>>> >> Am I missing something?
>>> >>
>>> >
>>> > You are missing that node variables are not globals, and in fact don't
>>> even have qualified names. I strongly suspect that that is why Hiera is
>>> not seeing them.
>>>
>>> That explains a why location isn't seen.
>>>
>>> I discovered later that hiera didn't seem to be using the facts either...
>>>
>>> Do I need to do something else to allow hiera to see facts?
>>> I am assuming if I can use facts I will work out how to set location as
>>> a fact and just use it that way.
>>>
>>> As an aside, are ENC variables global?
>>> I have been tempted to use my freeipa server as an ENC using ldap.
>>>
>>> I have also been tempted to have a go at writing an ldap backend for
>>> hiera but that's another story...
>>>
>>> >
>>> > There are several potential workarounds, among them:
>>> > set the needed variable(s) at top-level, based on some sort of
>>> conditional
>>>
>>> I was under the impression that node level variables were top level
>>> variables but I am guessing I am wrong. Time to find some docs I guess. :)
>>>
>>> > push all the contents of your node blocks into classes, so that the
>>> variables in question become class variables
>>>
>>> I am going to assume from that class variables are global because they
>>> have qualified names?
>>>
>>> > instead of creating a separate hierarchy level with a data file for
>>> each value of (say) $environment,use a hash of hashes in the level below,
>>> with the $environment values as the outer hash keys
>>> >
>>> > Cheers,
>>> >
>>> > John
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "Puppet Users" group.
>>> > To view this discussion on the web visit https://groups.google.com/d/*
>>> *msg/puppet-users/-/**1Ajo2OXHPC4J<https://groups.google.com/d/msg/puppet-users/-/1Ajo2OXHPC4J>
>>> .
>>> >
>>> > To post to this group, send email to puppet...@googlegroups.com.
>>> > To unsubscribe from this group, send email to puppet-users...@**
>>> googlegroups.com.
>>>
>>> > For more options, visit this group at http://groups.google.com/**
>>> group/puppet-users?hl=en<http://groups.google.com/group/puppet-users?hl=en>
>>> .
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/puppet-users/-/Gjgrw66TRWkJ.
>>
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
