NTP zone config could be more dynamic #4791
Assignees
Milestone
Comments
|
Not sure but maybe related: #3278. |
jgallagher
added a commit
that referenced
this issue
Aug 8, 2024
…ing told explicitly (#6050) This PR adds a special internal DNS name `boundary.ntp.control-plane.oxide.internal` which resolves to a set of AAAA records, one for each boundary NTP zone. We pass this name to chrony via a `pool` directive in its config file, allowing it to find the boundary NTP servers via internal DNS. This PR does not remove the explicit boundary NTP server names from either the sled-agent -> zone-setup or the zone-setup -> chrony config paths. Assuming this PR ships as part of R10, we can come back and remove those after R10 is out the door. We can't do both in one release, because we need to establish the new DNS name (via setting a new blueprint) in R10, at which point we can remove the explicit server names in R11, because NTP has to sync before we get the opportunity to modify DNS. Fixes #4791.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Internal NTP zones need to know about the boundary NTP zones. Today, the internal NTP zone config (that RSS constructs and passes into sled agent's
PUT /omicron-zones) includes a list of DNS names for the boundary NTP zones that RSS also provisioned. But this means that if we ever wanted to add or remove a boundary NTP zone (e.g., as part of replacing a sled that has a boundary NTP zone or to update the zone to a new image) then we'd need to also update the configs for every internal NTP zone and re-deploy them all.Could we instead provide an internal DNS name that expands to all the boundary NTP zones? Then on startup (and ideally periodically) the internal NTP zone would re-resolve that name and update itself to point to the right set of servers? That way the only thing that needs to be propagated is DNS, which happens anyway.
Aside: this problem also applies to boundary NTP zones (which reference external servers) but would only matter if/when we allow operators to change the upstream NTP servers. We could solve this the same way (publish an internal DNS name that refers to the same values as the upstream does, and keep it up to date) but that seems goofier for this case since we'd be publishing an internal name for an external IP and we'd also need to keep it up to date. An alternative would be to have the start method ask Nexus what should go there, but that's out because this functionality needs to work even when Nexus isn't up yet. So the zone either needs to cache the last-known value persistently (which is essentially what it does today) or else get it from internal DNS. Maybe we just keep boundary NTP zones the same accept that we would have to redeploy them if this value ever changed.
The text was updated successfully, but these errors were encountered: