tracking issue for server side of service discovery

[davepacheco]

• RFD on connection management
• RFD on plan for DNS servers for control plane service discovery (RFD 248, nearing completion)

The rest of this is contingent on any changes from the above RFDs.

• The DNS server
  • Standalone dropshot-programmable DNS server with local sqlite database (@rcgoodfellow) [internal-dns] First pass at integrating service discovery codebase #800
  • Zone-based deployment of standalone DNS server (@smklein) ([internal-dns] Shove service discovery into a zone #807)
  • RSS deployment of standalone DNS server, plus initial configuration (@smklein) ([internal-dns][sled agent] Assign IPs to DNS service from reserved subnet #965)
• Nexus needs to track information about deployed components of the control plane
  • Sled agent instances (already exists)
  • CockroachDB instances
  • Nexus instances
  • Dendrite instances
  • Oximeter instances (this exists, but the API is "notifying Nexus", rather than "Nexus-controlled")
  • Clickhouse instances
• Nexus needs a mechanism to update the DNS servers when any of the above deployment information changes
  • explicitly remove some instance by policy (e.g., to remove from service)
  • synchronize everything (i.e., generate a new complete view of the DNS zone and push it to the servers)
  • (optional) explicitly add some instance (e.g., as part of provision)

[davepacheco]

Closing because I think the pieces here are either done or covered by other issues.

• the key pieces of the DNS server are done
• we do track instances of control plane components in the "service" table today
• currently it is not possible for the deployment information changes, but when it becomes possible, there are pieces in place to propagate the changes to DNS (i.e., the "dns_config" background task)