ziti-controller: TraefikTcpRoute using old API group

[NeuronButter]

In the Traefik IngressRouteTCP template for the ziti-controller chart, the apiVersion is still traefik.containo.us/v1alpha1 however since v3, the API group should be traefik.io/v1alpha1. Is there any plans to bump this to be compatible with v3? Happy to submit a PR but it'll be a breaking change for anyone still using it and is on v2.

See here: https://doc.traefik.io/traefik/migration/v2-to-v3-details/#kubernetes-crds-api-group-traefikcontainous

[qrkourier]

I see what you're saying. Do you know if that change would continue to work with the latest K3S's bundled Traefik? That was the use case I had in mind when I added the optional Traefik IngressRouteTCP, as an alternative to Ingress.

If it would break latest K3S, then we could adjust template to allow overriding the API used group to broaden compatibility with more versions of Traefik.

If it wouldn't break latest stable K3S, then I'd welcome changing it. I seem to remember K3S was bundling an older Traefik.

The wider view is that I'd like to eventually trim down the alternatives we're supporting in the chart to two:

1. Ingress (Core)
2. TLSRoute (Gateway CRD)

[NeuronButter]

I see what you're saying. Do you know if that change would continue to work with the latest K3S's bundled Traefik? That was the use case I had in mind when I added the optional Traefik IngressRouteTCP, as an alternative to Ingress.

AFAIK, the latest version of k3s bundles the newest Traefik version

The wider view is that I'd like to eventually trim down the alternatives we're supporting in the chart to two

Honestly this makes the most sense, I only really raised the issue because I tried using the Traefik option and it didn't work as expected. There probably isn't a huge need for IngressRouteTCP going forward since it's relatively simple to setup manually anyway, and Ingress / gateway API would serve most users.

[qrkourier]

since it's relatively simple to setup manually

It's true. I reasoned there's a small, but meaningful, value in providing an "easy button" for publishing the ClusterIP services, primarily to ensure the correct servernames are configured at the cluster edge mapping to specific TCP listeners. Additionally, the requirement for TLS passthrough can be expressed in the chart's defaults or docs, at the very least.