TCPRouteRule and BackendRef

[ivanmatmati]

What happened:
Implementing a GW Api implementation, we're focusing on TCPRoute. I'm puzzled by the structures used in v1alpha2 for TCPRoute.
I see that TCPRouteSpec contains a slice of TCPRouteRule like this: Rules []TCPRouteRule. But a TCPRouteRule itself is simply a slice of BackendRef like this: BackendRefs []BackendRef. Comments in code don't reveal the reason for this structure. Finally, through Rules and BackendRefs, we're manipulating a slice of slice of BackendRef but for apparent reason.
What you expected to happen:
As there's no obvious reason for using of slice of slice of BackendRef, why not simply a slice of BackendRef ? This structure implies the two following examples should be different.But how?

rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: my-foo-service
          port: 6000
          weight: 1
        - group: ''
          kind: Service
          name: my-foo-service
          port: 8000
          weight: 1

and

rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: my-foo-service
          port: 6000
          weight: 1
    - backendRefs :
        - group: ''
          kind: Service
          name: my-foo-service
          port: 8000
          weight: 1

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

[shaneutt]

If my memory serves: the reason we're in this state is that we wanted to leave the option open for matching rules in the future, similar to what you see with HTTPRoute.Spec.Rules currently. Despite not having those rules now, it is simpler to add them horizontally at a later time as needed given this structure (which can be made backwards compatible) than to have to vertically add them later (which could not be made backwards compatible). GEP-735 is one of the few GEPs that has explored options in this area, and in fact for a brief period we had an implementation of this but decided to pull back on it (leading reason being a lack of "champion" with a use case to drive it forward) if that helps to provide some more context.

Given all that context I wanted to mention that in general we could use more champions for L4 related use cases and features, if you're interested in helping to provide new designs and redesigns of our L4 APIs like TCPRoute based on your own use cases (which by the sound of it are one of your 1st class use cases) we would welcome that in the form of GEPs, discussions, issues, and conversations in our weekly meetings.

[ivanmatmati]

Thanks @shaneutt for clear explanation, We'll keep in mind we can get involved for that matter.

[ivanmatmati]

Hi, following our discussion on this, I can report what looks like a bug. Consider these two examples of rules for TCP routes:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: route1
  namespace: ns1
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway1
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: tcp-echo-server
          namespace: ns1
          port: 9000
          weight: 10
    - backendRefs:
        - group: ''
          kind: Service
          name: tcp-echo-server-2
          namespace: ns2
          port: 9000
          weight: 13

From informers, I only get one backendRefs which is the second one mixed with weight from the first one. The only way to get correct data is using this one:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TCPRoute
metadata:
  name: route1
  namespace: ns1
spec:
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gateway1
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: tcp-echo-server
          namespace: ns1
          port: 9000
          weight: 10
        - group: ''
          kind: Service
          name: tcp-echo-server-2
          namespace: ns2
          port: 9000
          weight: 13

[youngnick]

Thanks for calling this out @ivanmatmati.

[shaneutt]

@ivanmatmati please do create an issue for this with clear reproduction steps and desired vs. current behavior, thank you!