> > 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.
