designate should create servers when related to designate-bind or other dns-backend

Bug #1770192 reported by Drew Freiberger on 2018-05-09
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Wishlist
Unassigned

Bug Description

When setting up a new designate service with designate-bind dns-backend, the designate-bind servers are not registered with the designate API.

It appears that one must manually run "designate server-create <designate-bind-FQDN>." even though designate charm has create_server functions available, they're not part of the relation. The charm documentation mentions that nameservers setting is required for queens, but it appears that it may be required for prior releases until dns-backend relation handles this.

Is this perhaps a bug given that my environment does not have pre-existing PTR and A records for my designate-bind servers?

For reference, using MAAS provider, designate and designate-bind are both deployed in lxds without static addressing. The designate and designate-bind units are able to find juju-XXXX-Y-lxd-Z.maas. DNS records, but pools.yaml shows IP addresses for nameservers.

If the IPs provide PTR records, the dns-backend relation should auto-populate servers in the API, even if they're not externally accessible at those particular NS records.

Pete Vander Giessen (petevg) wrote :

This sounds like more of a feature request than a bug. Marked it as wishlist for now, but feel free to push back if you think that the behavior as written is truly unexpected.

Changed in charm-designate:
importance: Undecided → Wishlist
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers