class Hiera

Loggers are pluggable, just provide a class called Hiera::Foo_logger and respond to :warn and :debug

See hiera-puppet for an example that uses the Puppet loging system instead of our own

# File lib/hiera.rb, line 23
def logger=(logger)
  require "hiera/#{logger}_logger"

  @logger = Hiera::FallbackLogger.new(
    Hiera.const_get("#{logger.capitalize}_logger"),
    Hiera::Console_logger)
rescue Exception => e
  @logger = Hiera::Console_logger
  warn("Failed to load #{logger} logger: #{e.class}: #{e}")
end

If the config option is a string its assumed to be a filename, else a hash of what would have been in the YAML config file

# File lib/hiera.rb, line 42
def initialize(options={})
  options[:config] ||= File.join(Util.config_dir, 'hiera.yaml')

  @config = Config.load(options[:config])

  Config.load_backends
end

version is a public API method intended to always provide a fast and lightweight way to determine the version of hiera.

The intent is that software external to hiera be able to determine the hiera version with no side-effects. The expected use is:

require 'hiera/version'
version = Hiera.version

This function has the following ordering precedence. This precedence list is designed to facilitate automated packaging tasks by simply writing to the VERSION file in the same directory as this source file.

1. If a version has been explicitly assigned using the Hiera.version=
   method, return that version.
2. If there is a VERSION file, read the contents, trim any
   trailing whitespace, and return that version string.
3. Return the value of the Hiera::VERSION constant hard-coded into
   the source code.

If there is no VERSION file, the method must return the version string of the nearest parent version that is an officially released version. That is to say, if a branch named 3.1.x contains 25 patches on top of the most recent official release of 3.1.1, then the version method must return the string “3.1.1” if no “VERSION” file is present.

By design the version identifier is not intended to vary during the life a process. There is no guarantee provided that writing to the VERSION file while a Hiera process is running will cause the version string to be updated. On the contrary, the contents of the VERSION are cached to reduce filesystem accesses.

The VERSION file is intended to be used by package maintainers who may be applying patches or otherwise changing the software version in a manner that warrants a different software version identifier. The VERSION file is intended to be managed and owned by the release process and packaging related tasks, and as such should not reside in version control. The VERSION constant is intended to be version controlled in history.

Ideally, this behavior will allow package maintainers to precisely specify the version of the software they're packaging as in the following example:

$ git describe --match "1.2.*" > lib/hiera/VERSION
$ ruby -r hiera/version -e 'puts Hiera.version'
1.2.1-9-g9fda440

@api public

@return [String] containing the hiera version, e.g. “1.2.1”

# File lib/hiera/version.rb, line 62
def self.version
  version_file = File.join(File.dirname(__FILE__), 'VERSION')
  return @hiera_version if @hiera_version
  if version = read_version_file(version_file)
    @hiera_version = version
  end
  @hiera_version ||= VERSION
end

::read_version_file reads the content of the “VERSION” file that lives in the same directory as this source code file.

@api private

@return [String] for example: “1.6.14-6-gea42046” or nil if the VERSION

file does not exist.

# File lib/hiera/version.rb, line 83
def self.read_version_file(path)
  if File.exists?(path)
    File.read(path).chomp
  end
end

Calls the backends to do the actual lookup.

The scope can be anything that responds to `[]`, if you have input data like a Puppet Scope that does not you can wrap that data in a class that has a `[]` method that fetches the data from your source. See hiera-puppet for an example of this.

The order-override will insert as first in the hierarchy a data source of your choice.

Possible values for the resolution_type parameter:

• :priority - This is the default. First found value is returned and no merge is performed

• :array - An array merge lookup assembles a value from every matching level of the hierarchy. It retrieves all

  of the (string or array) values for a given key, then flattens them into a single array of unique values.
  If _priority_ lookup can be thought of as a “default with overrides” pattern, _array_ merge lookup can be though
  of as “default with additions.”

• :hash - A hash merge lookup assembles a value from every matching level of the hierarchy. It retrieves all of

  the (hash) values for a given key, then merges the hashes into a single hash. Hash merge lookups will fail with
  an error if any of the values found in the data sources are strings or arrays. It only works when every value
  found is a hash. The actual merge behavior is determined by looking up the keys `:merge_behavior` and
  `:deep_merge_options` in the Hiera config. `:merge_behavior` can be set to `:deep`, :deeper` or `:native`
  (explained in detail below).

• _{ deep merge options }_ - Configured values for `:merge_behavior` and `:deep_merge_options`will be completely

  ignored. Instead the _resolution_type_ will be a `:hash` merge where the `:merge_behavior` will be the value
  keyed by `:behavior` in the given hash and the `:deep_merge_options` will be the remaining top level entries of
  that same hash.

Valid behaviors for the :hash resolution type:

• native - Performs a simple hash-merge by overwriting keys of lower lookup priority.

• deeper - In a deeper hash merge, Hiera recursively merges keys and values in each source hash. For each key,

  if the value is:
     - only present in one source hash, it goes into the final hash.
     - a string/number/boolean and exists in two or more source hashes, the highest priority value goes into
       the final hash.
     - an array and exists in two or more source hashes, the values from each source are merged into a single
       array and de-duplicated (but not automatically flattened, as in an array merge lookup).
     - a hash and exists in two or more source hashes, the values from each source are recursively merged, as
       though they were source hashes.
     - mismatched between two or more source hashes, we haven’t validated the behavior. It should act as
       described in the deep_merge gem documentation.

• deep - In a deep hash merge, Hiera behaves the same as for deeper, except that when a string/number/boolean

  exists in two or more source hashes, the lowest priority value goes into the final hash. This is considered
  largely useless and should be avoided. Use _deeper_ instead.

The merge can be given as a hash with the mandatory key `:strategy` to denote the actual strategy. This is useful for the `:deeper` and `:deep` strategy since they can use additional options to control the behavior. The options can be passed as top level keys in the `merge` parameter when it is a given as a hash. Recognized options are:

- 'knockout_prefix' Set to string value to signify prefix which deletes elements from existing element. Defaults is _undef_
- 'sort_merged_arrays' Set to _true_ to sort all arrays that are merged together. Default is _false_
- 'merge_hash_arrays' Set to _true_ to merge hashes within arrays. Default is _false_

@param key [String] The key to lookup @param default [Object,nil] The value to return when there is no match for key @param scope [#[],nil] The scope to use for the lookup @param order_override [#[]] An override that will considered the first source of lookup @param resolution_type [String,Hash<Symbol,String>] Symbolic resolution type or deep merge configuration @return [Object] The found value or the given default value

# File lib/hiera.rb, line 111
def lookup(key, default, scope, order_override=nil, resolution_type=:priority)
  Backend.lookup(key, default, scope, order_override, resolution_type)
end