Designate/Blueprints/Server Pools

Current State

Phase One

Gerrit Patch	[1]
Launchpad Blueprint	[2]

This is an initial change to the codebase to introduce the concept of a "server pool"

This has introduced a new service that sits where the agent would have traditionally sat for bind9

This has caused all servers and domains to assigned to a "pool", which we will use in the future to submit changes to the right pools.

Phase One State Diagram:

API v2 Changes

Servers are now a full sub resource of pools, and are accessed using HTTP requests like:

 GET http://designate-server:9001/v2/pools/pool_id/servers - get all servers in <pool_id>
 GET http://designate-server:9001/v2/pools/pool_id/servers/server_id - get <server_id> details
 

This was to avoid massive amounts of changes to SOA records for domains, and allowing us to notify backends [3] of just the server that changed.

Phase One limitations

1. Currently there is only support for one pool
2. This is currently a synchronous operation - async will be in a later phase
3. When designate is set up / upgraded for the first time, you will need set up a default pool in the /etc/designate/designate.cfg file.
   1. There is a default pool created in the SQLAlchemy migrations, so this will just copying and pasting the pool_id into the right section in the config file.

Future Work

Phase Two

Gerrit Patch	N/A Currently
Launchpad Blueprint	[4]

As part of phase two, we will introduce the concept of Async operations on backends, using the pool-manager interfaces.

There will be a couple of changes to the core of designate:

1. There will be a new table added for tracking of async operations.
2. Zone serial numbers will move to a incrementing integer (from the current date/time stamp format)
3. All responses from the API will move to a 202 - Accepted for modifying operations on zones.
   1. The response data for zone operations will include a status field, that will show PENDING.
   2. When the operation is complete, this will be changed to a ACTIVE status

Phase Two State Diagram:

Notes

1. This is 2 rpc calls, that no returns (oslo.messaging casts vs calls), meaning the central is not blocked on the pool-manager operation
2. This is an example API call while the backend is still working on the change
3. This is an example API call on the completion of the change

API v2 Changes

1. Changing response code for async operations

Database Changes

This will document the example changes to the SQLAlchemy implementation

Additional Tables

1. Pending Operations
   1. Resource ID - UUID
   2. Resource Type - UUID
   3. ChangeSetSerial - Integer (this name may need to be examined)