Class: Hiera

Inherits:
Object show all
Defined in:
modules/wmflib/lib/hiera/backend/nuyaml_backend.rb,
utils/hiera_lookup.rb,
modules/wmflib/lib/hiera/httpcache.rb,
modules/wmflib/lib/hiera/backend/role_backend.rb,
modules/wmflib/lib/hiera/backend/proxy_backend.rb,
modules/wmflib/lib/hiera/backend/role3_backend.rb,
modules/wmflib/lib/hiera/backend/netbox_backend.rb,
modules/wmflib/lib/hiera/backend/secret_backend.rb,
modules/wmflib/lib/hiera/backend/nuyaml3_backend.rb,
modules/wmflib/lib/hiera/backend/private_backend.rb,
modules/wmflib/lib/hiera/backend/httpyaml_backend.rb,
modules/wmflib/lib/hiera/backend/private3_backend.rb,
modules/puppetdbquery/lib/hiera/backend/puppetdb_backend.rb

Overview

Nuyaml Hiera backend - the yaml backend with some sugar on top

Based on the original yaml_backend from hiera distribution, any modification/addition: Author: Giuseppe Lavagetto <glavagetto@wikimedia.org> Copyright © 2014 Wikimedia Foundation

This backend allows some more flexibility over the vanilla yaml backend, as path expansion in the lookup.

Private path

If you define a 'private' data source in hiera, we will look up in a data.yaml file in the data dir we've specified as the datadir for a 'private' backend, or in the default datadir as a fallback.

Path expansion

Any hierarchy named in the backend-configuration section :expand_path be expanded when looking the file up on disk. This allows both to have a more granular set of files, but also to avoid unnecessary cache evictions for cached data.

Example

Say your hiera.yaml has defined

:nuyaml:

:expand_path:
  - module_data

:hierarchy:

- common
- module_data

then when searching hiera for say passwords::mysql::s1, hiera will first load the #datadir/common.yaml file and search for passwords::mysql::s1, then if not found, it will search for 's1' inside the file #datadir/module_data/passwords/mysql.yaml

Unless very small, all files should be split up like this.

Regexp matching

As multiple hosts may correspond to the same rules/configs in a large cluster, we allow to define a self-contained “regex.yaml” file in your datadir, where each different class of servers may be represented by a label and a corresponding regexp.

Example

Say you have a lookup for “cluster”, and you have “regex/%hostname” in your hierarchy; also, let's say that your scope contains hostname = “web1001.local”. So if your regex.yaml file contains:

databases:

__regex: !ruby/regex '/db.*\.local/'
cluster: db

webservices:

__regex: !ruby/regex '/^web.*\.local$/'
cluster: www

This will make it so that “cluster” will assume the value “www” given the regex matches the “webservices” stanza

Defined Under Namespace

Modules: Backend Classes: Config, Httpcache