Feature request - add Felix configuration at tigera-operator level

[grunlab]

Hi,

I'm currently deploying calico using tigera-operator.
And tigera-operator and calico configuration are deployed via argo-cd (trying to have a cluster 100% managed via gitops)

Currently, my installations.operator.tigera.io looks like this:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - allowedUses:
          - Workload
          - Tunnel
        assignmentMode: Automatic
        blockSize: 26
        cidr: 192.168.16.0/20
        disableBGPExport: false
        disableNewAllocations: false
        encapsulation: VXLANCrossSubnet
        name: default-ipv4-ippool
        natOutgoing: Enabled
        nodeSelector: all()
  kubeletVolumePluginPath: None

FYI, the full configuration is available here: https://gitlab.com/grunlab/calico/-/tree/main/deploy/kustomize

My issue:

I currently have those following warnings at calico-node container level:

$ kc logs calico-node-5cq4n | grep -i warning
...
2025-07-01 22:09:21.196 [WARNING][72] felix/int_dataplane.go 1309: Failed to auto-detect host MTU - no interfaces matched the MTU interface pattern. To use auto-MTU, set mtuIfacePattern to match your host's interfaces
2025-07-01 22:09:21.581 [WARNING][72] felix/int_dataplane.go 1309: Failed to auto-detect host MTU - no interfaces matched the MTU interface pattern. To use auto-MTU, set mtuIfacePattern to match your host's interfaces
2025-07-01 22:09:51.583 [WARNING][72] felix/int_dataplane.go 1309: Failed to auto-detect host MTU - no interfaces matched the MTU interface pattern. To use auto-MTU, set mtuIfacePattern to match your host's interfaces
2025-07-01 22:10:21.584 [WARNING][72] felix/int_dataplane.go 1309: Failed to auto-detect host MTU - no interfaces matched the MTU interface pattern. To use auto-MTU, set mtuIfacePattern to match your host's interfaces
...

Effectively, the name of the network interfaces of my nodes (end1 / Hardware: Turing PI RK1) is not matching the default MTU pattern :
^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|wlan|wwan).*)

Refer to https://docs.tigera.io/calico/latest/reference/felix/configuration --> MTUIfacePattern

$ ip a
...
2: end1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
...

Looking at the documentation, a custom MTU pattern could be set at felix configuration level via the parameter mtuIfacePattern
Configuring this parameter to ^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|end|wlan|wwan).*) should then solve my problem.

The documentation also say this:

If you have installed Calico using the operator, you cannot modify the environment provided to felix directly. To configure felix, see the [FelixConfiguration](https://docs.tigera.io/calico-cloud/reference/resources/felixconfig) resource instead.

Refer to https://docs.tigera.io/calico-cloud/reference/component-resources/node/felix/configuration

So i would need to manually patch (after the initial deployment done by the operator) the default felixconfiguration resource to add the parameter mtuIfacePattern ... in order to have something like:

$ kc get felixconfigurations.crd.projectcalico.org default -o yaml
apiVersion: crd.projectcalico.org/v1
kind: FelixConfiguration
metadata:
  name: default
spec:
  bpfConnectTimeLoadBalancing: TCP
  bpfEnabled: false
  bpfHostNetworkedNATWithoutCTLB: Enabled
  bpfLogLevel: ""
  floatingIPs: Disabled
  healthPort: 9099
  logSeverityScreen: Info
  mtuIfacePattern: ^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|end|wlan|wwan).*) <-- "manually added"
  nftablesMode: Disabled
  reportingInterval: 0s
  vxlanVNI: 4096

In order to keep my objective to have a cluster fully "gitops managed", I've tried to see if argo-cd could patch a resource that it did not deployed (I'm talking about the felixconfiguration resource: deployed by the operator by not directly by argo-cd) ... but it looks not possible : argoproj/argo-cd#2437

So it would be really nice if the felix configuration could be specified directly at tigera-operator installations.operator.tigera.io level (to avoid post configuration done after the operator first deployment and to be 100% gitops compliant)

Something like:

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    ipPools:
      - allowedUses:
          - Workload
          - Tunnel
        assignmentMode: Automatic
        blockSize: 26
        cidr: 192.168.16.0/20
        disableBGPExport: false
        disableNewAllocations: false
        encapsulation: VXLANCrossSubnet
        name: default-ipv4-ippool
        natOutgoing: Enabled
        nodeSelector: all()
  felixConfiguration:
    mtuIfacePattern: ^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|end|wlan|wwan).*)
  kubeletVolumePluginPath: None

Or (workaround), update the default MTU pattern to ^((en|wl|ww|sl|ib)[Pcopsvx].*|(eth|end|wlan|wwan).*)

Thank you

[tmjd]

I think as a workaround for new clusters you should be able to deploy the Calico CRDs (for exampl https://raw.githubusercontent.com/projectcalico/calico/v3.30.2/manifests/operator-crds.yaml) and a FelixConfiguration default resource with fields you want set. The operator and calico-node will update it with some defaults but it should work for you to set fields ahead of them starting.

There might be a race condition between the tigera-operator creating the FelixConfiguration default resource and ArgoCD creating it. I think ArgoCD would be quicker to create the resource. If you had problems with that you could add a sync-wave to the operator-crds and FelixConfig resource to ensure the creation ordering.