2023-03-28 18:39:22 +00:00
|
|
|
// Copyright (c) HashiCorp, Inc.
|
2023-08-11 13:12:13 +00:00
|
|
|
// SPDX-License-Identifier: BUSL-1.1
|
2023-03-28 18:39:22 +00:00
|
|
|
|
2022-09-01 14:45:07 +00:00
|
|
|
package configentry
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
|
|
|
|
"github.com/hashicorp/go-hclog"
|
2023-01-18 19:43:53 +00:00
|
|
|
"github.com/imdario/mergo"
|
2022-09-01 14:45:07 +00:00
|
|
|
"github.com/mitchellh/copystructure"
|
|
|
|
|
|
|
|
"github.com/hashicorp/consul/agent/structs"
|
|
|
|
)
|
|
|
|
|
|
|
|
func ComputeResolvedServiceConfig(
|
|
|
|
args *structs.ServiceConfigRequest,
|
|
|
|
entries *ResolvedServiceConfigSet,
|
|
|
|
logger hclog.Logger,
|
|
|
|
) (*structs.ServiceConfigResponse, error) {
|
|
|
|
var thisReply structs.ServiceConfigResponse
|
|
|
|
|
|
|
|
thisReply.MeshGateway.Mode = structs.MeshGatewayModeDefault
|
|
|
|
|
2023-01-18 19:43:53 +00:00
|
|
|
// Store the upstream defaults under a wildcard key so that they can be applied to
|
|
|
|
// upstreams that are inferred from intentions and do not have explicit upstream configuration.
|
2023-02-03 15:51:53 +00:00
|
|
|
wildcard := structs.PeeredServiceName{
|
|
|
|
ServiceName: structs.NewServiceName(structs.WildcardSpecifier, args.WithWildcardNamespace()),
|
|
|
|
}
|
2023-01-18 19:43:53 +00:00
|
|
|
wildcardUpstreamDefaults := make(map[string]interface{})
|
|
|
|
// resolvedConfigs stores the opaque config map for each upstream and is keyed on the upstream's ID.
|
2023-02-03 15:51:53 +00:00
|
|
|
resolvedConfigs := make(map[structs.PeeredServiceName]map[string]interface{})
|
2023-01-18 19:43:53 +00:00
|
|
|
|
2022-09-01 14:45:07 +00:00
|
|
|
// TODO(freddy) Refactor this into smaller set of state store functions
|
|
|
|
// Pass the WatchSet to both the service and proxy config lookups. If either is updated during the
|
|
|
|
// blocking query, this function will be rerun and these state store lookups will both be current.
|
|
|
|
// We use the default enterprise meta to look up the global proxy defaults because they are not namespaced.
|
2023-01-18 19:43:53 +00:00
|
|
|
|
2023-07-05 14:32:10 +00:00
|
|
|
var proxyConfGlobalProtocol string
|
2022-09-01 14:45:07 +00:00
|
|
|
proxyConf := entries.GetProxyDefaults(args.PartitionOrDefault())
|
|
|
|
if proxyConf != nil {
|
|
|
|
// Apply the proxy defaults to the sidecar's proxy config
|
|
|
|
mapCopy, err := copystructure.Copy(proxyConf.Config)
|
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("failed to copy global proxy-defaults: %v", err)
|
|
|
|
}
|
2023-01-18 19:43:53 +00:00
|
|
|
|
2022-09-01 14:45:07 +00:00
|
|
|
thisReply.ProxyConfig = mapCopy.(map[string]interface{})
|
|
|
|
thisReply.Mode = proxyConf.Mode
|
|
|
|
thisReply.TransparentProxy = proxyConf.TransparentProxy
|
2023-04-19 19:45:00 +00:00
|
|
|
thisReply.MutualTLSMode = proxyConf.MutualTLSMode
|
2022-09-01 14:45:07 +00:00
|
|
|
thisReply.MeshGateway = proxyConf.MeshGateway
|
|
|
|
thisReply.Expose = proxyConf.Expose
|
2022-12-19 20:19:37 +00:00
|
|
|
thisReply.EnvoyExtensions = proxyConf.EnvoyExtensions
|
2022-12-22 20:18:15 +00:00
|
|
|
thisReply.AccessLogs = proxyConf.AccessLogs
|
2022-09-01 14:45:07 +00:00
|
|
|
|
2023-01-20 17:25:51 +00:00
|
|
|
// Only MeshGateway and Protocol should affect upstreams.
|
2023-01-18 19:43:53 +00:00
|
|
|
// MeshGateway is strange. It's marshaled into UpstreamConfigs via the arbitrary map, but it
|
|
|
|
// uses concrete fields everywhere else. We always take the explicit definition here for
|
|
|
|
// wildcard upstreams and discard the user setting it via arbitrary map in proxy-defaults.
|
2023-01-20 17:25:51 +00:00
|
|
|
if mgw, ok := thisReply.ProxyConfig["mesh_gateway"]; ok {
|
|
|
|
wildcardUpstreamDefaults["mesh_gateway"] = mgw
|
2023-01-18 19:43:53 +00:00
|
|
|
}
|
|
|
|
if !proxyConf.MeshGateway.IsZero() {
|
|
|
|
wildcardUpstreamDefaults["mesh_gateway"] = proxyConf.MeshGateway
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
2023-07-05 14:32:10 +00:00
|
|
|
|
|
|
|
// We explicitly DO NOT merge the protocol from proxy-defaults into the wildcard upstream here.
|
|
|
|
// TProxy will try to use the data from the `wildcardUpstreamDefaults` as a source of truth, which is
|
|
|
|
// normally correct to inherit from proxy-defaults. However, it is NOT correct for protocol.
|
|
|
|
//
|
|
|
|
// This edge-case is different for `protocol` from other fields, since the protocol can be
|
|
|
|
// set on both the local `ServiceDefaults.UpstreamOverrides` and upstream `ServiceDefaults.Protocol`.
|
|
|
|
// This means that when proxy-defaults is set, it would always be treated as an explicit override,
|
|
|
|
// and take precedence over the protocol that is set on the discovery chain (which comes from the
|
|
|
|
// service's preference in its service-defaults), which is wrong.
|
|
|
|
//
|
|
|
|
// When the upstream is not explicitly defined, we should only get the protocol from one of these locations:
|
|
|
|
// 1. For tproxy non-peering services, it can be fetched via the discovery chain.
|
|
|
|
// The chain compiler merges the proxy-defaults protocol with the upstream's preferred service-defaults protocol.
|
|
|
|
// 2. For tproxy non-peering services with default upstream overrides, it will come from the wildcard upstream overrides.
|
|
|
|
// 3. For tproxy non-peering services with specific upstream overrides, it will come from the specific upstream override defined.
|
|
|
|
// 4. For tproxy peering services, they do not honor the proxy-defaults, since they reside in a different cluster.
|
|
|
|
// The data will come from a separate peerMeta field.
|
|
|
|
// In all of these cases, it is not necessary for the proxy-defaults to exist in the wildcard upstream.
|
|
|
|
parsed, err := structs.ParseUpstreamConfigNoDefaults(mapCopy.(map[string]interface{}))
|
|
|
|
if err != nil {
|
|
|
|
return nil, fmt.Errorf("failed to parse upstream config map for proxy-defaults: %v", err)
|
2023-01-20 17:25:51 +00:00
|
|
|
}
|
2023-07-05 14:32:10 +00:00
|
|
|
proxyConfGlobalProtocol = parsed.Protocol
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
serviceConf := entries.GetServiceDefaults(
|
|
|
|
structs.NewServiceID(args.Name, &args.EnterpriseMeta),
|
|
|
|
)
|
|
|
|
if serviceConf != nil {
|
2022-09-26 16:29:06 +00:00
|
|
|
|
2022-09-01 14:45:07 +00:00
|
|
|
if serviceConf.Expose.Checks {
|
|
|
|
thisReply.Expose.Checks = true
|
|
|
|
}
|
|
|
|
if len(serviceConf.Expose.Paths) >= 1 {
|
|
|
|
thisReply.Expose.Paths = serviceConf.Expose.Paths
|
|
|
|
}
|
|
|
|
if serviceConf.MeshGateway.Mode != structs.MeshGatewayModeDefault {
|
|
|
|
thisReply.MeshGateway.Mode = serviceConf.MeshGateway.Mode
|
2023-01-18 19:43:53 +00:00
|
|
|
wildcardUpstreamDefaults["mesh_gateway"] = serviceConf.MeshGateway
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
if serviceConf.TransparentProxy.OutboundListenerPort != 0 {
|
|
|
|
thisReply.TransparentProxy.OutboundListenerPort = serviceConf.TransparentProxy.OutboundListenerPort
|
|
|
|
}
|
|
|
|
if serviceConf.TransparentProxy.DialedDirectly {
|
|
|
|
thisReply.TransparentProxy.DialedDirectly = serviceConf.TransparentProxy.DialedDirectly
|
|
|
|
}
|
|
|
|
if serviceConf.Mode != structs.ProxyModeDefault {
|
|
|
|
thisReply.Mode = serviceConf.Mode
|
|
|
|
}
|
|
|
|
if serviceConf.Destination != nil {
|
|
|
|
thisReply.Destination = *serviceConf.Destination
|
|
|
|
}
|
2023-08-25 16:47:20 +00:00
|
|
|
if serviceConf.RateLimits != nil {
|
|
|
|
thisReply.RateLimits = *serviceConf.RateLimits
|
|
|
|
}
|
2022-09-01 14:45:07 +00:00
|
|
|
|
2022-09-26 16:29:06 +00:00
|
|
|
// Populate values for the proxy config map
|
|
|
|
proxyConf := thisReply.ProxyConfig
|
|
|
|
if proxyConf == nil {
|
|
|
|
proxyConf = make(map[string]interface{})
|
|
|
|
}
|
|
|
|
if serviceConf.Protocol != "" {
|
|
|
|
proxyConf["protocol"] = serviceConf.Protocol
|
|
|
|
}
|
|
|
|
if serviceConf.BalanceInboundConnections != "" {
|
|
|
|
proxyConf["balance_inbound_connections"] = serviceConf.BalanceInboundConnections
|
|
|
|
}
|
2022-09-01 14:45:07 +00:00
|
|
|
if serviceConf.MaxInboundConnections > 0 {
|
2022-09-26 16:29:06 +00:00
|
|
|
proxyConf["max_inbound_connections"] = serviceConf.MaxInboundConnections
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
2022-09-12 14:41:58 +00:00
|
|
|
if serviceConf.LocalConnectTimeoutMs > 0 {
|
2022-09-26 16:29:06 +00:00
|
|
|
proxyConf["local_connect_timeout_ms"] = serviceConf.LocalConnectTimeoutMs
|
2022-09-12 14:41:58 +00:00
|
|
|
}
|
|
|
|
if serviceConf.LocalRequestTimeoutMs > 0 {
|
2022-09-26 16:29:06 +00:00
|
|
|
proxyConf["local_request_timeout_ms"] = serviceConf.LocalRequestTimeoutMs
|
|
|
|
}
|
|
|
|
// Add the proxy conf to the response if any fields were populated
|
|
|
|
if len(proxyConf) > 0 {
|
|
|
|
thisReply.ProxyConfig = proxyConf
|
2022-09-12 14:41:58 +00:00
|
|
|
}
|
|
|
|
|
2023-04-19 19:45:00 +00:00
|
|
|
if serviceConf.MutualTLSMode != structs.MutualTLSModeDefault {
|
|
|
|
thisReply.MutualTLSMode = serviceConf.MutualTLSMode
|
|
|
|
}
|
|
|
|
|
2022-09-01 14:45:07 +00:00
|
|
|
thisReply.Meta = serviceConf.Meta
|
2022-12-19 20:19:37 +00:00
|
|
|
// Service defaults' envoy extensions are appended to the proxy defaults extensions so that proxy defaults
|
|
|
|
// extensions are applied first.
|
|
|
|
thisReply.EnvoyExtensions = append(thisReply.EnvoyExtensions, serviceConf.EnvoyExtensions...)
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// First collect all upstreams into a set of seen upstreams.
|
|
|
|
// Upstreams can come from:
|
|
|
|
// - Explicitly from proxy registrations, and therefore as an argument to this RPC endpoint
|
|
|
|
// - Implicitly from centralized upstream config in service-defaults
|
2023-02-03 15:51:53 +00:00
|
|
|
seenUpstreams := map[structs.PeeredServiceName]struct{}{}
|
2022-09-01 14:45:07 +00:00
|
|
|
|
|
|
|
var (
|
2023-04-11 15:20:33 +00:00
|
|
|
noUpstreamArgs = len(args.UpstreamServiceNames) == 0
|
2022-09-01 14:45:07 +00:00
|
|
|
|
|
|
|
// Check the args and the resolved value. If it was exclusively set via a config entry, then args.Mode
|
|
|
|
// will never be transparent because the service config request does not use the resolved value.
|
|
|
|
tproxy = args.Mode == structs.ProxyModeTransparent || thisReply.Mode == structs.ProxyModeTransparent
|
|
|
|
)
|
|
|
|
|
|
|
|
// The upstreams passed as arguments to this endpoint are the upstreams explicitly defined in a proxy registration.
|
|
|
|
// If no upstreams were passed, then we should only return the resolved config if the proxy is in transparent mode.
|
|
|
|
// Otherwise we would return a resolved upstream config to a proxy with no configured upstreams.
|
|
|
|
if noUpstreamArgs && !tproxy {
|
|
|
|
return &thisReply, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// First store all upstreams that were provided in the request
|
2023-02-03 15:51:53 +00:00
|
|
|
for _, psn := range args.UpstreamServiceNames {
|
|
|
|
if _, ok := seenUpstreams[psn]; !ok {
|
|
|
|
seenUpstreams[psn] = struct{}{}
|
|
|
|
}
|
|
|
|
}
|
2022-09-01 14:45:07 +00:00
|
|
|
|
|
|
|
// Then store upstreams inferred from service-defaults and mapify the overrides.
|
|
|
|
var (
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
upstreamDefaults *structs.UpstreamConfig
|
2023-02-03 15:51:53 +00:00
|
|
|
upstreamOverrides = make(map[structs.PeeredServiceName]*structs.UpstreamConfig)
|
2022-09-01 14:45:07 +00:00
|
|
|
)
|
|
|
|
if serviceConf != nil && serviceConf.UpstreamConfig != nil {
|
|
|
|
for i, override := range serviceConf.UpstreamConfig.Overrides {
|
|
|
|
if override.Name == "" {
|
|
|
|
logger.Warn(
|
|
|
|
"Skipping UpstreamConfig.Overrides entry without a required name field",
|
|
|
|
"entryIndex", i,
|
|
|
|
"kind", serviceConf.GetKind(),
|
|
|
|
"name", serviceConf.GetName(),
|
|
|
|
"namespace", serviceConf.GetEnterpriseMeta().NamespaceOrEmpty(),
|
|
|
|
)
|
|
|
|
continue // skip this impossible condition
|
|
|
|
}
|
2023-02-03 15:51:53 +00:00
|
|
|
psn := override.PeeredServiceName()
|
|
|
|
seenUpstreams[psn] = struct{}{}
|
|
|
|
upstreamOverrides[psn] = override
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
if serviceConf.UpstreamConfig.Defaults != nil {
|
|
|
|
upstreamDefaults = serviceConf.UpstreamConfig.Defaults
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
if upstreamDefaults.MeshGateway.Mode == structs.MeshGatewayModeDefault {
|
|
|
|
upstreamDefaults.MeshGateway.Mode = thisReply.MeshGateway.Mode
|
|
|
|
}
|
2023-01-18 19:43:53 +00:00
|
|
|
upstreamDefaults.MergeInto(wildcardUpstreamDefaults)
|
|
|
|
// Always add the wildcard upstream if a service-defaults default-upstream was configured.
|
|
|
|
resolvedConfigs[wildcard] = wildcardUpstreamDefaults
|
|
|
|
}
|
|
|
|
}
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
|
2023-01-18 19:43:53 +00:00
|
|
|
if !args.MeshGateway.IsZero() {
|
|
|
|
wildcardUpstreamDefaults["mesh_gateway"] = args.MeshGateway
|
|
|
|
}
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
|
2023-01-18 19:43:53 +00:00
|
|
|
// Add the wildcard upstream if any fields were populated (it may have been already
|
|
|
|
// added if a service-defaults exists). We likely could always add it without issues,
|
|
|
|
// but this has been existing behavior, and many unit tests would break.
|
|
|
|
if len(wildcardUpstreamDefaults) > 0 {
|
|
|
|
resolvedConfigs[wildcard] = wildcardUpstreamDefaults
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for upstream := range seenUpstreams {
|
|
|
|
resolvedCfg := make(map[string]interface{})
|
|
|
|
|
|
|
|
// The protocol of an upstream is resolved in this order:
|
|
|
|
// 1. Default protocol from proxy-defaults (how all services should be addressed)
|
|
|
|
// 2. Protocol for upstream service defined in its service-defaults (how the upstream wants to be addressed)
|
|
|
|
// 3. Protocol defined for the upstream in the service-defaults.(upstream_config.defaults|upstream_config.overrides) of the downstream
|
|
|
|
// (how the downstream wants to address it)
|
2023-07-05 14:32:10 +00:00
|
|
|
if proxyConfGlobalProtocol != "" {
|
|
|
|
resolvedCfg["protocol"] = proxyConfGlobalProtocol
|
|
|
|
}
|
|
|
|
|
2023-01-20 17:25:51 +00:00
|
|
|
if err := mergo.MergeWithOverwrite(&resolvedCfg, wildcardUpstreamDefaults); err != nil {
|
|
|
|
return nil, fmt.Errorf("failed to merge wildcard defaults into upstream: %v", err)
|
|
|
|
}
|
2022-09-01 14:45:07 +00:00
|
|
|
|
2023-02-03 15:51:53 +00:00
|
|
|
upstreamSvcDefaults := entries.GetServiceDefaults(upstream.ServiceName.ToServiceID())
|
2022-09-01 14:45:07 +00:00
|
|
|
if upstreamSvcDefaults != nil {
|
|
|
|
if upstreamSvcDefaults.Protocol != "" {
|
2023-01-20 17:25:51 +00:00
|
|
|
resolvedCfg["protocol"] = upstreamSvcDefaults.Protocol
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
// When dialing an upstream, the goal is to flatten the mesh gateway mode in this order
|
|
|
|
// (larger number wins):
|
|
|
|
// 1. Value from the proxy-defaults
|
|
|
|
// 2. Value from top-level of service-defaults (ServiceDefaults.MeshGateway)
|
|
|
|
// 3. Value from centralized upstream defaults (ServiceDefaults.UpstreamConfig.Defaults)
|
|
|
|
// 4. Value from local proxy registration (NodeService.Proxy.MeshGateway)
|
|
|
|
// 5. Value from centralized upstream override (ServiceDefaults.UpstreamConfig.Overrides)
|
|
|
|
// 6. Value from local upstream definition (NodeService.Proxy.Upstreams[].MeshGateway)
|
|
|
|
//
|
|
|
|
// The MeshGateway value from upstream definitions in the proxy registration override
|
|
|
|
// the one from UpstreamConfig.Defaults and UpstreamConfig.Overrides because they are
|
|
|
|
// specific to the proxy instance.
|
|
|
|
//
|
|
|
|
// Step 6 is handled by the dialer's ServiceManager in MergeServiceConfig.
|
|
|
|
|
|
|
|
// Start with the merged value from proxyConf and serviceConf. (steps 1-2)
|
|
|
|
if !thisReply.MeshGateway.IsZero() {
|
|
|
|
resolvedCfg["mesh_gateway"] = thisReply.MeshGateway
|
|
|
|
}
|
|
|
|
|
|
|
|
// Merge in the upstream defaults (step 3).
|
2022-09-01 14:45:07 +00:00
|
|
|
if upstreamDefaults != nil {
|
|
|
|
upstreamDefaults.MergeInto(resolvedCfg)
|
|
|
|
}
|
|
|
|
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
// Merge in the top-level mode from the proxy instance (step 4).
|
2022-09-01 14:45:07 +00:00
|
|
|
if !args.MeshGateway.IsZero() {
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
// This means each upstream inherits the value from the `NodeService.Proxy.MeshGateway` field.
|
2022-09-01 14:45:07 +00:00
|
|
|
resolvedCfg["mesh_gateway"] = args.MeshGateway
|
|
|
|
}
|
|
|
|
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
// Merge in Overrides for the upstream (step 5).
|
|
|
|
if upstreamOverrides[upstream] != nil {
|
|
|
|
upstreamOverrides[upstream].MergeInto(resolvedCfg)
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if len(resolvedCfg) > 0 {
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
resolvedConfigs[upstream] = resolvedCfg
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// don't allocate the slices just to not fill them
|
Fix mesh gateway configuration with proxy-defaults (#15186)
* Fix mesh gateway proxy-defaults not affecting upstreams.
* Clarify distinction with upstream settings
Top-level mesh gateway mode in proxy-defaults and service-defaults gets
merged into NodeService.Proxy.MeshGateway, and only gets merged with
the mode attached to an an upstream in proxycfg/xds.
* Fix mgw mode usage for peered upstreams
There were a couple issues with how mgw mode was being handled for
peered upstreams.
For starters, mesh gateway mode from proxy-defaults
and the top-level of service-defaults gets stored in
NodeService.Proxy.MeshGateway, but the upstream watch for peered data
was only considering the mesh gateway config attached in
NodeService.Proxy.Upstreams[i]. This means that applying a mesh gateway
mode via global proxy-defaults or service-defaults on the downstream
would not have an effect.
Separately, transparent proxy watches for peered upstreams didn't
consider mesh gateway mode at all.
This commit addresses the first issue by ensuring that we overlay the
upstream config for peered upstreams as we do for non-peered. The second
issue is addressed by re-using setupWatchesForPeeredUpstream when
handling transparent proxy updates.
Note that for transparent proxies we do not yet support mesh gateway
mode per upstream, so the NodeService.Proxy.MeshGateway mode is used.
* Fix upstream mesh gateway mode handling in xds
This commit ensures that when determining the mesh gateway mode for
peered upstreams we consider the NodeService.Proxy.MeshGateway config as
a baseline.
In absense of this change, setting a mesh gateway mode via
proxy-defaults or the top-level of service-defaults will not have an
effect for peered upstreams.
* Merge service/proxy defaults in cfg resolver
Previously the mesh gateway mode for connect proxies would be
merged at three points:
1. On servers, in ComputeResolvedServiceConfig.
2. On clients, in MergeServiceConfig.
3. On clients, in proxycfg/xds.
The first merge returns a ServiceConfigResponse where there is a
top-level MeshGateway config from proxy/service-defaults, along with
per-upstream config.
The second merge combines per-upstream config specified at the service
instance with per-upstream config specified centrally.
The third merge combines the NodeService.Proxy.MeshGateway
config containing proxy/service-defaults data with the per-upstream
mode. This third merge is easy to miss, which led to peered upstreams
not considering the mesh gateway mode from proxy-defaults.
This commit removes the third merge, and ensures that all mesh gateway
config is available at the upstream. This way proxycfg/xds do not need
to do additional overlays.
* Ensure that proxy-defaults is considered in wc
Upstream defaults become a synthetic Upstream definition under a
wildcard key "*". Now that proxycfg/xds expect Upstream definitions to
have the final MeshGateway values, this commit ensures that values from
proxy-defaults/service-defaults are the default for this synthetic
upstream.
* Add changelog.
Co-authored-by: freddygv <freddy@hashicorp.com>
2022-11-09 16:14:29 +00:00
|
|
|
if len(resolvedConfigs) == 0 {
|
2022-09-01 14:45:07 +00:00
|
|
|
return &thisReply, nil
|
|
|
|
}
|
|
|
|
|
2023-04-11 15:20:33 +00:00
|
|
|
thisReply.UpstreamConfigs = make(structs.OpaqueUpstreamConfigs, 0, len(resolvedConfigs))
|
2022-09-01 14:45:07 +00:00
|
|
|
|
2023-04-11 15:20:33 +00:00
|
|
|
for us, conf := range resolvedConfigs {
|
|
|
|
thisReply.UpstreamConfigs = append(thisReply.UpstreamConfigs,
|
|
|
|
structs.OpaqueUpstreamConfig{Upstream: us, Config: conf})
|
2022-09-01 14:45:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return &thisReply, nil
|
|
|
|
}
|