Goal:

Enable operators to deploy and manage multiple Designate DNS pools, where each pool has independent BIND replica counts, NS records, and attributes. For now, all of the pools will share the same primary servers.

This allows operators to create pool-based DNS service which can be scaled and segmented by pool specific attributes. Users will be able to define pools via a ConfigMap, dynamically add/remove pools, scale pools independently, and migrate between single-pool and multipool configurations.

Acceptance Criteria:

• Multipool Configuration
      - Operators can define multiple DNS pools using a designate-multipool-config ConfigMap
      - Each pool supports custom name, description, attributes (e.g., availability_zone, region), bindReplicas count, and NS records
      - A "default" pool must always exist in multipool configurations
      - Pool names must be unique across the configuration
• StatefulSet Management
      - System creates one StatefulSet per pool (e.g., designate-backendbind9-pool0, designate-backendbind9-pool1)
      - Each StatefulSet is labeled with pool name and index for identification
      - Single-pool mode (without multipool ConfigMap) continues to work using original StatefulSet naming
• Validation and Safety
      - Admission webhook validates multipool ConfigMap structure before applying ConfigMap changes
      - Validation ensures: default pool exists, unique pool names, bindReplicas >= 0
      - Pool removal is prevented if active DNS zones exist in that pool
      - Configuration errors are surfaced to operators via status conditions
• Dynamic Pool Operations
      - Operators can add new pools by updating the multipool ConfigMap
      - Operators can remove pools (after associated DNS zones are deleted) by removing them from ConfigMap
      - Orphaned StatefulSets (of removed pools) are gracefully scaled down and deleted
      - Operators can scale individual pools up or down by changing bindReplicas
• Migration Support
      - Existing single-pool deployments can migrate to multipool by creating the ConfigMap
      - Multipool deployments can revert to single-pool by deleting the ConfigMap
      - Migration handles StatefulSet creation/deletion gracefully
      - No manual intervention required during migration. With that being said, operators should set up / take care of required resources, e.g. storage
• pools.yaml Generation
      - System generates Designate pools.yaml containing all configured pools
      - RNDC keys are indexed sequentially across all pools
      - Pools.yaml updates automatically when multipool configuration changes
      - Backward compatible with single-pool pools.yaml format
• Testing Coverage
      - Automated tests verify: basic multipool deployment, adding pools, removing pools, scaling pools, single-to-multipool migration, multipool-to-single migration
      - All tests pass in CI/CD pipeline