Designate/Blueprints/Server Pools/High Level Overview
Why / What / How of Server Pools
Server Pools are required for a few different scenarios:
This allows users to have 'private' DNS servers. These servers would typically allow non standard TLDs (.dev , .local etc), and may not have the same level of blacklist restrictions. They would be aimed at people with Neutron Networking, and VPC style set ups, where access to the DNS server would come from trusted networks (eg, in-cloud - owned instances, and VPN'd onsite resources)
This would allow customers to set DNS entries for internal servers, on domains that would not be available on the public pools, and have them accessible by internal users
Having multiple public pools with the same capabilities, would allow the scheduler to distribute zones across multiple infrastructures.
Features / Premium Systems
By using scheduler hints, we can mark different pools as having different capabilites - such as GeoIP / Round Robin DNS / Anycast.
This allows operators to run different DNS infrastructures as required. For example this allow users to have some zones on pools with GeoIP, and pay a premium for this feature, while having the rest of their zones on a cheaper 'standard' tier.
Pools will be broken down into 'types'. This will be an extensible list - by using plugins to define types.
This would be similar to what we have today - a public pool that is maintained by adding servers, and then informing designate of the server name.
These would be dynamically created pools, generally used for private pools, that would have the server name / IP defined by nova / neutron.
We would need to extend the information in the server pools API to allow setting information like what neutron network / subnet to connect to, and any extra info required.