Implement gateway-apis behavior

[youngnick]

Tasks to implement:

General:

• Rename service-apis to gateway-api (Rename references of service-apis to gateway-api #3349)

HTTPRouteSpec:

• Valid Gateways for Gateway.AllowType (Implement Gateway.AllowType in Processor #3351)
• Add validation of hostnames (Validation for hostnames #3353)
• Missing service (Missing serviceName in a HTTPRouteForwardTo #3354)
• "Exact" HTTPHeaderMatch (Implement "Exact" HTTPHeaderMatch #3356)
• Implement the RouteBindingSelector (Implement the RouteBindingSelector #3401)
• Add TLS Support (Add Gateway API TLS Support #3404)
• Set status on HTTPRoute resources (Set status on HTTPRoute resources #3436)
• Spec.Rules.ForwardTo is empty return HTTP status code 503 (Spec.Rules.ForwardTo is empty return HTTP status code 503 #3454)
• Invalid Spec.Rules.ForwardTo should set status on Gateway (Invalid Spec.Rules.ForwardTo should set status on Gateway #3455)
• Filter on Gateway.Listener.Protocol (Filter on Gateway.Listener.Protocol #3540)
• Route.ForwardTo missing service should return HTTP 503 (Route.ForwardTo missing service should return HTTP 503 #3553)
• Support HTTPRoute requestHeaderModifier RouteFilterType (Support HTTPRoute requestHeaderModifier RouteFilterType #3559)
• Support weight on HTTPRoute.ForwardTo (Support weight on HTTPRoute.ForwardTo #3560)
• Take the Gateway.Listener.hostname into account when processing routes (Take the Gateway.Listener.hostname into account when processing routes #3561)
• Gateway API: HTTPRoutes should have at most one Condition of a given type (Gateway API: HTTPRoutes should have at most one Condition of a given type #3534)
• Move away from Gateway Configuration in Contour Config File (Move away from Gateway Configuration in Contour Config File #3617)
• Set status on Gateway (Set status on Gateway #3437)
• "RegularExpression" HTTPHeaderMatch (Gateway API: "RegularExpression" HTTPHeaderMatch [custom] #3357)
• Set status on TCPRoute (Set Status on TCPRoute #3441)
• Set Status on UDPRoute (Set Status on UDPRoute #3442)
• Update route status if gateway selector changes (Remove RouteParentStatus from routes if a Gateway no longer allows the route's kind or namespace #3526)
• Listener Route binding selector kind must match Routes compatible with Listener protocol (Gateway API: Listener Route binding selector kind must match Routes compatible with Listener protocol #3529)
• Ensure *Route status updates respect observed generation status update order (Gateway API: Ensure *Route status updates respect observed generation status update order #3533)
• Support HTTPRoute requestMirror RouteFilterType (Support HTTPRoute requestMirror RouteFilterType [extended] #3557)
• Handle Route conflicts with HTTPRoute.Matches (Gateway API: handle Route conflicts with HTTPRoute.Matches #3608)
• Gateway Port <> envoy-service-http(s)-address serve flags (Gateway Port <> envoy-service-http(s)-address serve flags #3616)
• Add support for GatewayAPI Admission webhook (Add support for GatewayAPI Admission webhook #3639)
• Tests the interactions between different resources (HTTPProxy, Ingress, Gateway APIs etc.) (Tests the interactions between different resources (HTTPProxy, Ingress, Gateway APIs etc.) #3367)

Experimental:

• Contour Managed Envoy Contour Managed Envoy #3545

[youngnick]

Blocked on service-apis actually defining the behaviour.

[danehans]

v1alpha1 of service apis is scheduled to be released this month (August 2020). As discussed during this week's community call, it would be helpful to begin planning for the implementation. @jpeach suggested that work such as #2683 be completed prior to the service apis implementation. Should this issue be used as the meta issue for describing a) the work that needs to be completed prior to implementing service apis and b) the actual service api's implementation? Should a separate issue be created for a? In general, I would like to enumerate the work needed to implement service-apis, including anything that's needed prior to the actual implementation so myself and others can begin helping with the service apis implementation.

/cc @Miciah @stevesloka

[youngnick]

Thanks @danehans, I agree that this issue should hold:

• a list of issues that block doing some implementation of the service apis behavior
• a list of issues that need to be implemented to actually deliver the behavior as at v1alpha1.

We should figure those out here, then I will add them to the initial description as a checklist so we get a count.

[jpeach]

Blocked on #2226, which will allow new builders to be added at runtime.

[youngnick]

• Decision about *Class behavior (IngressClass and GatewayClass) Decision: How do we implement *Class objects (IngressClass and GatewayClass) #2809
• Work to add builder interface (@skriss) internal/dag: Refactor builder #2226
• Work to add interface between DAG and xDS caches (@jpeach) Introduce DAG model consumer abstractions #2775

[youngnick]

Okay, for the service-apis objects to be supported in Contour, we will need:

• GatewayClass watching support. Note that as decided in Decision: How do we implement *Class objects (IngressClass and GatewayClass) #2809, only one GatewayClass is supported per Contour deployment. The best way to make this work is TBD. (Not needed to implement)
• Gateway watching support. Note that Contour itself will not create Gateways, it will watch for Gateways in its GatewayClass, and build a configuration to send valid Listeners to Envoy, writing back information about Listener status to the relevant Gateway.
• HTTPRoute watching support. Contour should take HTTPRoutes referenced from Listeners, and add config to Envoy to expose the routes. (internal/dag: Add informers for TLSRoute & BackendPolicy #3280)
• TLSRoute watching support. Contour should take TLSRoutes referenced from Listeners, and add config to Envoy to expose the routes. (internal/dag: Add informers for TLSRoute & BackendPolicy #3280)
• BackendResource (internal/dag: Add informers for TLSRoute & BackendPolicy #3280)

These are the only resources that Contour needs to implement for its service-apis support. Note that we will probably need to work closely with upstream to define what conformance means for this feature set (that is, the "ingress controller" feature set, or some similar name).

I'm going to start working on a design document for this implementation.

[shashankram]

I am interested in exploring the use of Contor for ingress using the Gateway API. Is there a document that describes how much of the API is supported, and what the roadmap is? It seems like there is functionality that is usable based on https://projectcontour.io/guides/gateway-api/, just wasn't sure exactly what is supported at the moment.

[youngnick]

We currently don't have a canonical document aside from this issue, as the support is changing too quickly. We do only plan to support HTTPRoute and TLSRoute as route targets however, in line with our positioning of Contour as a layer 7 ingress controller.

[skriss]

Is anyone opposed to closing this tracking issue now that our support is pretty far along, and managing the remaining backlog solely via the gateway-api label?

[skriss]

Is anyone opposed to closing this tracking issue now that our support is pretty far along, and managing the remaining backlog solely via the gateway-api label?

Alright, closing this one out, follow the area/gateway-api label for ongoing work.