Migration from manifest to operator; configmaps "kubernetes-services-endpoint" already exists

[moss-telavox]

Hey guys!

Attempting to migrate from manifest installation from kubespray to the operator following https://docs.tigera.io/calico/latest/operations/operator-migration.

We run calico in ebpf mode.

Ran into the following problem, where the operator tries to copy over the kubernetes-services-endpoint configmap to the tigera-operator namespace:

Status:
  Conditions:
    Last Transition Time:  2025-03-03T19:00:20Z
    Message:               Error converting existing installation: failed to create configmap "kubernetes-services-endpoint" in tigera-operator ns configmaps "kubernetes-services-endpoint" already exists
    Observed Generation:   1
    Reason:                MigrationError
    Status:                True
    Type:                  Degraded
Events:                    <none>

By the looks of it, the operator runs

operator/pkg/controller/migration/convert/bpf.go

Lines 30 to 46 in fbdd0a6

	func copyK8sServicesEPConfigMap(c *components) error {
	// Extract end point host, port from configmap in kube-system namespace
	cmName := render.K8sSvcEndpointConfigMapName
	cm := &corev1.ConfigMap{}
	cmNamespacedName := types.NamespacedName{
	Name: cmName,
	Namespace: "kube-system",
	}
	if err := c.client.Get(ctx, cmNamespacedName, cm); err != nil {
	return fmt.Errorf("failed read to configMap %q: %s", cmName, err)
	}
	host := cm.Data["KUBERNETES_SERVICE_HOST"]
	port := cm.Data["KUBERNETES_SERVICE_PORT"]
	// Create the config map in tigera-operator namespace
	cmNamespacedName.Namespace = common.OperatorNamespace()
	err := c.client.Create(ctx, &corev1.ConfigMap{

multiple times.
Only the first one will succeed.

Or to put in another way, th configmap has been copied

$ kubectl get cm -n kube-system kubernetes-services-endpoint  
NAME                           DATA   AGE
kubernetes-services-endpoint   2      17d
$ kubectl get cm -n tigera-operator kubernetes-services-endpoint  
NAME                           DATA   AGE
kubernetes-services-endpoint   2      8m59s

But the migration gets stuck because the subsequent copies fail.

I managed to move on with the migration after changing from err := c.client.Create to err := c.client.Update, as Update can create resources as well.
Can create a PR for that if interesting, but maybe we want to look into why copyK8sServicesEPConfigMap runs more than once. (Maybe some reason for it?)

[moss-telavox]

as Update can create resources as well.

Scratch that, I'm not so certain of that.
Probably just that my update image can do Update because the configmap had already been copied to tigera operator.

[github-actions]

This issue is stale because it has been open for 30 days with no activity.