config option nameservers not clearing up old configuration data

Bug #1699132 reported by Gábor Mészáros on 2017-06-20
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Designate Charm
Medium
Unassigned

Bug Description

setting nameservers to some setting, it only creates the new zones. After changing the nameservers options to some new value, the charm does not remove the old options.
The expected behaviour would be to remove the old configuration from designate DB.

lib/charm/openstack/designate.py#640
            with cls.check_zone_ids(nova_domain_name, neutron_domain_name):
                if hookenv.config('nameservers'):
                    for ns in hookenv.config('nameservers').split():
                        cls.create_server(ns)

$ juju config designate nameservers
ns1.testdomain.eu. ns2.testdomain.eu. ns3.testdomain.eu.

$ designate server-list
+--------------------------------------+--------------------+
| id | name |
+--------------------------------------+--------------------+
| 4436be7e-c3e9-4575-9dc8-54dd3ef10813 | ns1.demodomain.eu. |
| 5fd94f58-76d3-44dd-a370-68535fe6af9e | ns2.demodomain.eu. |
| d1328565-429f-4762-bf89-1638abe54597 | ns1.testdomain.eu. |
| 357570af-fd41-4eeb-91e3-9b08f3273098 | ns2.testdomain.eu. |
| 249f1045-8bba-4119-87b9-f4c1ee87bea6 | ns3.testdomain.eu. |
+--------------------------------------+--------------------+

Changed in charm-designate:
importance: Undecided → Medium
status: New → Triaged
Edward Hope-Morley (hopem) wrote :

Hi @gabor can you specifc which release of openstack you hit this issue with? I ask because I think there are two issues in the charm, first is the one you hit i.e. old records not removed but with Rocky these don't get updated at all since the charm is hardcoded to use python-designateclient which is deprecated and hardwired to use the deprecated v1 api. Solution is to switch to python-openstackclient (or just use the api direct) and also use designate-maname [1]. I'll raise a seperate bug for the second issue.

[1] https://docs.openstack.org/designate/rocky/admin/pools.html

hello Ed, I'm running this on top of Ocata. I'll take a look at the openstackclient, thanks for the idea.

Michał Ajduk (majduk) wrote :

This issue seems to be related to Designate bug [1]

[1] https://bugs.launchpad.net/designate/+bug/1758013

Tytus Kurek (tkurek) wrote :

I believe this is invalid.

"designate" command calls v1 API which is no longer used by the designate charm [1]. Instead the NS records are managed through the "pools.yaml" file which is working fine with Queens + Charms 18.11. I have just run the following tests:

$ juju config designate nameservers
ns1.example.com. ns2.example.com.

$ openstack zone create --email <email address hidden> example.com.

$ dig -t NS example.com @designate-bind.example.com
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.

$ juju config designate nameservers="ns1.example.com. ns2.example.com. ns3.example.com."

$ dig -t NS example.com @designate-bind.example.com
example.com. 3600 IN NS ns1.example.com.
example.com. 3600 IN NS ns2.example.com.
example.com. 3600 IN NS ns3.example.com.

$ juju config designate nameservers="ns2.example.com. ns3.example.com."

$ dig -t NS example.com @designate-bind.example.com
example.com. 3600 IN NS ns2.example.com.
example.com. 3600 IN NS ns3.example.com.

So the NS records are added / removed properly from the hosted zones.

[1] https://bugs.launchpad.net/charm-designate/+bug/1804022

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers