Fix configured_zones behaviour

[aanriot]

Hello,

With the latest commits, we unconditionally perform a file.managed state because the file argument is always defined. I think that it breaks the previous configured_zones behaviour, as we may want to declare a zone (and bind has to know the filename) without managing it.

Feel free to comment.

[aanriot]

GitHub doesn't allow me to add you as a reviewer @crux-capacitor, but please feel free to comment as well.

[crux-capacitor]

Hi @aanriot,

The file argument is optional underneath configured_views:<view>:configured_zones:<zone>. If you do specify it, it allows you to declare the file to be used that you configured underneath available_zones:<zone>, otherwise the code will choose the file based on the zone under available_zones that matches the zone name for the current view in the loop.

Your code adds a way to not create the zone file?

[aanriot]

Hi @aanriot,

The file argument is optional underneath configured_views:<view>:configured_zones:<zone>. If you do specify it, it allows you to declare the file to be used that you configured underneath available_zones:<zone>, otherwise the code will choose the file based on the zone under available_zones that matches the zone name for the current view in the loop.

Your code adds a way to not create the zone file?

Thanks @crux-capacitor . That's true. Previously, it was possible to declare a zone (and its path) and edit the occurring zone file manually. Currently, I have a server on which we manage the bind configuration, but not the content of the zone files, mainly because they contain static records as well as dynamic records.

[aboe76]

@aanriot can this behavior be documented somewhere?

[aanriot]

@aanriot can this behavior be documented somewhere?

@aboe76 If I understand correctly the doc, it's already at https://github.com/saltstack-formulas/bind-formula#external-zone-files.

But it should probably be rewritten accordingly with pillar.example if we choose to move forward with the clarification attempt @javierbertoli mentionned.

[aanriot]

Closing this PR as it will not be merged, refactoring attempts will be tracked in #114.