[internal-dns] register and publish ddmd in the switch zone#10381
[internal-dns] register and publish ddmd in the switch zone#10381zeeshanlakhani wants to merge 1 commit intomainfrom
Conversation
DDMD has always run in the switch zone alongside Dendrite, MGS, and MGD, but it was never registered in internal DNS, leaving no path for a cross-host consumer to discover it. This adds `ServiceName::Ddm`, plumbs `ddm_port` through the host-zone switch (RSS plan + reconfigurator DNS execution), threads an `Overridables::ddm_ports` map for the test suite, and lands a `DdmInstance` dropshot sim in test utils so that the test harness registers a real DDM port in DNS the same way it does for the other switch-zone services. We also drop the duplicate DDMD_PORT const in `ddm-admin-client` in favor of the canonical `omicron_common::address::DDMD_PORT`. Same-host callers continue to use `Client::localhost()`. This was extracted from the multicast PR (zl/multicast-mgd-ddm), which uses ddmd cross-host as the first DNS-resolved consumer, as Nexus is the consumer.
jgallagher
left a comment
jgallagher
left a comment
There was a problem hiding this comment.
Thank you very much for splitting this out!
| dendrite_port: u16, | ||
| mgs_port: u16, | ||
| mgd_port: u16, | ||
| ddm_port: u16, |
There was a problem hiding this comment.
I think this function taking 3 u16s in a row was already sketchy - what do you think about changing this to take something like
struct HostSwitchZonePorts {
dendrite: u16,
mgs: u16,
mgd: u16,
ddm: u16,
}instead of four separate arguments? That way we get named parameters for the call sites, and don't have to rely on them getting the order correct, and inside this function, we can destructure them:
let HostSwitchZonePorts { dendrite, ...all the rest ... } = ports;so we also get a compile-time check that we update this function if we change the struct?
| /// In-process stand-in for the `ddmd` (Delay Driven Multipath daemon) | ||
| /// admin API. | ||
| /// | ||
| /// `ddmd` runs in sled global zones and switch zones in real deployments, |
There was a problem hiding this comment.
Will the ddmd that runs in the global zones ever need to be in DNS too, or is that one only communicated with locally?
| /// internal DNS as `ServiceName::Ddm`. | ||
| /// | ||
| /// This currently has no registered routes. Any integration needing | ||
| /// concrete endpoints (e.g., peer lists) must extend the `ApiDescription`. |
There was a problem hiding this comment.
This seems a little fishy - I think the other test-utils variants of these services is running something approximating the "real" service (albeit a stub binary for non-illumos systems - it still handles all the normal API endpoints). If this doesn't serve the same API, how can tests use it?
2 participants
DDMD has always run in the switch zone alongside Dendrite, MGS, and MGD, but it was never registered in internal DNS, leaving no path for a cross-host consumer to discover it. This adds
ServiceName::Ddm, plumbsddm_portthrough the host-zone switch (RSS plan + reconfigurator DNS execution), threads anOverridables::ddm_portsmap for the test suite, and lands aDdmInstancedropshot sim in test utils so that the test harness registers a real DDM port in DNS the same way it does for the other switch-zone services.We also drop the duplicate DDMD_PORT const in
ddm-admin-clientin favor of the canonicalomicron_common::address::DDMD_PORT. Same-host callers continue to useClient::localhost().This was extracted from the multicast PR (zl/multicast-mgd-ddm), which uses ddmd cross-host as the first DNS-resolved consumer, as Nexus is the consumer.