Define the universe of resources that can be "routes"

[Miciah]

What would you like to be added:
The universe of allowable resources that can be "routes" should be defined.

For example, the universe could be defined as HTTPRoute, TCPRoute (if the gateway controller implements TCPRoute, which is an extension), and any additional resources as defined by the gateway controller implementation.

Why is this needed:
In a discussion of allowing the use of label selectors instead of object references to specify routes, @howardjohn raised the objection that a controller must know the type of the route:

routes may select objects other than just HttpRoute and TcpRoute. With this approach, an implementer would need to to query for all objects for the label? I suppose they could limit it to the set of objects that they consider valid routes though

#12 (comment)

It would be useful to be able to say that the label selector can match (for example) HTTPRoute, TCPRoute, and any additional implementation-specific resources, as defined by the gateway controller. With this definition, an implementer would know to use informers for these specific resources.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[hbagdi]

/remove-lifecycle stale

[danehans]

Can the universe be constrained by the api group, i.e. networking.x-k8s.io?

[robscott]

I think we'd want to leave open the possibility of implementation specific route types so I'd lean towards no. There's also the L4 proposal that could result in a Service being considered a Route.

[Miciah]

The critical point was that implementers must have a well defined, finite set of resources that an implementation must list and watch. I believe we should (a) enumerate the core resources that must be in this set but also (b) permit an implementer to include additional resources in the set, as Rob mentions. Doing so would enable the implementer (a) to know exactly which types to list or watch and (b) to extend the core functionality with additional "route" resources.

The following is an example of what I have in mind: "The gateway controller recognizes any object of any of the following resources from the networking.x-k8s.io API group as routes: HTTPRoute, TCPRoute, and TrafficSplit. The gateway controller may recognize additional resources as 'routes' as defined by the specific implementation." This explanation could be added to the godoc for RouteBindingSelector.

One additional point to consider is that, since this issue was created, we have replaced the gateway's list of route references with route selectors, which makes it even more important to lay out clear and explicit semantics of what a "route" is and what objects a route selector could possibly select, especially if the route selector could potentially select common resources such as services.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[jpeach]

/remove-lifecycle stale

[robscott]

Closing now that Gateway Route Selection includes kind/resource.