On Tuesday, December 18, 2012 9:33:13 AM UTC-8, Ellison Marks wrote:
>
> You're looking for the hiera_include() function, I believe. It's
> undocumented in the official docs, which is a shame, but I'll try to
> describe it.
>
> Your node definition would look something like this:
>
> node default {
> hiera_include('classes')
> }
>
> This instructs every node to look up the classes variable in hiera. It
> doesn't *need* to be named classes, but I like that name. This variable
> should evaluate to a list of strings. Each of these strings will then be
> treated as a class name and puppet will attempt to 'include' it. You make
> your hierarchy so that each node gets an appropriate list.
>
>
>
Hmm. Thanks for the explanation. It sounds *potentially* useful. However,
still one problem:
I dont think it's additive.
In other words, you cant have a truly modular flow in hiera, where you have
the following pseudocode
$(allhosts ) => gets 'classes' list from common.yaml
$(dbmachines) => gets additional classes from dbhosts.yaml
$(webmachines) => gets additional classes from webhosts.yaml
If you want a host that is both a db machine, AND a webserver, you need to
create a new hiera file,
dbandwebhost.yaml
and then make sure that all machines in that context, get pointed to that
specific file, rather than getting to merge things.
The only method I see that uses the "pure" hiera_include method you show
above, and still allows for mix-and-max class includes, would be to
handcraft individual
FQDN.yaml
files for each and every host. ?
--
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/-/MSluxgsFuWYJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
