Tests the interactions between different resources (HTTPProxy, Ingress, Gateway APIs etc.)

[stevesloka]

Test the interactions between different resources (HTTPProxy, Ingress, Gateway APIs etc.) and how they interact together.

Originally posted by @sunjayBhatia in #3278 (comment)

[xaleeks]

More specifically, I read this to mean envoy concurrently gobbling up Ingress, HTTPProxy CRD, and HTTPRoutes / TLSRoutes when Gateways and GatewayClass are in play. I agree we need to test since nothing in our support for Gateway API precludes the coexistence of the other two. HTTPProxy is far richer than Gateway API right now so maybe a mix of the two is desirable to some users. In the future, I wonder if we should add constraints or best practice warnings in a practical sense.

Keeping it in Parking lot 1 it should probably get picked up in 1.16 or 1.17, as part of our GA support for Gateway API

[stevesloka]

I'm a bit worried about the interaction between all the APIs and coming up with unintended consequences that might not be apparent to users when you combine the APIs together.

We do get easy wins right now for things like Cert-Manager and HTTP01 challenges with Ingress resources, but I think there are ways that folks could abuse the APIs and take over portions of the controller without someone else knowing.

[youngnick]

I agree that there are risks of weird interactions, definitely. But I think the functionality it gives you is, on the whole, worth it. Being able to migrate from Ingress to HTTPProxy by adding in a HTTPProxy and removing it if anything goes wrong is excellent, and I think the same will be useful for HTTPProxy -> Gateway API migration.

But we should absolutely test it out, and document how the behavior works.

[xaleeks]

Tagging this for v1.16 so we can begin investigating, if you guys don’t mind. The reasoning is I feel like we’d rather surface strange behavior early on since we are still working through the design of the Contour Operator to manage all these pieces. This is a use case that Gateway API implementation has to be built to handle.

[youngnick]

We haven't made any progress on this one for 1.16, moving to 1.17.

[youngnick]

Still no progress, bumping to 1.18.

[skriss]

We haven't done this, I'm going to move it back to Prioritized Backlog and we can discuss inclusion in 1.19.

[xaleeks]

So the to-dos here are

1. define the resolution logic when multiple resources exist that define the same route aka URL
2. Identify any exceptions to the above if we do define some canonical order, ie. the wildcard from issue Ingress wildcard entry can be favored over HTTPProxy exact domain #4128 seems like an appropriate one
3. Document the logic externally for our users

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack