Drop all TCPRoute/UDPRoute-related code

[skriss]

It sounds like, given that Contour doesn't support TCPRoute/UDPRoute, we should not write status to them, not watch them, and not require/set up RBAC for them. Need to go through and delete all of the related code and RBAC.

Will require a corresponding operator PR as well.

[stevesloka]

So revert this: #4143 (comment)?

[youngnick]

Yes, I spent some time rechecking the spec, and the idea is that if you don't support an object, you don't interact with it at all, which limits your RBAC exposure and makes your controller easier to write.

I think it will require some careful troubleshooting documentation (in Gateway API, not Contour) to make sure that people know that if you don't get status on a Route, you need to check the Gateway to see if your Route has been rejected.

[stevesloka]

if you don't get status on a Route, you need to check the Gateway to see if your Route has been rejected.

But you'd never get status on the Gateway right? This would just look to the user like nothing is working.

[skriss]

I think the only indication you'd get is in the Gateway's listener status (https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.ListenerStatus) that supportedKinds does not include whatever kind you're trying to use.

[stevesloka]

Gotcha that makes sense for the gateway status, but doesn't help with the route status.

[youngnick]

Yes, it's an unfortunate downside of the fact that, although there's a core set of objects, the set of Routes is unbounded, so it's not possible for implementation authors to guarantee that all Routes that might reference a Gateway could be updated with a status. So, we (the Gateway API project) agreed that having a Condition in the Listener status was the best we could do.

That's what I meant by "There will need to be a troubleshooting guide", it's going to be important to teach everyone that when something isn't working with a Route, you check the Listener status first.

[stevesloka]

The only problem I can see with a troubleshooting guide is that right now it feels like "status" is the place to go to figure out anything. Not that a troubleshooting guide is a bad idea, I think that guide is great, just not sure if that's enough.

Can wait and see though to figure out if it does become a problem.

[youngnick]

I was also thinking about adding a default condition to the standard Route conditions block that puts Accepted to Unknown and has a message saying "A controller hasn't reconciled this, check the Gateway Listener status for more". (Obviously, upstream changes here).