Support for "ignoring" a TunnelBinding?

[KAllan357]

I ended up configuring a series of TunnelBindings in an undocumented fashion and while it works, there was a funny issue that cropped up.

Use Case:

I wanted to use the disableDNSUpdates: true feature in the tunnelRef and a Proxied Wildcard in my cluster - but to also let the operator create the initial tunnel instead of bringing my own.

kind: ClusterTunnel
spec:
  newTunnel:
    name: foo
  ...
---
kind: TunnelBinding
metadata:
  name: wildcard
subjects:
  - name: dummy
    spec:
      fqdn: "*.fizz.buzz.me.com"
tunnelRef:
  name: foo
---
kind: TunnelBinding
metadata:
  name: a
subjects:
  - name: real-thing
    spec:
      fqdn: "traefik.fizz.buzz.me.com"
      target: "http://traefik.traefik.svc.cluster.local"
tunnelRef:
  name: foo
  disableDNSUpdates: true

When configured in this manner, I would get a good Cloudflare config yaml, albeit with a funky entry for "wildcard"

kind: ConfigMap
data:
  config.yaml: |
    tunnel: abc123
    ingress:
      - hostname: traefik.fizz.buzz.me.com
        service: http://traefik.traefik.svc.cluster.local
      - hostname: '*.fizz.buzz.me.com'
        service: http_status:404

When I repeated this configuration, but with slightly different name values, I noticed a different behavior:

    ingress:
      - hostname: '*.fizz.buzz.me.com'
        service: http_status:404
      - hostname: traefik.fizz.buzz.me.com
        service: http://traefik.traefik.svc.cluster.local

When the config ended up in this configuration, the first ingress would always match because of the wildcard, and the tunnel would respond with a 404. It wasn't until I renamed the TunnelBinding objects that I received a different layout of the config.

I suspect that TunnelBindings are returned alphabetically by name in getRelevantTunnelBindings and the loop here https://github.com/adyanth/cloudflare-operator/blob/main/controllers/tunnelbinding_controller.go#L561.

I was thinking there could be a feature to allow for the optional ignoring of a TunnelBinding. Or perhaps a priority number? Some sort of feature so that we could better order the resulting config.

[adyanth]

Oh interesting. The wildcard is added by the fallback_target on the tunnel rather than the binding. The sort order was necessary so as to not unnecessarily update the deployment just due to the order in which k8s decides to return the bindings.

I had not considered the edge case of adding a wildcard in the binding, which does cause issues. By design, the wildcard only comes in the end when using fallback_target. In that case, I think it would be ideal to use the sort order for non wildcards, and then sort the wildcards with longest matching first, and also officially allow overriding the fallback_target with a tunnel binding. Thanks!