409 Duplicate zone returned when recreating previously deleted zone.

[Robert Putt]

Following creation of a zone in designate if the zone is deleted and at a later date recreated a 409 error is returned stating "Duplicate zone"...

For example...

curl -X POST -H "X-Auth-Token: a0a0a46efcfb4c6e8aa36a0fe74abde1" -H "Content-Type: application/json" -H "Cache-Control: no-cache"-d '{
> "name": "testdomain.local.",
> "ttl": 3600,
> "email": "<email address hidden>"
> }' "http://91.134.109.130:9001/v1/domains"

{
  "created_at": "2017-02-13T23:33:35.000000",
  "description": null,
  "email": "<email address hidden>",
  "id": "b6aa8ead-20d3-4558-8fed-d3759f7e1d25",
  "name": "testdomain.local.",
  "serial": 1487028815,
  "ttl": 3600,
  "updated_at": null
}

curl -X DELETE -H "X-Auth-Token: a0a0a46efcfb4c6e8aa36a0fe74abde1" -H "Content-Type: applicaton/json" -H "Cache-Control: no-cache" -d '{
> "name": "testdomain.local.",
> "ttl": 3600,
> "email": "<email address hidden>"
> }' "http://91.134.109.130:9001/v1/domains/b6aa8ead-20d3-4558-8fed-d3759f7e1d25"

curl -X GET -H "X-Auth-Token: a0a0a46efcfb4c6e8aa36a0fe74abde1" -H "Content-Type: application/json" -H "Cache-Control: no-cache" "http://91.134.109.130:9001/v1/domains"
{
  "domains": []
}

curl -X POST -H "X-Auth-Token: a0a0a46efcfb4c6e8aa36a0fe74abde1" -H "Content-Type: applicatio/json" -H "Cache-Control: no-cache" -d '{
> "name": "testdomain.local.",
> "ttl": 3600,
> "email": "<email address hidden>"
> }' "http://91.134.109.130:9001/v1/domains"

{"message": "Duplicate Zone", "code": 409, "type": "duplicate_domain", "request_id": "req-e916ea37-b473-4415-88ac-7d025f73753c"}

As you can see, if I create a domain, delete the domain and then try and recreate it refuses as the domain already exists. Here is the version of designate I have been running this against...

dpkg -l | grep designate
ii designate 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - metapackage
ii designate-agent 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - agent
ii designate-api 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - API server
ii designate-central 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - central daemon
ii designate-common 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - common files
ii designate-mdns 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - mdns
ii designate-pool-manager 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - pool manager
ii designate-sink 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - sink
ii designate-zone-manager 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - zone manager
ii python-designate 1:2.0.0-3~bpo8+1 all OpenStack DNS as a Service - Python libs
ii python-designateclient 2.1.0-2~bpo8+1 all client library for the OpenStack Designate API - Python 2.7

Hopefully I can take a look at getting this patched, although I am largely unfamiliar with the Designate code base, it's not a project I tend to get involved with too often.

Best Regards,

Rob

[Robert Putt (robert-putt)]

Interestingly I see an ugly error in the pool-manager...

2017-02-13 23:45:41.412 21180 ERROR designate.pool_manager.service [req-4f960f7f-cdc7-480c-8606-d0edf88c4619 - - - - -] No targets for <Pool id:'794ccc2c-d751-44fe-b57f-8894c9f5c842' name:'default'> found.

Sure enough in the DB there are no targets for this pool in the targets table even though there were included in the config at the time of initialising the db as seen below.

#####################
## Pool Configuration
#####################

# This section does not have the defaults filled in but demonstrates an
# example pool / server set up. Different backends will have different options.

[pool:794ccc2c-d751-44fe-b57f-8894c9f5c842]
nameservers = 0f66b842-96c2-4189-93fc-1dc95a08b012
targets = f26e0b32-736f-4f0a-831b-039a415c481e
#also_notifies = 192.0.2.1:53, 192.0.2.2:53

[pool_nameserver:0f66b842-96c2-4189-93fc-1dc95a08b012]
port = 53
host = 127.0.0.1

[pool_target:f26e0b32-736f-4f0a-831b-039a415c481e]
options = port:53, host:127.0.0.1
masters = 127.0.0.1:5354
type = bind9

I see some similar comments in http://lists.openstack.org/pipermail/openstack-operators/2016-August/011150.html so I had a go at performing the following... https://github.com/openstack/designate/blob/master/doc/source/upgrade/mitaka.rst but I think there is something more fundamental with my installation which is faulty.

Either way I installed via the most up to date docs I could find here... http://docs.openstack.org/developer/designate/install/ubuntu-liberty.html so I am fairly confident maybe others are having an issue with this.

[Tim Simmons (timsim)]

Could you execute an `openstack zone list` via the client, or if you're using the API GET /v2/zones and paste the results (I'm betting your zone is actually PENDING, but not sure that will reflect in the old API).

[Robert Putt (robert-putt)]

Hey Tim,

Yep your right my zone is in PENDING state. Not sure how it got here but I am guessing it was an issue during zone creation as the zone doesn't exist in BIND. I guess maybe this isn't an issue after all rather my crappy deploy :-).

Best Regards,

Rob

[Launchpad Janitor (janitor)]

[Expired for Designate because there has been no activity for 60 days.]