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

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.

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