6 Commits (38b5367d42b1b16ae86cc593439c5594099708b8)

Author	SHA1	Message	Date
Derek Menteer	aa4709ab74	Add envoy connection balancing. (#14616) ... Add envoy connection balancing config.	2 years ago
cskh	f22685b969	Config-entry: Support proxy config in service-defaults (#14395) ... * Config-entry: Support proxy config in service-defaults * Update website/content/docs/connect/config-entries/service-defaults.mdx Co-authored-by: Jeff Boruszak <104028618+boruszak@users.noreply.github.com>	2 years ago
Daniel Upton	a31738f76f	proxycfg-glue: server-local implementation of ResolvedServiceConfig ... This is the OSS portion of enterprise PR 2460. Introduces a server-local implementation of the proxycfg.ResolvedServiceConfig interface that sources data from a blocking query against the server's state store. It moves the service config resolution logic into the agent/configentry package so that it can be used in both the RPC handler and data source. I've also done a little re-arranging and adding comments to call out data sources for which there is to be no server-local equivalent.	2 years ago
Mark Anderson	98a2e282be	Fixup acl.EnterpriseMeta ... Signed-off-by: Mark Anderson <manderson@hashicorp.com>	3 years ago
R.B. Boyer	7b0548dd8d	server: suppress spurious blocking query returns where multiple config entries are involved (#12362) ... Starting from and extending the mechanism introduced in #12110 we can specially handle the 3 main special Consul RPC endpoints that react to many config entries in a single blocking query in Connect: - `DiscoveryChain.Get` - `ConfigEntry.ResolveServiceConfig` - `Intentions.Match` All of these will internally watch for many config entries, and at least one of those will likely be not found in any given query. Because these are blends of multiple reads the exact solution from #12110 isn't perfectly aligned, but we can tweak the approach slightly and regain the utility of that mechanism. ### No Config Entries Found In this case, despite looking for many config entries none may be found at all. Unlike #12110 in this scenario we do not return an empty reply to the caller, but instead synthesize a struct from default values to return. This can be handled nearly identically to #12110 with the first 1-2 replies being non-empty payloads followed by the standard spurious wakeup suppression mechanism from #12110. ### No Change Since Last Wakeup Once a blocking query loop on the server has completed and slept at least once, there is a further optimization we can make here to detect if any of the config entries that were present at specific versions for the prior execution of the loop are identical for the loop we just woke up for. In that scenario we can return a slightly different internal sentinel error and basically externally handle it similar to #12110. This would mean that even if 20 discovery chain read RPC handling goroutines wakeup due to the creation of an unrelated config entry, the only ones that will terminate and reply with a blob of data are those that genuinely have new data to report. ### Extra Endpoints Since this pattern is pretty reusable, other key config-entry-adjacent endpoints used by `agent/proxycfg` also were updated: - `ConfigEntry.List` - `Internal.IntentionUpstreams` (tproxy)	3 years ago
R.B. Boyer	8b987a4d59	configentry: make a new package to hold shared config entry structs that aren't used for RPC or the FSM (#12384) ... First two candidates are ConfigEntryKindName and DiscoveryChainConfigEntries.	3 years ago