Repository navigation
Label and describe Private DNS resolver contexts by their network - #851
Merged
Merged
Conversation
The DNSResolverContext for a network now carries the network name and UID labels, and existing contexts get them on the next pass. DNS copies these labels to the context's managed zone, so the zone names its VPC.
This was referenced Nov 3, 2026
Merged
Set the managed-object-labels annotation so DNS copies the network labels to the managed zone, and log a failed label write instead of holding up DNS access.
Set kubernetes.io/description to "Private DNS for the <network> VPC", using the network's display name when it has one. DNS copies it to the managed zone, which the portal shows as the zone description.
scotwells
changed the title
scotwells
marked this pull request as ready for review
November 3, 2026 17:57
ecv
approved these changes
Nov 3, 2026
ecv
left a comment
ecv
left a comment
Contributor
There was a problem hiding this comment.
Approve.
New and existing resolver contexts get the network labels, the copy-labels annotation and the description; a failed label write is logged and never blocks DNS access. Keys match dns-operator#456 (dns.networking.miloapis.com/managed-object-labels, kubernetes.io/description).
- The annotation and label keys line up with dns-operator#456, and the order is safe either way: until dns-operator ships, the annotations are inert.
- The portal (cloud-portal#1788) reads
spec.visibility, not these labels or the description, so nothing here changes what the portal shows. Zones made before the change already show "Private" in the portal, since dns-operator already setVisibility: Privateon managed zones. internalDNSNetworkLabelsskips the name label when it is not a valid label value and keeps the UID label, covered by the long-name test.
Follow-ups:
- The patch error on an existing context is logged on every reconcile pass while it fails; consider rate-limiting or surfacing it as a condition.
- Nothing yet consumes the network label or description in the portal; the stack's description and labels have no reader until a follow-up lands.
kevwilliams
approved these changes
Nov 3, 2026
kevwilliams
left a comment
kevwilliams
left a comment
Contributor
There was a problem hiding this comment.
Verified a failed label write on an existing context is logged and never blocks DNS access, and the long-name and pre-existing-context paths are both tested.
scotwells
added a commit
to datum-cloud/cloud-portal
that referenced
this pull request
Nov 3, 2026
<!-- claude-projects-attribution: {"github_login":"scotwells"} -->
_Requested by **Scot Schuchert-Wells**_
## Description
Private DNS zones (`spec.visibility: Private`, such as each VPC's
`datum.internal` zone) never get public nameservers, so the DNS list
showed "Looking up..." for them forever.
- The DNS Host column shows "Private" for private zones instead of the
spinner.
- The zone page hides the Nameservers tab for private zones.
Which VPC a zone serves shows up in the existing Description column: the
operator changes linked below set the zone's `kubernetes.io/description`
to "Private DNS for the ‹network› VPC".
Related: datum-cloud/enhancements#921
Companion PRs: datum-cloud/network-services-operator#851,
datum-cloud/dns-operator#456, #1788
This was referenced Nov 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Requested by Scot Schuchert-Wells
What
The
DNSResolverContextcreated for a network now carries:networking.datumapis.com/network(name, skipped when too long for a label value) andnetworking.datumapis.com/network-uid;kubernetes.io/description: Private DNS for the <network> VPC, using the network's display name when it has one;dns.networking.miloapis.com/managed-object-labels, asking DNS to copy the two network labels to the managed zone.Existing contexts are updated on the next reconcile, and the description follows display name changes. Writes are best effort: a failure is logged and never holds up DNS access.
Why
DNS copies these to the managed
datum.internalzone, so the portal's Description column says which VPC each zone is for, and the zone's labels name the network.Related: datum-cloud/enhancements#921
Companion PRs: #851, datum-cloud/dns-operator#456, datum-cloud/cloud-portal#1788