variable not being picked up by hiera hierarchy

164 views
Skip to first unread message

David LeVene

unread,
Aug 11, 2014, 2:30:21 AM8/11/14
to puppet...@googlegroups.com
Hey All,

I'm trying to setup environments as well as splitting up the configs to correctly manage various hosts we have - but I'm running into an issue where a variable defined does not seem to be picked up on a puppet run.

I'm only referring to one hierarchy so I've left out a few of the other bits to simplify things - the setup of datadir not containing hieradata is due to how everything else is setup.

#cat hiera.yaml
---
:backends:
  - yaml
:yaml:
  :datadir: /etc/puppet
:hierarchy:
  - environments/%{environment}/hieradata/virtual_%{::is_virtual}
  - environments/%{environment}/hieradata/virtsh_hosting_%{is_virsh_hosting}
  - environments/%{environment}/hieradata/common
  - hieradata/virtual_%{::is_virtual}
  - hieradata/virtsh_hosting_%{is_virsh_hosting}
  - hieradata/common

I have a node definition which includes a class called "class virthost {" the first line of this config is

    #Used to define if its a virthost for use in hiera configs
    $is_virsh_hosting=true

as you can see from the above, i'm using the variable so i can have a file called
  • virtsh_hosting_true.yaml sitting inside hieradata which works as expected.
When performing the test using hiera - i get the expected results in both my environment & prod setup 

# hiera -d augeas_libs_version -c /etc/puppet/hiera.yaml is_virsh_hosting=true
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Hiera YAML backend starting
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Looking up augeas_libs_version in YAML backend
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Looking for data source hieradata/virtual_
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Cannot find datafile /etc/puppet/hieradata/virtual_.yaml, skipping
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Looking for data source hieradata/virtsh_hosting_true
DEBUG: Mon Aug 11 15:36:28 +0930 2014: Found augeas_libs_version in hieradata/virtsh_hosting_true
1.0.0-5.el6_5.1


# hiera -d augeas_libs_version -c /etc/puppet/hiera.yaml is_virsh_hosting=true environment=staging
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Hiera YAML backend starting
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Looking up augeas_libs_version in YAML backend
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Looking for data source environments/staging/hieradata/virtual_
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Cannot find datafile /etc/puppet/environments/staging/hieradata/virtual_.yaml, skipping
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Looking for data source environments/staging/hieradata/virtsh_hosting_true
DEBUG: Mon Aug 11 15:36:39 +0930 2014: Found augeas_libs_version in environments/staging/hieradata/virtsh_hosting_true
1.0.0-5.el6_5.1

If it doesn't find it in this file, it default to another version - It needs to be this way due to some legacy setup's on other boxes and we require different version of some libraries.

So, this all looks correct and its returning what I expect it to return, but when I run puppet on the hosts in question, it does not want to use the correct version - its defaulting back to a version further down the tree (in common.yaml)

If i move the intended config into ::is_virtual so its looking at the file virtual_false.yaml it works as expected - but this encompasses more hosts than required.

So my question is... why isn't it picking up my configuration from  $is_virsh_hosting=true ?

$ puppet -V
3.1.1
$ hiera -V
1.1.1

Given the puppet version.. is this bug related to my setup?

Any assistant/guidance would be appreciated.

Cheers
David






David LeVene

unread,
Aug 12, 2014, 8:01:31 PM8/12/14
to puppet...@googlegroups.com
Found my own answer - so though i'd post it here incase anyone else is trying to learn this stuff :)

The variable i was trying to reference was located inside a class, so it would have had to have been referenced as %{classname::variable}, this is considered bad practice as its not a top scope variable and it could run into issues further down the track - my solution was to create a puppet custom fact and reference it via ${::fact_name}

This is a snippet from my custom fact, so I hope it helps someone else;

All the hosts are named type-role-env-loc eg
int-vmhost-testing-location

machine_role.rb is the file name and i had it located in the base module puppet/modules/base/lib/facter <-- stuff in this dir (modulename/lib/facter) is automatically picked up by puppet.

Facter.add('machine_role') do
  setcode do
    $hostname = Facter.value('hostname')
    case $hostname
      when /-vmhost-/
        $machine_role = 'vmhost'
     when /-Othermachinenames-/
        $machine_role = 'whatever'
     default
        $machine_role = 'unknown'
     end
  end
end

so that above creates a puppet custom fact, which facter -p (-p tell it to use puppet custom manifests) will return 
machine_role => <rolename>

If you're testing on a local machine outside of puppet set your path to where the facter file is located

$ export FACTERLIB=~/puppet/modules/base/lib/facter:$FACTERLIB
$ facter machine_role
vmhost

inside hiera.conf i setup a hierarchy and one of the lines was...
 - role/%{::machine_role}

so I had a directory created inside the :datadir: dir called roles which contains files like
vmhost.yaml
whatever.yaml
unknown.yaml

also a quick way to see if things are working properly..

hiera -d -c /path/to/hiera.yaml param_to_check ::machine_role=vmhost

Once you have this setup in puppet and *IF* you have updated your hiera.conf make sure you restart puppet!

This gave me the ability if required to have different conditions for different host types as defined by their hostname.

Cheers
David
Reply all
Reply to author
Forward
0 new messages