Open ulvida opened 2 years ago
Note: I'm doing this PR from a personal fork, because I had a very strange problem with our University's fork.
Can you rebase the branch on the current main branch? The molecule/docker directory, is not necessary anymore.
Thanks for the PR.
In general I was wondering how you would like to use the variables , if there are commented.
Wouldn't it make sense to leave them in and rename the variables depending on which templates they are used. So all variables which go into the strict_authoritative templates are preseed with bind9_strictauthoritative ...
Thanks for the PR. thanks for your role!
In general I was wondering how you would like to use the variables , if there are commented. I wondered too. I tried to keep it simple and maintain the logic. But in this path led me to the idea that it may be worthy to re-design a bit this variables' set, for the whole role.
Wouldn't it make sense to leave them in and rename the variables depending on which templates they are used. So all variables which go into the strict_authoritative templates are preseed with bind9_strictauthoritative ...
It's an interesting proposal, and could be for the variables which are specific to this set of templates. But for some variables it won't work, for example for bind9_authoritative
, which is needed true
for strict_authoritative templates, but not for the templates themselves, but for the logic of role.
However, for me, a better goal would be to consider this proposal:
... it led us to develop a sister role that may interestingly enhance it.
In fact, considering coding only, it also deserves to merge the two roles in a single one, with a refactor of the code and the design of a new version of the API of the role. But I think it isn't good to do that without discussing it with you and preparing it for the community of users of the role.
If you consider this can be a common path, I would be glad to propose the merge of the two role. If not, I'm always concerned about micro-communities an their yet-another-abandonware, but maybe I work it out even.
Sorry I started a new review, inestead of answering yours.
Hello, hereafter we propose you a PR we already talked you about. It consists essentially in a new set of templates for stronger, strict authoritative nameservers.
We explored the possibility to include the new features in the default template set (and we indeed included some enhancements for these templates, but it is secondary), finally it was more productive to develop a new set where we try to follow another design than the default ones.
The new set of templates is quite extensively documented, and in the readme we will also see that it led us to develop a sister role that may interestingly enhance it.
In fact, considering coding only, it also deserves to merge the two roles in a single one, with a refactor of the code and the design of a new version of the API of the role. But I think it isn't good to do that without discussing it with you and preparing it for the community of users of the role.
The quite barroque solution proposed: ansible code that writes locally ansible configuration should allow to explore the possibilities without loosing the present role and its simple evolutions.
Closes #38, as this PR is a proposal of its implementation.