New config format

[mouchymouchy]

Hi everyone

In version 5.2, old-style format of config file will not be supported anymore nativelly.
https://doc.powerdns.com/recursor/yamlsettings.html

Is there a plan to switch in a fully managed file with epp file and yaml generation ?

How can we manage that ?

[ju5t]

@mouchymouchy There are no plans yet, but if you have the time to PR this we can review it.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. We get that this might not be what you had expected but we're trying to limit stale as issues as much as possible. Thank you for your contributions.

[saz]

As long as the new format isn't supported, starting with 5.2, old-style settings must be enabled:

[saz]

@ju5t Can you reopen this issue? At least for the recursor, the old style config format will be dropped in a future release.

Besides that, the current way isn't working, if you drop a setting, as file_line won't remove this. You either need to be explicit and add powerdns::config with ensure => absent or you need to do the cleanup manually.

This is quite an unexpected behavior, especially if someone makes manual changes, as they won't be cleaned up.

Looking at PowerDNS/pdns#14574, it seems as if there will be changes in the future for the authoritative server.

Maybe we can use this as an opportunity to improve the config handling a bit? Theoretically, it might be enough to just accept a config hash and dump it into a file. This will make things "harder" for a user of the module, as the recursor (and potentially the authoritative) config must be known, but it's partially the case right now already.

Stick to the current way with all downsides and use the new format if the version number is >= 5.0.0 but match things properly, might also be a possible way.

[ju5t]

@saz I agree that this should be done differently.

Perhaps a solution could be to implement the new YAML config and drop the old way of configuring the module. We can release a breaking release (v6) so whoever needs to upgrade to the new YAML config can just use the latest version. People who'd like to stick to an older version of PowerDNS can use v5. I would prefer if we can stick to powerdns::config as it does make the upgrade path for a user easier.

This does mean we would have to block old versions of PowerDNS. I'm not sure what the schedule is of the authoritative YAML config, but it might be preferred to release v6 when that's finished too.

Stick to the current way with all downsides and use the new format if the version number is >= 5.0.0 but match things properly, might also be a possible way.

We might have to do this if the authoritative config update takes too long.

I don't have much time to implement the new config format myself. We're not using Puppet extensively anymore either so I'm a bit out of touch with the latest standards/methods of Puppet.

[saz]

I think keeping powerdns::config will become quite complex, when creating only one file.

Maybe it makes sense to manage settings in separate config files and just set the include part in the main config? This should also work for yaml and might make a transition easier.

[saz]

Seems like, it's done like that when running PowerDNS as container: https://github.com/PowerDNS/pdns/blob/master/Docker-README.md#usage

[ju5t]

Seems like PowerDNS haven't even implemented YAML yet in their own Ansible module.

I think keeping powerdns::config will become quite complex, when creating only one file.

Ok. I liked that concept, but perhaps we can do something similar? What if we only allowed to configure the module by using Hiera? Would that allow us to do some smarter things or is this not recommended?

[saz]

If we create a file per powerdns::config call, it will work as before and I don't see a reason, why this shouldn't be possible. Maybe one or the other must be set directly in the main config, but I'm not really expecting that.

I'll see what I can do in the next couple of days.

Btw, as you've mentioned less usage of puppet: if you're interested, I can clarify if it's fine to move this module over to voxpupuli

[ju5t]

@saz I'm happy to move this to Vox Pupili. I've had a look at moving it before but the process seemed to be very time consuming so I've left things as is.

[saz]

I've tried my idea locally, with the config split in multiple files. I'll create a PR to first move to data-in-module and get rid of params.pp, after that, I'll create a PR for the split config setup.

As this should also work for the yaml-based config, it's easy to add support for that with another PR :-)