Merge lp://staging/~lamont/maas/bug-1599223 into lp://staging/~maas-committers/maas/trunk
Status: | Merged |
---|---|
Approved by: | LaMont Jones |
Approved revision: | no longer in the source branch. |
Merged at revision: | 5162 |
Proposed branch: | lp://staging/~lamont/maas/bug-1599223 |
Merge into: | lp://staging/~maas-committers/maas/trunk |
Diff against target: |
539 lines (+164/-112) 6 files modified
src/maasserver/dns/tests/test_zonegenerator.py (+11/-22) src/maasserver/dns/zonegenerator.py (+1/-35) src/maasserver/models/dnsresource.py (+6/-3) src/maasserver/models/staticipaddress.py (+61/-16) src/maasserver/models/tests/test_dnsresource.py (+2/-2) src/maasserver/models/tests/test_staticipaddress.py (+83/-34) |
To merge this branch: | bzr merge lp://staging/~lamont/maas/bug-1599223 |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Mike Pontillo (community) | Approve | ||
Review via email: mp+299491@code.staging.launchpad.net |
Commit message
Refactor get_hostname_
Description of the change
Cleanup how IP Addresses get into the DNS, and reduce the overall number of SQL queries for that process significantly. All IP addresses wind up in the DNS, with the FQDN being what we expect it to be historically, and $IFACE.$FQDN for the other IPs, so that there is only the one PTR RR for the FQDN. ($IFACE.$FQDN may have many PTR RRs in the RRset.)
In the old world, we created forward/reverse DNS for the FQDN, and also created PTR RRs naming $IFACE.$FQDN for each address on each interface on each node that resided in the subnet that we were generating a PTR zone for.
With this change, $IFACE.$FQDN is promoted to first-class citizen, and we create forward and reverse DNS for the names. Any name properly given to the FQDN is omitted from the $IFACE.$FQDN collection, since that would cause us to generate multiple PTR RRs for the primary IPs for the domain. The admin who needs multiple PTR RRs for specific situations can use dnsresource-records to cause that to happen.
Looks good to me. Was this tested end-to-end on nodes deployed with more than one interface? We need to make sure to do that before backporting to 2.0. Let me know if I can help.