On Monday, December 10, 2012 7:25:30 PM UTC-6, Schofield wrote:
>
> I am working with puppet 3.0 and have the opportunity to build the hiera
> hierarchy from scratch. I am pondering which data should be included in
> hiera and how it should be organized. After some research it appears that
> most folks struggle when their data is dependent on multiple facts rather
> than a strict hierarchical data structure. For example: a value depends on
> the node location *and *what environment it is in dev|test|qa|prod.
>
Well, yes. Hiera is an hierarchical data store. It works great if you can
put your data in a well-defined priority hierarchy, because that's what
it's designed to handle. It is flexible enough to support some kinds of
deviations from a strict hierarchy, but the further you go from an
hierarchical structure, the worse Hiera supports it. if your data isn't
something reasonably close to hierarchical, then you might be better off
choosing or creating an altogether different data store.
>
> In my mind a hiera hierarchy like the following which is based on network
> location of a node would work great because each level is more specific and
> a subset of the previous making overrides very clear and clean.
>
> - fqdn - for node specific overrides
> - cluster - cluster specific overrides
> - network - all clusters are isolated on a network segment.
> - common - the default
>
>
Absolutely. That sort of thing is Hiera's bread & butter.
Now the difficult part is that I also want to externalize data in to hiera
> based on the network location *and *the environment. This becomes more
> complex if a third variable is added.
>
> So the question is: Is there a best practice for handling hiera data
> values based on multiple attributes? In this case location *and
> *environment.
> One doesn't take precedence over the other but both are needed to find a
> unique and correct value.
>
>
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)
Those can be used separately or in combination, and even in
self-combination, so in principle, you can use as many dimensions as you
want. In practice, it can get very messy, very quickly.
The best Hiera approach for any given situation is highly dependent on the
data that need to be stored and served. Factors such as whether
commonalities are coincidental or by design, and who has logical
administrative control over the data may be important.
Supposing that you want to support a site under a single, unified
administration and with a lot of commonality between different
environments, I would suggest considering using option (1) above to add a
dimension for environment. That would manifest in the hierarchy definition
in your hiera.yaml file, which might look something like this:
:hierarchy:
- %{fqdn}
- %{environment}/%{cluster}
- %{cluster}
- %{environment}/%{network}
- %{network}
- %{environment}/common
- common
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/-/ftw3X9LMm8gJ.
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.
