CloudStack DNS framework - Integrate PowerDNS as first plugin#12737
CloudStack DNS framework - Integrate PowerDNS as first plugin#12737sudo87 wants to merge 72 commits into
Conversation
2. added relevant changes in dao and vo 3. worked on creatednszone, integration with mgr 4. powerdns create zone api call
1. creatednszone 2. listdnszone 3. updatednszone 4. deletednszone
1. Add dns server 2. create zone 3. add records 4. verify in powerdns 5. verify using dig
1. Registerdnsrecordforvm api 2. removednsrecordforvm api 3. cleanup; fixed license, dao logic
1. refactored client 2. added exceptions 3. enhanced updateZone 4. ownership check for deleteDnsServer
…n svc and handle dot version in client
…elete events 2. add dnsrecordurl in nic_details table 3. add dnsrecordurl in vm response
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #12737 +/- ##
============================================
+ Coverage 20.14% 20.40% +0.26%
- Complexity 18477 18837 +360
============================================
Files 5751 5798 +47
Lines 519415 522015 +2600
Branches 60625 60894 +269
============================================
+ Hits 104648 106536 +1888
- Misses 403334 403934 +600
- Partials 11433 11545 +112
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@weizhouapache a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18349 |
|
@blueorangutan test |
|
@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian Build Failed (tid-16419) |
|
@vladimirpetrov could you please share the test results ? thanks @rajujith is it good to you ? |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
|
@blueorangutan package |
|
@sudo87 a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 18425 |
|
@blueorangutan test |
|
@sudo87 a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
|
[SF] Trillian test result (tid-16456)
|
|
@weizhouapache @sudo87 , this came probably a bit early to be an extension type. Would it make sense to still invest in it, or to create a second phase where it can be implemented as extension? |
|
This pull request has merge conflicts. Dear author, please fix the conflicts and sync your branch with the base branch. |
Thanks for the suggestion. In my opinion, an external orchestration model for DNS is certainly feasible (e.g., via a generic DnsExtensionProvider that executes Python/shell scripts or other external tooling implementing the same DnsProvider contract). However, DNS operations are comparatively simpler than VM, network, or storage orchestration. They are mostly CRUD-style operations (zones and records) without complex state machines or deep lifecycle management. Because of that, implementing DNS providers directly in Java as part of CloudStack is not particularly complex. At the same time, a Java-based provider model is more consistent with existing CloudStack extension patterns and avoids introducing an additional execution layer (script-based dispatch), which can add operational overhead and reduce type safety and debuggability compared to native implementations. So my view is that a Java DNS provider framework is the more natural fit for CloudStack, while an external execution-based provider model remains feasible for environments that specifically require script-based integration. |
Description
This PR introduces initial implementation for a plugin based DNS framework in Apache CloudStack. It enables both admin and end-users to manage DNS zones and record with external authoritative dns providers.
First supported DNS provider: PowerDNS
Github issue: #9958
Cwiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/DNS+Framework+and+Plugins
Doc PR: apache/cloudstack-documentation#646
Terminology:
API Changes
There are following APIs have been introduced to support DNS management from CloudStack and Instance auto registration:
UI changes




Supported network for Auto Registration: Shared network
Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
How did you try to break this feature and the system with this change?