Hiera Integration

[sakibsys]

First of all thanks you so much for writing such a nice module. I am running into an issue where I need to pull following IP address from hiera.

I have multiple bind servers running in multiple region and most of the servers are slave servers. Also, we're using puppet role base installation.

Below is my named.conf.option file.

dns::server::options { '/etc/named/named.conf.options': listen_on_port => '53', listen_on => [ '127.0.0.1', '1.2.3.4' ], dump_file => '/var/named/data/cache_dump.db', statistics_file => '/var/named/data/named_stats.txt', memstatistics_file => '/var/named/data/named_mem_stats.txt', allow_query => [ any ], transfers => [ '1.3.4.0/8' ], allow_notify => [ '1.3.4.0/8' ], also_notify => [ '1.3.4.5', '6.7.8.9' ], recursion => 'yes', } }

What do I have to add/modify in your module in order to add above values in Hiera ?

[solarkennedy]

This part of this module is not designed to be integrated with hiera directly.

However you can use the hiera() or lookup() function to get a value out of hiera and inject it into any manifest. https://puppet.com/docs/hiera/3.3/puppet.html#hiera-lookup-functions https://puppet.com/docs/puppet/5.3/hiera_use_function.html

[ghost]

The most direct translation of your code above to using Hiera is:

---

$listen_on_port     = hiera('dns::server::options::listen_on_port', undef)
$listen_on          = hiera_array('dns::server::options::listen_on', undef)
$dump_file          = hiera('dns::server::options::dump_file', undef)
$statistics_file    = hiera('dns::server::options::statistics_file', undef)
$memstatistics_file = hiera('dns::server::options::memstatistics_file', undef)
$allow_query        = hiera_array('dns::server::options::allow_query', undef)
$transfers          = hiera_array('dns::server::options::transfers', undef)
$allow_notify       = hiera_array('dns::server::options::allow_notify', undef)
$also_notify        = hiera_array('dns::server::options::also_notify', undef)
$recursion          = hiera('dns::server::options::recursion', undef)

dns::server::options { '/etc/named/named.conf.options':
    listen_on_port     => $listen_on_port,
    listen_on          => $listen_on,
    dump_file          => $dump_file,
    statistics_file    => $statistics_file,
    memstatistics_file => $memstatistics_file,
    allow_query        => $allow_query,
    transfers          => $transfers,
    allow_notify       => $allow_notify,
    also_notify        => $also_notify,
    recursion          => $recursion,
}

---

Hiera:

dns::server::options::listen_on_port:     '53'
dns::server::options::listen_on:
    - '127.0.0.1'
    - '1.2.3.4'
dns::server::options::dump_file:          '/var/named/data/cache_dump.db'
dns::server::options::statistics_file:    '/var/named/data/named_stats.txt'
dns::server::options::memstatistics_file: '/var/named/data/named_mem_stats.txt'
dns::server::options::allow_query:
    - 'any'
dns::server::options::transfers:
    - '1.3.4.0/8'
dns::server::options::allow_notify:
    - '1.3.4.0/8'
dns::server::options::also_notify:
    - '1.3.4.5'
    - '6.7.8.9'
dns::server::options::recursion:          'yes'

---

This assigns a variable for each parameter from the dns::server::options defined type. Each such parameter/variable is pulled from a correspondingly named Hiera key. Any parameter that is not found in Hiera gets an undef value, which means the dns::server::options defined type will use its own default value for that parameter. Arrays use the hiera_array function in order to merge arrays found in different parts of the Hiera hierarchy; if this is not desired, the hiera_array calls can be replaced by straight hiera calls.

Unfortunately, I don't know the syntax or semantics for the new lookup function which replaces the hiera class of functions, so I can't give an example using that.

[sakibsys]

Thanks you so much for your help. Its working perfectly.

[solarkennedy]

@jearls do you think we should give up on the idea of having the options file as define and instead make it a class, forcing people to only have "1" of them and allowing them to use native hiera lookups?

[ghost]

To be honest, I think the way its implemented right now makes no sense -- forcing the consumer of the module to specify the path to the options file when that path is already hard-coded into the main template. As a class, you could have an optional parameter for the path to the options file which people could use if they're providing their own template for the main named.conf file that puts the options somewhere else, but otherwise use the default parameters to just get the "right" path in the first place.

However, it might make sense to use a modified version of the defined type if there is a reason to have more than one options file - for example, to have a different set of options for a view, where the defined type has a view parameter and uses that parameter to determine if the options file goes into the path used by the main template or a view-specific path. However, I don't know if the idea of view-specific options actually makes any sense.

In either case, it's a major version change to either replace the defined type with a class or to redo the defined type to be useful for multiple options files.