Unable to call unbound::local_zone class anymore about puppet-unbound

[b4ldr]

@jlutran can you expand more on your use case? would something like the following work

$default_local_zone = { '.' => 'refuse' }
$nsd_zones = lookup('nsd::zones').keys
$local_zones = $nsd_zones.reduce($default_local_zone) |$memo, $zone| {
  $tmp = merge($memo, {$zone => 'transparent'})
  $tmp
}
class {'unbound':
 $local_zone = $local_zones
}

[jlutran]

I use unbound::local_zone as a resolver whitelist on my hosts :

1. Set resolver to localhost only
2. Disable all zones resolving ({ '.' => 'refuse' })
3. Add custom zones using multiple unbound::local_zone calls in separate puppet profiles

Your code above is working, but hard to implement in my case because ::unbound::local_zone class is called from multiple puppet manifests.

[b4ldr]

@xaque208 what do you think of this? i think the use case is a valid one and it is maybe worth bringing back the local_zone type. however it may be initiative unless we once again change the structure of the unbound::local_zone variable so it can be used with create_resources, e.g.

class{ 'unbound'
  local_zone => { 'example.com' => { 'type' => 'refuse' }
}

this would mean the current method like the following would stop working

class{ 'unbound'
  local_zone => { 'example.com' => 'refuse' }
}

the other options is to create a resource that can add local_zone data with a different format to unbound::local_zone. this would be similar to unbound::remote vs unbound::local_data. im happy to do the work if you give me direction

[zachfi]

@b4ldr I assume then that the unbound class would then contain a create_resources('unbound::local', $local_zone...) or are you thinking something different?

@jlutran Would storing all of the local_zone data in the same hiera data object be enough for you? I'm curious to learn more about why local_zone is in multiple manifests on the same node. I assume just for organization purposes. Is that right?

[b4ldr]

@b4ldr I assume then that the unbound class would then contain a create_resources('unbound::local', $local_zone...) or are you thinking something different?

yes, it would mean going back to the old way of doing it.

[zachfi]

Bringing back the local_zone class while also supporting a parameter on the unbound class that, if defined, is passed to create_resources seems like the best of both worlds. I'm speculating here, as I don't use the feature, but users would be able to define the resources centrally in hiera, or scattered throughout the manifest.

[jlutran]

@jlutran Would storing all of the local_zone data in the same hiera data object be enough for you? I'm curious to learn more about why local_zone is in multiple manifests on the same node. I assume just for organization purposes. Is that right?

I use a default unbound profile, and then set some local zones on custom roles. For example :

class profiles::unbound(
    $default_nameservers = hiera('public_nameservers', []),
    $proxy_endpoint = hiera('proxy', undef),
    $git_endpoint = hiera('git_source', undef),
) {
    unbound::forward { '.': address => $default_nameservers }
    ensure_resource('unbound::local_zone', '.', { 'type' => 'refuse' })
    ensure_resource('unbound::local_zone', $default_sync_server, { 'type' => 'transparent' })

    if( $proxy_endpoint ) {
        $proxy_domain = regsubst($proxy_endpoint, '^http[s]?://([^:/]+).*$', '\1')
        ensure_resource('unbound::local_zone', $proxy_domain, { 'type' => 'transparent' })
    }
    if( $git_endpoint ) {
        $git_domain = regsubst($git_endpoint, '^http[s]?://([^:/]+).*$', '\1')
        ensure_resource('unbound::local_zone', $git_domain, { 'type' => 'transparent' })
    }
}

class profiles::custom_role($metrics_endpoint) {
    ensure_resource('unbound::local_zone', $metrics_endpoint, { 'type' => 'transparent' })
}

And so on...

[zachfi]

#182 has been merged to resolve this. Apologies for the trouble.