> > You might find it convenient and logical to structure it as one > > large, complex, nested value, from which the individual > > components would select the pieces they need. For example, a > > hash with VM hostnames as keys, and hashes of VM names to VM > > parameter hashes as values (i.e. a trebly-nested hash). > > Alternatively, there are ways you could spread out the data over > > multiple Hiera keys, but the overall logical structure is going > > to be similar. > > *nodnod* OK, that seems sane, thanks.
Thanks again for the push there; it really helped. FWIW, what I've got is actually a hybrid, combining a structured giant hiera data tree with hierarchical class overrides; this seems useful so I'll show y'all. Here's a snippet of the hosts structure, which lives in hosts.yaml: - ---------------- hosts: dev01.[snip]: # type, environment, and site are all used to *find* what we # inherit from in hiera, and hence cannot themselves be inherited, # or at least not in a reasonable fashion fqdn: dev01.[snip] type: cytoweb type_version: 3 environment: dev site: dev01 ipv6: false ipv4: true ipv4_ip: [snip] openvzid: 6222 openvzhost: ds518 qa01.[snip]: # type, environment, and site are all used to *find* what we # inherit from in hiera, and hence cannot themselves be inherited, # or at least not in a reasonable fashion fqdn: qa01.[snip] type: cytoweb type_version: 2 environment: qa site: qa01 ipv6: false ipv4: true ipv4_ip: [snip] openvzid: 8589 openvzhost: ds988 - ---------------- Here's the relevant bit of site.pp; *all* other puppet decisions are hiera driven: - ------------- $hosts = hiera_hash('hosts') $host_type = $hosts[$fqdn]['type'] $host_type_version = $hosts[$fqdn]['type_version'] # Make sure our type can be loaded $type_test = hiera('type_loaded') notify{ "sphtf": message => "site.pp: host type file: hiera/types/${::host_type}_v$host_type_version" } $host_environment = $hosts[$fqdn]['environment'] $host_site = $hosts[$fqdn]['site'] node default { notify{ "spht": message => "site.pp: host type: $::host_type" } notify{ "sphtv": message => "site.pp: host type version: $::host_type_version" } hiera_include('classes') } - ------------- So we grab some specific bits out of the host structure for the current host, but then, and this is the fun part, we *turn them back into hiera selectors*; this is my hiera.yaml: - ------------- --- :backends: - yaml :yaml: :datadir: /opt/puppet3/etc/hiera :hierarchy: - node/%{::fqdn} - types/%{::host_type}_v%{::host_type_version} - site/%{::host_site} - environments/%{::host_environment} - os/%{::operatingsystem} - osfamily/%{::osfamily} - hosts - sites - users - common # options are native, deep, deeper :merge_behavior: deeper - ------------- So this means that qa01.[snip] can have behaviour driven by information in the global hosts structure, which can be accessed by everybody for global things like generating an /etc/hosts file, *and* it can have hiera/node/qa01.[snip] , which can have class overrides like: sudo::dev_sudo: true or whatever. Note in addition that with "deeper" merging setup, if you use hiera_hash as I've done, you can actually override bits of the structure. We don't use this for the hosts structure, but we *do* use it for users: create_resources( users::user, hiera_hash('users::users') ) is how that structure gets used, and individual hosts can have things like: --- users::users: stu: ensure: present until: 'Mon Jun 24 12:59:12 PDT 2013' andrew: ensure: present until: 'Mon Jun 24 12:59:12 PDT 2013' in their node/hostname.[snip] files, which will override those parts of the users::user structure, in which those users default to "enable: false". users::user, like hosts, is a big giant nested hash. Hopefully this all is of use to someone. -Robin -- 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. For more options, visit https://groups.google.com/groups/opt_out.