Clarify route conflicts in the same resource

[stevesloka]

I ran into a conflict today thinking about implementation and thought it would be best to gather everyone else's thoughts on it.

There is some logic written in the API which states in the event of conflicts occur, how to handle (e.g. The oldest Route based on creation timestamp, or the Route appearing first in alphabetical order).

What if I have an HTTPRoute which has the same matches set, but with different forwardTo? We can't apply any timestamp logic since there isn't a resource to compare against.

What should a GET for local.projectcontour.io/ respond with? What conditions should I set?

Example:

kind: HTTPRoute
apiVersion: networking.x-k8s.io/v1alpha1
metadata:
  name: http-filter-1
  namespace: projectcontour-roots 
spec:
  hostnames:
    - local.projectcontour.io
  rules:
    - matches:  
      - path:
          type: Prefix
          value: /  
      forwardTo:
      - serviceName: insecure   #<--- serviceName different
        port: 80
    - matches:
      - path:
          type: Prefix
          value: / 
      forwardTo:
      - serviceName: rootapp   #<--- serviceName different
        port: 80

[gxthrj]

How about adding a priority field for each rule?

[tokers]

Priority works well when number of routes are small.

[youngnick]

We have a few options, I think:

• we make use of the fact that the routes are in an array/slice so they're naturally ordered. In this case, we just need to define which order takes precedence. I think it's okay to just pick one, as long as we say what that order is in the type documentation. My preference would be last one wins, since that just means that you run through all of them, and if a later one matches, you overwrite.
• Alternatively, we could mandate that identical matches load balance equally across all matches. This seems too surprising to me.

[robscott]

I agree that all we can just rely on the position in the list as a final tiebreaker here. I don't have a strong preference as far as order. The current spec uses ascending order in one instance, but it would be a bit easier to implement if we used descending order for this specific condition. The most important thing is that we choose a consistent method of tiebreaking here. It looks like we just need one more addition to https://github.com/kubernetes-sigs/gateway-api/blob/master/apis/v1alpha1/httproute_types.go#L180-L187.

[hbagdi]

+1 to what Rob said. We should add this to conflict resolution guidelines. I don't have any preference with ordering either, but it should be consistent across the API (not just rules in HTTPRoute).

[gxthrj]

If using the slice sorting, I prefer to choose the route based on the creation timestamp and choose The oldest Route one.

[youngnick]

Okay, for choosing which one wins given two matching Routes in a slice, we have two options then:

• first one wins. This means that, when iterating across a slice of Routes, you should take them and check if you've seen a matching route already, and if so, throw any other matches away.
• Last one wins, This means that, when iterating across a slice of Routes, you should over write whatever you see, and everything will just work out.

The first one feels a little bit more Go-like, the second one is easier to naively implement. Thoughts @robscott and @hbagdi ? Anyone else as well. If none of us have a preference, I'll just go with the second, and make a PR to update the docs Rob linked accordingly.

[robscott]

I have a slight preference for first one wins, but would be happy with either. In either case, this should be covered by webhook validation so whatever we add as guidance here should really only be relevant as a last resort.