14 Commits (74158a8aa29e74a1887099798b185b9c68078d0f)

Author	SHA1	Message	Date
Dan Upton	2427e38839	Enable servers to configure arbitrary proxies from the catalog (#13244) ... OSS port of enterprise PR 1822 Includes the necessary changes to the `proxycfg` and `xds` packages to enable Consul servers to configure arbitrary proxies using catalog data. Broadly, `proxycfg.Manager` now has public methods for registering, deregistering, and listing registered proxies — the existing local agent state-sync behavior has been moved into a separate component that makes use of these methods. When an xDS session is started for a proxy service in the catalog, a goroutine will be spawned to watch the service in the server's state store and re-register it with the `proxycfg.Manager` whenever it is updated (and clean it up when the client goes away).	3 years ago
Evan Culver	000d0621b4	connect: Add Envoy 1.22 to integration tests, remove Envoy 1.18 (#12805) ... Co-authored-by: R.B. Boyer <rb@hashicorp.com>	3 years ago
R.B. Boyer	cb82949ac6	xds: errors from the xds serverless plugin are fatal (#12682)	3 years ago
Eric	cf3e517d0e	Create and wire up the serverless patcher	3 years ago
Eric	f5c9fa6fa6	Make an xdscommon package that will be shared between Consul and Envoy plugins	3 years ago
Freddy	378a7258e3	Prevent xDS tight loop on cfg errors (#12195)	3 years ago
R.B. Boyer	89bd1f57b5	xds: allow only one outstanding delta request at a time (#12236) ... Fixes #11876 This enforces that multiple xDS mutations are not issued on the same ADS connection at once, so that we can 100% control the order that they are applied. The original code made assumptions about the way multiple in-flight mutations were applied on the Envoy side that was incorrect.	3 years ago
R.B. Boyer	d2c0945f52	xds: fix for delta xDS reconnect bug in LDS/CDS (#12174) ... When a wildcard xDS type (LDS/CDS/SRDS) reconnects from a delta xDS stream, prior to envoy `1.19.0` it would populate the `ResourceNamesSubscribe` field with the full list of currently subscribed items, instead of simply omitting it to infer that it wanted everything (which is what wildcard mode means). This upstream issue was filed in envoyproxy/envoy#16063 and fixed in envoyproxy/envoy#16153 which went out in Envoy `1.19.0` and is fixed in later versions (later refactored in envoyproxy/envoy#16855). This PR conditionally forces LDS/CDS to be wildcard-only even when the connected Envoy requests a non-wildcard subscription, but only does so on versions prior to `1.19.0`, as we should not need to do this on later versions. This fixes the failure case as described here: #11833 (comment) Co-authored-by: Huan Wang <fredwanghuan@gmail.com>	3 years ago
Evan Culver	7e20a5e4f9	connect: remove support for Envoy 1.15	3 years ago
R.B. Boyer	b2d17ac448	xds: fix representation of incremental xDS subscriptions (#10987) ... Fixes #10563 The `resourceVersion` map was doing two jobs prior to this PR. The first job was to track what version of every resource we know envoy currently has. The second was to track subscriptions to those resources (by way of the empty string for a version). This mostly works out fine, but occasionally leads to consul removing a resource and accidentally (effectively) unsubscribing at the same time. The fix separates these two jobs. When all of the resources for a subscription are removed we continue to track the subscription until envoy explicitly unsubscribes	3 years ago
Daniel Nephin	8252a2691c	xds: document how authorization works	3 years ago
R.B. Boyer	848ad8535b	xds: ensure that dependent xDS resources are reconfigured during primary type warming (#10381) ... Updates to a cluster will clear the associated endpoints, and updates to a listener will clear the associated routes. Update the incremental xDS logic to account for this implicit cleanup so that we can finish warming the clusters and listeners. Fixes #10379	3 years ago
R.B. Boyer	ede14b7c54	xds: emit a labeled gauge of connected xDS streams by version (#10243) ... Fixes #10099	4 years ago
R.B. Boyer	71d45a3460	Support Incremental xDS mode (#9855) ... This adds support for the Incremental xDS protocol when using xDS v3. This is best reviewed commit-by-commit and will not be squashed when merged. Union of all commit messages follows to give an overarching summary: xds: exclusively support incremental xDS when using xDS v3 Attempts to use SoTW via v3 will fail, much like attempts to use incremental via v2 will fail. Work around a strange older envoy behavior involving empty CDS responses over incremental xDS. xds: various cleanups and refactors that don't strictly concern the addition of incremental xDS support Dissolve the connectionInfo struct in favor of per-connection ResourceGenerators instead. Do a better job of ensuring the xds code uses a well configured logger that accurately describes the connected client. xds: pull out checkStreamACLs method in advance of a later commit xds: rewrite SoTW xDS protocol tests to use protobufs rather than hand-rolled json strings In the test we very lightly reuse some of the more boring protobuf construction helper code that is also technically under test. The important thing of the protocol tests is testing the protocol. The actual inputs and outputs are largely already handled by the xds golden output tests now so these protocol tests don't have to do double-duty. This also updates the SoTW protocol test to exclusively use xDS v2 which is the only variant of SoTW that will be supported in Consul 1.10. xds: default xds.Server.AuthCheckFrequency at use-time instead of construction-time	4 years ago