Support weight on HTTPRoute.ForwardTo

[stevesloka]

Weight specifies the proportion of HTTP requests forwarded to the backend referenced by the ServiceName or BackendRef field. This is computed as weight/(sum of all weights in this ForwardTo list). For non-zero values, there may be some epsilon from the exact proportion defined here depending on the precision an implementation supports. Weight is not a percentage and the sum of weights does not need to equal 100.

If only one backend is specified and it has a weight greater than 0, 100% of the traffic is forwarded to that backend. If weight is set to 0, no traffic should be forwarded for this entry. If unspecified, weight defaults to 1.

// ref: https://gateway-api.sigs.k8s.io/spec/#networking.x-k8s.io/v1alpha1.HTTPRouteForwardTo

[stevesloka]

//ref: kubernetes-sigs/gateway-api#596

[xaleeks]

@stevesloka Seems you're working on it so I'm tagging it 1.15. The behavior in Gateway API here seems consistent with that of HTTPProxy, in that weights do not have to add to 100 and will be adjusted accordingly by proportionality.

Curious on our approach here for a feature that's not consistent with our CRD, I guess we just need to support both right? Concern is It can cause a bit of confusion as we continue to bring httproute and tlsroute up to parity to httpproxy.

Something for you to think about here as well @youngnick

[stevesloka]

Curious on our approach here for a feature that's not consistent with our CRD

I don't understand the question @xaleeks? Specifically for weights with gateway-api, they function the same short of returning a 503 when all are zero, but we spent months on a design to also apply that to HTTPProxy.

More generically, if the behaviors are different we'd have to match the API's design. For example, Gateway could allow for conflicts with path prefixes and it's resolved with timestamps, but with HTTPProxy that can't happen.

[xaleeks]

Thanks @stevesloka , sorry my wording was confusing. Behavior for this feature in question is consistent. I meant to ask 'Curious as to what we should do if we come across a feature in httproute that doesn't behave consistently with a similar thing in httpproxy' and you answered it.

We are just responsible for maintaining both for the time being, and if they diverge we still need to implement the gateway API.