Comment 4 for bug 1699132

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