fix(mgmt-agent): watch acn.azure.com CRDs and Nodes (MTPNC, NNC)

[Andrew Denton (ventifus)]

What

Expands watchedGroupSuffixes from multitenancy.acn.azure.com to the entire acn.azure.com group, to pick up MultiTenantPodNetworkConfig and NodeNetworkConfig. Also adds core/v1/nodes to the hardcoded resources watched alongside core/v1/namespaces.

Why

The SWIFT networking TSG (ARO-25382) needs MTPNC, NNC, and Node state for triage, but none of it was being snapshotted into kubernetesResourceSnapshots.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ventifus
Once this PR has been reviewed and has the lgtm label, please assign janboll for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi Andrew Denton (@ventifus). Thanks for your PR.

I'm waiting for a Azure member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[Copilot]

Pull request overview

This PR updates the mgmt-agent resource watcher’s API group suffix filter to include the broader acn.azure.com domain, so additional ACN networking CRDs (notably MTPNC and NNC) will be discovered and snapshotted while preserving coverage of existing multitenancy.acn.azure.com resources via suffix matching.

Changes:

• Replace multitenancy.acn.azure.com with acn.azure.com in the watcher’s watchedGroupSuffixes.
• Update the matchesGroupSuffix unit test to reflect the new suffix list entry.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
mgmt-agent/pkg/controller/resourcewatcher.go	Broadens the watched API group suffix from multitenancy.acn.azure.com to acn.azure.com so both the apex group and its subdomains are included.
mgmt-agent/pkg/controller/resourcewatcher_test.go	Adjusts TestMatchesGroupSuffix to validate matching for acn.azure.com.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Andrew Denton (ventifus)]

Good catch, restored - multitenancy.acn.azure.com is back in as a subdomain-match test case for acn.azure.com.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Suppressed comments (1)

mgmt-agent/pkg/controller/resourcewatcher_test.go:40

• TestMatchesGroupSuffix no longer exercises the important subdomain case for the new suffix (e.g. multitenancy.acn.azure.com should still match acn.azure.com). Without this, a regression in the strings.HasSuffix(group, "."+suffix) logic for acn.azure.com wouldn’t be caught.

		{"multicluster.openshift.io", true},
		{"acn.azure.com", true},
		{"multitenancy.acn.azure.com", true},

[Brendan Bergen (SudoBrendan)]

I think this is based on old kube (?). It was true at some point in the past that node status was incredibly noisy, but they fixed it AFAICT - https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/589-efficient-node-heartbeats

IMO - if a Node status changes (regardless of frequency), SRE will really care about that, especially since it's expected that Node outages or remediations will be our primary course of action. This data is likely the most valuable thing for us to ship to logs - highlighting issues with capacity and connectivity.

In any case, I'm convinced Nodes will generate way less traffic than Events or Pods, which we already track.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.