I have been thinking about a good way to include things in Hiera--that is,
to insert a directive to add another stream. The problem is one of
attachment: inserting things becomes complex when you think much about it.
Consider the following:
---
key1: value1
key2: value2
key3: '%include values/me.yaml'
And a me.yaml:
---
:value: value3
Does that make sense? The result would be:
---
key1: value1
key2: value2
key3: value3
How about this me.yaml:
---
:value:
- element3.1
- element3.2
- element3.3
Giving the result:
---
key1: value1
key2: value2
key3:
- element3.1
- element3.2
- element3.3
And predictably with a hash:
---
:value:
subkey1: element3.1
subkey2: element3.2
subkey3: element3.3
And the result:
---
key1: value1
key2: value2
key3:
subkey1: element3.1
subkey2: element3.2
subkey3: element3.3
We could even predict shell globs, such that the following works:
---
key1: value1
key2: value2
vhosts: '%include vhosts/*.yaml'
Now here's the trick: What if you want to expand from a base?
---
key1: value1
key2: value2
key3:
- element1
- element2
- '%include values/me.yaml'
And you want a result like
---
key1: value1
key2: value2
key3:
- element1
- element2
- element3
- element4
You might say, "But wait, with an array this always makes sense because an
array can't blind-insert a value" (can it?), so something like this would
make no sense:
---
key1: value1
key2: value2
key3:
- element1
- element2
-
- element3
- element4
But what happens when you want to blindly append to a hash?
---
key1: value1
key2: value2
key3:
subkey1: element1
subkey2: element2
'%include values/key3.yaml'
This does not appear well-formed... and similarly unpalatable is the idea
of using a different semantic for this case:
---
key1: value1
key2: value2
key3:
subkey1: element1
subkey2: element2
':%include': values/key3.yaml
This is fairly significant because there are instances--for example, I'm
sitting on one--where you have an Apache httpd.conf that's, oh, what is
it... 4976 lines long, about 4500 of which are vhost definitions.
The Puppetlabs Apache module breaks vhosts out into individual files, just
like debian, even on CentOS/RHEL. This is a better way... trust me I've
done it both ways, extensively. I've worked in environments where having a
huge httpd.conf caused major pain and interruptions to our SLAs that we
handwaved away by having fine-print text that reads "99.99% uptime refers
to network uptime. We cannot guarantee against software or hardware
failures." Turns out multi-editing httpd.conf from vi causes problems
sometimes.
But what you get for your trouble is 300-500 virtual hosts defined in one
big friggin' YAML file, just so you can create a node that calls:
create_resources('apache::vhost', hiera('vhosts'))
create_resources('nginx::vhost', hiera('vhosts'))
And, you see, therein lies the problem. Sometimes you really, really want
a hierarchy like:
data/
common.yaml
nodes/
web-01.yaml
web/
vhosts-enabled/
*.yaml
Especially if you have automated systems dropping files in and out of these
directories, i.e. to create/delete/enable/disable sites. Kind of removes
data hotspots.
Perhaps a merge directive would be easier, like hiera_hash():
# web.yaml
---
:merge: web/vhosts/*
vhosts:
# web/vhosts/vhost1.yaml
---
vhosts:
www.example.com:
docroot: '/var/www/sites/www.example.com/html'
priority: 1
Thoughts? I kind of want to file a competent Feature Request on this that
proscribes a good way forward.
--
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 post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
