retire "services" table

[davepacheco]

The services table stores information about Omicron zones deployed by RSS. I think the intent was so that Nexus would know what was supposed to exist so that over time it could reconfigure the set of zones deployed. Unfortunately, we discovered this table doesn't have enough information to fully specify these zones so it cannot be used (by itself) to describe either what zones do exist nor what zones should exist. But fortunately we've already addressed this problem:

• A fuller specification of each Omicron zone is fetched from each sled agent as part of the inventory process. This allows Nexus to know what zones are actually out there (as of some particular collection).
• Blueprints include this same representation of Omicron zones. This allows Nexus to know what zones are supposed to be out there.
• We use this representation in sled agent's PUT /omicron-zones API so we know it's sufficient to fully specify these zones.
• I think we've built enough of a blueprint planner to have some confidence that the overall representation works to evolve the set of deployed zones.

Given that, I think we can just drop the services table altogether. There is only one thing that uses it as far as I know, and that's DNS propagation. After #4889, we should be free to drop this table altogether.

CC @smklein does this sound reasonable?

[smklein]

Makes sense to me, I think the combination of inventory ("what exists") and blueprints ("what we want to exist") makes sense, and the services table is redundant with both of those.

[jgallagher]

Summarizing discussion from yesterday's update sync: there are (at least) two other clients of the service table:

1. omdb db network list-eips uses it to map from an external IP to the kind of service (nexus vs ntp)
2. DataStore::vpc_resolve_to_sleds() uses it to determine which sleds are running services that are using a service VPC (currently only SERVICE_VPC_ID, but we could imagine more fine-grained VPCs in the future)

#5202 changes both of those to also check the current target blueprint, but doesn't remove their use of service. To do so, I think we would need to first guarantee that every system has a current target blueprint. This should be straightforward for deployed systems, as we could set it to a disabled blueprint based on the latest collection, but would require work to ensure it will be true for new systems going through RSS.

Separately, there's a question of whether these clients ought to be looking at the latest inventory instead of (or in addition to?) the current target blueprint. Both inventory and blueprints are potentially misleading, but in different ways (inventory collections are lossy, blueprints are aspirational).

[davepacheco]

I think I found another use here:

omicron/nexus/db-queries/src/db/datastore/rack.rs

Line 793 in 6a0d1af

pub async fn nexus_external_addresses(

This is used during Silo creation to find the Nexus external IPs so that we can assemble the right DNS records for the new Silo. After #5068, Reconfigurator will be capable of doing this correctly, but it can't be used here until/unless we fully automate planning+execution.

[jgallagher]

I took a stab at smoking out any other service table consumers (by removing it from schema.rs and following the trail of broken compilation). The only consumers beyond what we've already described in this issue are two omdb commands:

• omdb db services list-instances
• omdb db services list-by-sled

I suspect we can drop both of these, since you can get the same information by printing the current target blueprint? Maybe we want some variant(s) of blueprint printing that shows a subset of info or a different means of organization, but that is obviously not a blocker.