[scotwells]

Requested by Scot Schuchert-Wells

What

A resolver context's managed zone and zone association now carry:

• dns.networking.miloapis.com/managed: "true" (as before) and the Kubernetes well-known app.kubernetes.io/managed-by: dns.networking.miloapis.com;
• the context labels the context names, comma separated, in its dns.networking.miloapis.com/managed-object-labels annotation;
• the context's kubernetes.io/description.

Existing zones and associations are updated on the next pass. Copied labels and the description are added or corrected, never removed. A failed write is logged and never stops the pass, and the association is left alone while its zone is being deleted.

Only listed labels are copied, so labels that track the context itself (for example GitOps instance labels) never select the managed objects.

Why

Whoever creates a resolver context can then say what its zone is for, and clients can show or select zones by it without following owner references.

Related: datum-cloud/enhancements#921

Companion PRs: datum-cloud/network-services-operator#851, #456, datum-cloud/cloud-portal#1788

[ecv]

Request changes.

The failing Run on Ubuntu check is the linter, and this PR causes it: task lint runs with --new-from-merge-base=origin/main, so it flags only this PR's lines, and main's CI at a3b3a88 is green. Both failing runs (126095605585, 126095650212) show the same two errors and no test failure, so TestTrustedPROXYDestinationSurvivesTCP is not involved.

• internal/internaldns/controlplane/context_reconciler.go:804: goconst, the string "true" now has 3 occurrences. Make it a constant.
• internal/internaldns/controlplane/context_reconciler.go:830: revive import-shadowing, the local labels shadows an imported package name. Rename it.
• Behavior reads correctly otherwise: only labels the context lists are copied, managed and managed-by are always forced, labels and the description are added or corrected and never removed, and writes on a deleting zone are skipped.

Follow-ups:

• app.kubernetes.io/managed-by is now stamped on every existing managed zone and association; confirm nothing selects on that label before it ships.
• A failed metadata write is only logged, so a persistent webhook rejection on the zone would go unnoticed; consider an event.

[ecv]

Approve.

a8a2541 fixes both lint findings that held this: "true" becomes managedObjectValue, and the local labels that shadowed the import is renamed objLabels at every use. Behaviour is unchanged, and CI is green at the head.

Follow-ups:

• The earlier ones stand: confirm nothing selects on app.kubernetes.io/managed-by before every existing managed zone gets stamped with it, and surface a persistently failing metadata patch as an event rather than a log line.

[kevwilliams]

Checked the annotation and description keys match network-services-operator#851, managed and managed-by can't be overridden by listed labels, and pre-existing zones are patched.