Traefik v3 breaks Kubernetes Ingress Prefix Path Regex about traefik HOT 6 OPEN

I feel that this bug shouldn't have been closed?
I cannot get regex's working for an Ingress using Traefik v3
Using the example given for this issue:

          - path: /xxx/v1/yyyy/{customer:[a-z0-9]+}/push/

I've tried writing it two other ways and the v3 parser does not treat either as a regex:

          - path: /xxx/v1/yyyy/{[a-z0-9]+}/push/

          - path: /xxx/v1/yyyy/[a-z0-9]+/push/

from traefik.

Hey @fkollmann,
As it's explained in the migration guide, defaultRuleSyntax needs to be set to v2 if you want to keep the v2 format by default.
This should be used temporarily, while migrating to the default v3 syntax.

from traefik.

If you set defaultRuleSyntax to be v2 will Ingresses using v3 syntax (whatever that may be, I haven't found how it differs yet) still work?
I'm trying to work out how you'd migrate without an outage.

from traefik.

Hello @jim-barber-he,

Could you confirm that the bug you described may be fixed by this PR?

from traefik.

Hi @nmengin,

Author of the mentioned PR here. I don't think my PR fixes this issue. Further more it might even make the workaround (defaultRuleSyntax: v2) impossible. Therefore I would remove my changes regarding ingress configuration from my PR.

Digging through the code it seems like that with the current implementation it is not possible to configure ingress paths with regex matching. Only Path(...) and PathPrefix(...) are used internally.

Maybe using path type ImplementationSpecific in combination with the annotation traefik.ingress.kubernetes.io/router.pathmatcher could be another workaround. But this feels kinda hacky and the documentation says only Path and PathPrefix should be used as path matchers.

To reiterate, it is not mentioned in the migration guide that it is no longer possible to use regex for routing in this use case. So I think this is a real bug and should be reopened.

Disclaimer: Unfortunately I have no experience with Kubernetes ingress configuration. I purely went with what's in the code and might have missed something. So take this with a grain of salt.

from traefik.

Hello @HalloTschuess,

Thank you for your feedback.
I re-opened the issue to discuss it during the next triage with the other maintainers.

So I think this is a real bug and should be reopened.

From what I understand in this issue, such behavior is not expected indeed.

from traefik.