Wildcard path matching like nginx

[jdelgadillo]

Describe the solution you'd like We'd like the ability to use a wildcard for matching the path. As part of the IngressRoute, we'd like to do the following

...
spec:
  ...
  routes:
  - match: /path/to/object/[a-zA-Z0-9_]+/logs
     service:
     - name: log-service
        port: 9000
  -match: /path/to/object/[a-zA-Z0-9_]+
    - service:
       -name: object-management-service:
         port: 9000

I know this could be done by putting logs at the beginning and eliminating the need for regular expression matching, but the team really wants to have the path to the object precede the logs in the path and the back-end wants a separate service for the logging functionality.

Anything else you would like to add: nginx Ingress Controller has support for regular expression matching: https://kubernetes.github.io/ingress-nginx/user-guide/ingress-path-matching/

Environment:

• Contour version: 0.12.1
• Kubernetes version: (use kubectl version):

kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.7", GitCommit:"6f482974b76db3f1e0f5d24605a9d1d38fad9a2b", GitTreeState:"clean", BuildDate:"2019-03-25T02:41:57Z", GoVersion:"go1.10.8", Compiler:"gc", Platform:"linux/amd64"}

• Kubernetes installer & version: Azure AKS, Kubernetes 1.12.7
• Cloud provider or hardware configuration: Azure
• OS (e.g. from /etc/os-release): Centos 7

[davecheney]

Thank you for raising this issue. We are considering expanding the number of ways a route could match on as part of the ticket we call Routing NG, #1075 .

To be clear, it is unlikely we will support regex path matching because of its interaction with ingress route delegation. However we will probably support some form of path globing, eg. /foo/*/bar. I wanted to make this clear to set your expectations appropriately.

[jdelgadillo]

Thanks for the update @davecheney

Out of curiosity, how does current Contour handle multiple matches?

Say we have a request to /path/object/logs/:id and /path/object/:id

And we have an IngressRoute:

- match: /path/object/logs
  services:
  - name: log-service
- match: /
  services: 
  -name: object-management-service

The request GET /path/object/logs/id matches both. How does Contour decide which service gets the request? My experiments seem to indicate it always goes to object-management-service regardless of whether I put the match for object-management-service at the beginning or end of the array of matches.

[jdelgadillo]

Never mind. It was a mis-configured IngressRoute. Service name did not match the deployed service for logs

[davecheney]

The only path matching we support at the moment is prefix path matching. As Envoy matches routes in the order we present them to it, we sort the match: cases provided to us in descending order so that the most specific prefix takes precedence.

[stevesloka]

// cc #1457

[stevesloka]

Pushing the milestone since there needs additional design on #1612

[jpeach]

Note that regex matching will not work with prefix rewrite, since Envoy regards them as disjoint configurations :(

[ravilr]

@stevesloka regex path in K8s Ingress resource is a supported configuration in Contour today. Is the new design for HTTPProxy here https://github.com/projectcontour/contour/blob/master/design/routing-design.md#wildcard-path-routing going to support regex for path matching in routes ?

[stevesloka]

@ravilr yup that was the goal! We have the design and even some impl in a PR, however, during the PR ran into a few issues that we needed to re-think about and it got bumped from the Contour v1 release.

[ravilr]

Thanks for the reply. the design doc specifically mentions only wildcards (*) in paths. Is it limited to wildcards (*) only or even '^+*[]%' / those supported by Envoy's safe_regex ?

[youngnick]

The reason is inclusion. If we allow regexes that include path separators, then, when building a tree of included documents by path, some paths may be undefinable, or may overlap in difficult-to-predict ways. It's not an unsolvable problem, I don't think, but as @stevesloka said, it's not one that we have had a chance to think about yet.

The wildcard here is intended to be a path segment - that is, anything between / characters. The reason it's not anything more complicated (like ^+*[]% or other regex metacharacters) is that then Contour will need to grow a regex parsing engine and make a guess about what you mean, in case your HTTPProxy document is included into another one.

[youngnick]

The comments on #1612 capture some of these concerns.