Merge lp:~jtv/maas/independence-for-dnsconfig into lp:~maas-committers/maas/trunk
Status: | Merged |
---|---|
Approved by: | Jeroen T. Vermeulen |
Approved revision: | no longer in the source branch. |
Merged at revision: | 1836 |
Proposed branch: | lp:~jtv/maas/independence-for-dnsconfig |
Merge into: | lp:~maas-committers/maas/trunk |
Diff against target: |
204 lines (+38/-61) 3 files modified
src/maasserver/management/commands/get_named_conf.py (+2/-2) src/provisioningserver/dns/config.py (+26/-35) src/provisioningserver/dns/tests/test_config.py (+10/-24) |
To merge this branch: | bzr merge lp:~jtv/maas/independence-for-dnsconfig |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Raphaël Badin (community) | Approve | ||
Review via email: mp+202459@code.launchpad.net |
Commit message
Take DNSConfig out of the DNSConfigBase class hierarchy.
Description of the change
This will allow me to simplify the data paths within the remaining hierarchy later. It also makes it easier to tailor the write_config implementations for DNS config files and zone files. For example, it doesn't seem as if the one for zone files actually uses its kwargs. I also isolated get_include_snippet a bit more by making it a class method. Tightening up the data flows creates elbow room for the changes that these branches ultimately support: multiple managed interfaces per cluster.
After this, I can start consolidating the remaining DNSConfigBase hierarchy: DNSConfigBase ← DNSZoneConfig ← {DNSForwardZone
You may notice how DNSConfig comes out as more of a function than a class. Actual use in the MAAS codebase instantiates the class, immediately calls the object's write_config method, and then forgets about the object. I kept the class because these classes were always intended mostly as a kind of sub-module. It's a friendly way of grouping together the writing of the DNS config and generation of the matching DNS include snippet.
Jeroen
I must say this is starting to come together pretty nicely!