..

This work is licensed under a Creative Commons Attribution 3.0 Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode

=========================
 Designate Zone Pool Move
=========================

https://blueprints.launchpad.net/designate/+spec/zone-move

Zone move is an important feature that possibly eliminates the problem observed
with zone export-import.


Problem description
===================

Assume, zone is currently located in pool A, but has to move to pool B. (for example
pool B is another, new DNS provider).

Currently, Designate only allows you to create zone export (will be a Bind-format
single file with all the records of the zone) and zone import. So, a zone can be
exported from one pool; deleted from pool A; and imported into another pool B.

* The problem is that the zone has to be deleted in this process and imported.
* Large zone imports (20-30k records) can take a couple of hours as Designate
  creates all records one by one.

Therefore, it is problematic to move a zone between the pools/backends without any
hacks. At the point when the zone is deleted, but not imported, any DNS queries to
Designate-MDNS from the backend will not work.


Proposed change
===============

Introduce a new admin-only command in designate ``zone pool move``. The command works
as below:

**openstack zone pool move zone_id_or_name --pool_id=AN_ID_OF_POOL_B**

* The designate service should update zone pool_id property similar to other zone
  properties. The updated pool_id will be reflected in the designate DB. If the
  command is invoked without pool_id paramter, the designate reschedule the zone
  and move it to a different pool if appropriate. For example, user can move
  their zone up to a higher tier of service by updating an attribute and then
  calling move will cause attribute scheduler to select appropriate pool.
* After DB update, designate will create copy of zone (can also be called as clone)
  except it should not create new db entry for the clone zone. The clone zone will
  be created on target pool backend servers i.e. pool B.
* The zone transfer(AXFR/IXFR) will happen and the zone on pool B gets synced with
  the designate DB.
* At this point zone still exists in pool A. It can be removed after the administrator
  has changed the settings manually at domain registrar. This is a manual process.

The above proposed change eliminates the zone export as well as zone delete steps.
Thus, speed up the import of large zone to the target pool.


API Changes
-----------

The zone move will be triggered via the V2 API.

**Example zone pool move request:**

.. code-block:: http

        POST http://192.168.1.47/dns/v2/zones/52f42b9e-c48b-43e2-af01-180e8ed33cd0/tasks/pool_move HTTP/1.1
        Host: 127.0.0.1:9001
        Accept: application/json
        Content-Type: application/json

        {
          "pool_id": "794ccc2c-d751-44fe-b57f-8894c9f5c842"
        }


Central Changes
---------------

Central will update the pool_id of the zone for which move is requested. The updated
pool_id will be written to DB. Central will then clone the zone and then create new clone
zone in target pool backend servers.


Implementation
==============

Assignee(s)
-----------

Primary assignee:
  Kiran Pawar (kpdev in Gerrit)


Dependencies
============

None