Here’s a really good reason. First off, unless your hiera.yaml is super complicated, then it probably doesn’t need to be in version control. However, for a lot of deployments you need it in VC, but not in your control repo (i.e., the one that r10k will access for Puppetfile, hieradata and build our corrosponding enviros for on your master).
No, place that hiera.yaml in it’s own VC repo.
I had a control repo with:
1 2 3
and I kept running in to this:
This was a very simple test to see if my
production environment was grabbing the correct data via a message K,V in
Check out the –debug
1 2 3 4 5 6 7 8
So I copied the
datafile path and redirected it to a diff along with a ```$(pwd) while in the /etc/puppetlabs/puppet/environments/production/hieradata directory:
1 2 3 4 5
$datadir path in hiera.yaml
is indeed missing that f-ing ‘n’. Why? Because this was the second time this happened to me today.
Really? The second time? Really. The second fucking time.
I previously committed hiera.yaml along with hieradata/ and my Puppetfile to branch production. I tested it and came across this problem. Did the same test to figure out the correct path and updated hiera.yaml.
However, hiera.yaml was also in my development and staging branches. I didn’t update those. So here I was again doing tests on development data for Puppet and boom my shit’s broken again.
Since hiera.yaml is only used singularly on a puppet run, i.e., it’s not consulted on a per environment basis, you only need one copy of it, and that’s the one in your puppet $confdir. Having it scattered to the winds with r10k in the control repo does not give you any extra functionality (yet, someday we might make it enviro aware, but currently is not the case).
So if you’re going to run your hiera.yaml into a VCS then do it in it’s own monolithic repo. You can symlink it into the $confdir for Puppet.