9 Commits (1804b5879938c767d008ea996c0b579d81d5db50)

Author	SHA1	Message	Date
R.B. Boyer	c3fa46c3f6	test: possibly fix flaky TestEnvoy/case-ingress-gateway-multiple-services test (#15034) ... The integration test TestEnvoy/case-ingress-gateway-multiple-services is flaky and this possibly reduces the flakiness by explicitly waiting for services to show up in the catalog as healthy before waiting for them to show up in envoy as healthy which gives it just a bit more time to sync.	2 years ago
cskh	622804ad5b	fix flaky integration test (#14843)	2 years ago
cskh	69f40df548	feat(ingress gateway: support configuring limits in ingress-gateway c… (#14749) ... * feat(ingress gateway: support configuring limits in ingress-gateway config entry - a new Defaults field with max_connections, max_pending_connections, max_requests is added to ingress gateway config entry - new field max_connections, max_pending_connections, max_requests in individual services to overwrite the value in Default - added unit test and integration test - updated doc Co-authored-by: Chris S. Kim <ckim@hashicorp.com> Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com> Co-authored-by: Dan Stough <dan.stough@hashicorp.com>	2 years ago
R.B. Boyer	5afd04897c	test: use direct service registration in envoy integration tests (#9138) ... This has the biggest impact on enterprise test cases that use namespaced registrations, which prior to this change sometimes failed the initial registration because the namespace was not yet created.	4 years ago
R.B. Boyer	9801ef8eb1	agent: enable enable_central_service_config by default (#8746)	4 years ago
Chris Piraino	1a853fc954	Always require Host header values for http services (#7990) ... Previously, we did not require the 'service-name.*' host header value when on a single http service was exposed. However, this allows a user to get into a situation where, if they add another service to the listener, suddenly the previous service's traffic might not be routed correctly. Thus, we always require the Host header, even if there is only 1 service. Also, we add the make the default domain matching more restrictive by matching "service-name.ingress.*" by default. This lines up better with the namespace case and more accurately matches the Consul DNS value we expect people to use in this case.	5 years ago
Chris Piraino	5105bf3d67	Require individual services in ingress entry to match protocols (#7774) ... We require any non-wildcard services to match the protocol defined in the listener on write, so that we can maintain a consistent experience through ingress gateways. This also helps guard against accidental misconfiguration by a user. - Update tests that require an updated protocol for ingress gateways	5 years ago
Chris Piraino	f40833d094	Allow Hosts field to be set on an ingress config entry ... - Validate that this cannot be set on a 'tcp' listener nor on a wildcard service. - Add Hosts field to api and test in consul config write CLI - xds: Configure envoy with user-provided hosts from ingress gateways	5 years ago
Kyle Havlovitz	247f9eaf13	Allow ingress gateways to route traffic based on Host header ... This commit adds the necessary changes to allow an ingress gateway to route traffic from a single defined port to multiple different upstream services in the Consul mesh. To do this, we now require all HTTP requests coming into the ingress gateway to specify a Host header that matches "<service-name>.*" in order to correctly route traffic to the correct service. - Differentiate multiple listener's route names by port - Adds a case in xds for allowing default discovery chains to create a route configuration when on an ingress gateway. This allows default services to easily use host header routing - ingress-gateways have a single route config for each listener that utilizes domain matching to route to different services.	5 years ago