consul

Commit Graph

Author	SHA1	Message	Date
R.B. Boyer	9e7b52dd4e	[1.14.x] grpc: ensure grpc resolver correctly uses lan/wan addresses on servers (#17286 ) The grpc resolver implementation is fed from changes to the router.Router. Within the router there is a map of various areas storing the addressing information for servers in those areas. All map entries are of the WAN variety except a single special entry for the LAN. Addressing information in the LAN "area" are local addresses intended for use when making a client-to-server or server-to-server request. The client agent correctly updates this LAN area when receiving lan serf events, so by extension the grpc resolver works fine in that scenario. The server agent only initially populates a single entry in the LAN area (for itself) on startup, and then never mutates that area map again. For normal RPCs a different structure is used for LAN routing. Additionally when selecting a server to contact in the local datacenter it will randomly select addresses from either the LAN or WAN addressed entries in the map. Unfortunately this means that the grpc resolver stack as it exists on server agents is either broken or only accidentally functions by having servers dial each other over the WAN-accessible address. If the operator disables the serf wan port completely likely this incidental functioning would break. This PR enforces that local requests for servers (both for stale reads or leader forwarded requests) exclusively use the LAN "area" information and also fixes it so that servers keep that area up to date in the router. A test for the grpc resolver logic was added, as well as a higher level full-stack test to ensure the externally perceived bug does not return. Also backport subtle test fix from #16396	2 years ago
hc-github-team-consul-core	aa3f89496d	backport of commit `8cdb0e7fd2` (#16002 ) Co-authored-by: Chris S. Kim <ckim@hashicorp.com>	2 years ago
hc-github-team-consul-core	0f52c25396	Backport of Add custom balancer to always remove subConns into release/1.14.x (#15836 ) * backport of commit `c37343dfcc` * backport of commit `27a0ffb6e8` * backport of commit `ee5841db54` * backport of commit `35f72880ce` * backport of commit `e8be8e4d55` * backport of commit `44d5c20f16` * backport of commit `5420eddfb0` * backport of commit `ec1b87a98e` Co-authored-by: Chris S. Kim <ckim@hashicorp.com>	2 years ago
hc-github-team-consul-core	2811464d56	Backport of fix(peering): increase the gRPC limit to 8MB into release/1.14.x (#15589 ) * backport of commit `84b287cc3c` Co-authored-by: cskh <hui.kang@hashicorp.com>	2 years ago
Chris S. Kim	fb7b645b29	Update hcp-scada-provider to fix diamond dependency problem with go-msgpack (#15185 ) (#15277 )	2 years ago
Paul Glass	d17af23641	gRPC server metrics (#14922 ) * Move stats.go from grpc-internal to grpc-middleware * Update grpc server metrics with server type label * Add stats test to grpc-external * Remove global metrics instance from grpc server tests	2 years ago
Dan Upton	b9e525d689	grpc: rename public/private directories to external/internal (#13721 ) Previously, public referred to gRPC services that are both exposed on the dedicated gRPC port and have their definitions in the proto-public directory (so were considered usable by 3rd parties). Whereas private referred to services on the multiplexed server port that are only usable by agents and other servers. Now, we're splitting these definitions, such that external/internal refers to the port and public/private refers to whether they can be used by 3rd parties. This is necessary because the peering replication API needs to be exposed on the dedicated port, but is not (yet) suitable for use by 3rd parties.	2 years ago

7 Commits (18831-backport1.14.10)