On Tuesday, December 11, 2012 11:10:48 AM UTC-6, Schofield wrote:
>
>
> Hiera allows you to lay out your data in two dimensions: data file and
>> key. Whatever selection rules you want to use to choose particular data
>> need to operate in that context. There are at least three ways in which
>> you can embed additional dimensions:
>>
>> 1. You can create separate hierarchies or hierarchy pieces based on
>> node data, by interpolating the data into the hierarchy definition file
>> 2. You can use compound keys
>> 3. You can expand your values into hashes (with the hash keyspace
>> constituting an additional dimension)
>>
>> Would you mind going into detail on options 2 and 3?
>
Option 2:
Instead of having keys of (say) this form:
<module>::<class>::foo
At least some of them have form similar to this:
<environment>__<module>::<class>::foo
Then you account for that specifically when you perform lookups:
foo = hiera("${environment}__mymodule::myclass::foo")
That only works for explicit lookups, however: where you want to provide
for class parameter autolookup then you need to use specific keys. Of
course, I generally recommend using explicit lookups instead of class
parameters anyway, but that's a different discussion.
Option 3:
Luke was right that I was talking about using complex data structures in
your hiera data, but I was trying to describe a somewhat narrower and more
specific use than he recognized. I was suggesting that (some of) your
hiera data can look like this:
mymodule::myclass::foo:
development: dev_foo
production: prod_foo
So that in your manifests you can write:
$foo_hash = hiera('mymodule::myclass::foo')
$foo = foo_hash[$environment]
>
> Getting messy, quickly is my concern if the hierarchy is not the best fit
> for the enterprise or the enterprise architecture changes. Are there any
> rules of thumb to consider that would suggest hiera is not the best data
> externalization tool and someone might be better off with a RDMS or
> denormalized search index as the external data source?
>
>
I don't have any rules of thumb for you, as it really depends a lot on your
priorities, and also somewhat on your available resources. However, I
think some of the hiera metrics you should be evaluating are
- The number of separate files you will need
- The complexity of the data files and their layout
- The amount of data duplication required
- Your manifests' usage of hiera-dependent features (mainly class
parameter autolookup)
Also remember that hiera has some nice advantages stemming from the
relatively simple form its data take. You can put them under version
control alongside your manifests, for example, and you can modify them with
a plain text editor. You don't need any separate software to be running to
get at the data.
Remember too that hiera supports multiple, pluggable back-ends. Instead of
replacing hiera, you could consider just adding a custom back-end for some
of your more unruly data.
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/-/I2lZrL4k8dUJ.
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.
