Designate/Blueprints/Server Pools
Contents
Overview
Current State
Phase One
Gerrit Patch | [1] |
---|---|
Launchpad Blueprint | [2] |
Overview
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
- Currently there is only support for one pool
- This is currently a synchronous operation - async will be in a later phase
- 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.
- 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.
Next Steps
Phase Two
Gerrit Patch | N/A Currently |
---|---|
Launchpad Blueprint | [4] |
Overview
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:
- There will be a new table added for tracking of async operations.
- Zone serial numbers will move to a incrementing integer (from the current date/time stamp format)
- All responses from the API will move to a 202 - Accepted for modifying operations on zones.
- The response data for zone operations will include a status field, that will show PENDING.
- When the operation is complete, this will be changed to a ACTIVE status
Phase Two State Diagram
Notes
- This is 2 rpc calls, that no returns (oslo.messaging casts vs calls), meaning the central is not blocked on the pool-manager operation
- This is an example API call while the backend is still working on the change
- This is an example API call on the completion of the change
API v2 Changes
- Changing response code for async operations
Database Changes
This will document the example changes to the SQLAlchemy implementation
Additional Tables
- Pending Operations
- Resource ID - UUID
- Resource Type - UUID
- ChangeSetSerial - Integer (this name may need to be examined)
Phase Three
Gerrit Patch | N/A Currently |
---|---|
Launchpad Blueprint | [5] |
Overview
This will need fleshing out, but will be the creation of a pools scheduler to allow for multiple pools, and per tenant pools
Discussion
Any ideas for phase three ( Schedulers ) please put them here, and tag your user name, so we know who to ask
- Decide how much pools are exposed in the API (artom)
- Use case example: private and public pools. Completely transparent, per-tenant pools work in this case (public and private tenant).
- Use case example: single tenant wants multiple pools. No choice but to expose pools in the API so he can control what zones go to what pool.
- Can we support both of the above simultaneously?
- Look at nova's to see if there is reusable code (graham)