Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gateway Port <> envoy-service-http(s)-address serve flags #3616

Closed
stevesloka opened this issue Apr 26, 2021 · 6 comments
Closed

Gateway Port <> envoy-service-http(s)-address serve flags #3616

stevesloka opened this issue Apr 26, 2021 · 6 comments
Labels
area/gateway-api Issues or PRs related to the Gateway (Gateway API working group) API. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.

Comments

@stevesloka
Copy link
Member

Contour defines the ports which Envoy listens on via a set of contour serve flags:

  • envoy-service-http-address
  • envoy-service-http-port
  • envoy-service-https-address
  • envoy-service-https-port

These are defined in a Gateway.Listeners now. Need to find a pattern to not use the contour serve flags but allow the Gateway.Listener ports to take precedence in the event someone is utilizing GatewayAPI.

@stevesloka stevesloka added kind/feature Categorizes issue or PR as related to a new feature. area/gateway-api Issues or PRs related to the Gateway (Gateway API working group) API. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. labels Apr 26, 2021
@stevesloka
Copy link
Member Author

Another thought would be to move to use Gateway for Contour by default and have them select root HTTPProxies. Then we can deprecate the flags noted above and use the ports from the Gateway exclusively.

@youngnick
Copy link
Member

So, we would always have a Contour Gateway, that could also refer to HTTPProxy resources?

Having a Gateway able to refer to HTTPProxy resources as a type of Route is actually a great idea regardless, but this one does sound interesting.

@stevesloka
Copy link
Member Author

Yeah the thought would be to move Contour to use a Gateway to configure the listeners regardless of if you're using HTTPRoute, TLSRoute, etc. We'd have to add support for Ingress/HTTPProxy, but would give you a single place to define the listener parameters and removes gateway-api from being a "special" implementation.

@youngnick
Copy link
Member

Once we have Contour managing the Envoy Service at least, this would be a nice option, but I think we'll have to keep the old way around for a while (that is do a proper deprecation cycle), since people may not want to install Alpha CRDs in their clusters.

Copy link

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 github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Dec 13, 2023
@sunjayBhatia
Copy link
Member

I think this can be closed now, see https://projectcontour.io/docs/1.27/config/gateway-api/#gateway-listeners

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/gateway-api Issues or PRs related to the Gateway (Gateway API working group) API. kind/feature Categorizes issue or PR as related to a new feature. lifecycle/needs-triage Indicates that an issue needs to be triaged by a project contributor. lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale.
Projects
None yet
Development

No branches or pull requests

3 participants