Closed biggreenogre closed 9 years ago
I intend to deprecate dns_rr
. There is a replacement resource type called resource_record
. Can you use this instead?
That last commit appears to be unrelated to the "unique ID" work that was original to the pull request and I see now that the pull request has your master branch as its source. For future reference, this is just one reason why it's important to commit your changes to an issue branch rather than your master branch. The other major reason is that as the owner of the target repository, this pull request effectively grants me write access to your master branch.
I do not intend to merge any of the different pieces of work that are now a part of this pull request.
Regarding the "unique ID" for dns_rr
: I believe the replacement resource_record
resource type is an acceptable workaround to the title uniqueness problems present in dns_rr
.
Regarding the parameterization of SOA record values in db.empty: I hesitate to implement these since these values are only initial values, and there is already a mechanism (the source
parameter) for supplying the initial state of a zone which is well-documented as an initialization tool rather than an update tool. A user might reasonably expect the SOA parameters to update an existing zone if their values change, but this is not the case. For altering the SOA record of existing zones, I recommend attempting to manually update the zone using nsupdate.
Hi Nate,
I apologise for the confusing set of emails. My fault entirely and thank you very much for the module that, for me, is superior to any of the other Puppet Forge bind modules I have looked at.
The "unique ID" patch is something I have been using for a while, it was intended to be minimally intrusive to the existing code and adding it to the main codebase would have helped us to transition our systems to the newer resource_record type. Since the dns_rr type really is deprecated, I will just live with my local patch until we can catch up .
The second piece regarding the db.empty template was not intended to reach you. I'm afraid I'm new to using Github in more than a very basic way for my own code and very simple pull requests and got lost somewhere along the way. In fact. I thought I had specifically avoided confirming any of the pull request actions for that one.
Again, apologies for the inconvenience and thanks for the excellent bind module.
regards,
Drew
On 09/12/14, Nate Riffe notifications@github.com wrote:
I do not intend to merge any of the different pieces of work that are now a part of this pull request.
Regarding the "unique ID" for dns_rr: I believe the replacement resource_record resource type is an acceptable workaround to the title uniqueness problems present in dns_rr.
Regarding the parameterization of SOA record values in db.empty: I hesitate to implement these since these values are only initial values, and there is already a mechanism (the source parameter) for supplying the initial state of a zone which is well-documented as an initialization tool rather than an update tool. A user might reasonably expect the SOA parameters to update an existing zone if their values change, but this is not the case. For altering the SOA record of existing zones, I recommend attempting to manually update the zone using nsupdate.
— Reply to this email directly or view it on GitHub(https://github.com/inkblot/puppet-bind/pull/17#issuecomment-66371816).
Thanks for the high praise! If you're not using librarian-puppet I highly recommend it.
This patch allows a unique ID to be appended to to the dns_rr resource title to allow disambiguation of similar resources within puppet. It is backwards compatible and does not require the alteration of any existing resources. Note: It looks like this type has been deprecated but I have been using this patch for some time without issue and it would be helpful to have it included.