Policy name migrator looks up a DaemonSet named `calico-node`, which does not exist in `manifests/canal.yaml`

Expected Behavior

The policy name migration controller added in v3.32 should work on a cluster installed from manifests/canal.yaml.

Current Behavior

It logs this every five seconds, indefinitely:

[ERROR][14] kube-controllers/policy_name_migrator.go 301: Error getting calico-node DaemonSet: daemonsets.apps "calico-node" not found

manifests/canal.yaml names its DaemonSet canal:

$ kubectl -n kube-system get ds
NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
canal        1         1         1       1            1           104s
kube-proxy   1         1         1       1            1           6m40s

The name is a string literal in waitForCalicoNodeRollout() (kube-controllers/pkg/controllers/networkpolicy/policy_name_migrator.go:299 at v3.32.0):

ds, err := c.cs.AppsV1().DaemonSets(c.namespace).Get(c.ctx, "calico-node", metav1.GetOptions{})
if err != nil {
    logrus.Errorf("Error getting calico-node DaemonSet: %v", err)
    continue
}

run() calls waitForCalicoNodeRollout() before its main loop, so the migration never starts. Same code on release-v3.32 and master.

Possible Solution

Read the DaemonSet name from an environment variable defaulting to calico-node, and set it to canal in manifests/canal.yaml.

Skipping the wait when the DaemonSet is absent would not be equivalent: the wait is there so policy names are not rewritten until every node runs a version that understands them, and on canal that code runs in the canal DaemonSet.

Steps to Reproduce (for bugs)

1. Create a cluster with no CNI (for example kind with disableDefaultCNI: true and podSubnet: "10.244.0.0/16").
2. kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.32.0/manifests/canal.yaml, unmodified.
3. Wait for calico-kube-controllers to reach 1/1 Running.
4. kubectl -n kube-system logs -l k8s-app=calico-kube-controllers

Context

Seen after upgrading a cluster from v3.31.4 to v3.32.0. The pod stays 1/1 Running with 0 restarts, so the only symptom is the repeating error, but it reads like a broken cluster and prompted an investigation into whether policy enforcement had been affected.

Your Environment

• Calico version: v3.32.0, installed from manifests/canal.yaml
• Calico dataplane: iptables
• Orchestrator version: Kubernetes v1.34.11
• Operating System and version: Ubuntu 24.04.4 LTS