Support an inline RouteConfiguration in ScopedRouteConfiguration.
This change enables fully inlined scoped route configuration by
allowing users to specify an inline `RouteConfiguration` in the scope's
config, as opposed to requiring a `route_configuration_name` to use for
an RDS subscription.
Signed-off-by: Andres Guedez <aguedez@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ cbc05d480cc24fc96bbbbd476cc31b25402d6777
Commit Message: upstream: support max connection duration for upstream connections
Risk Level: low, isolated opt-in feature
Testing: new unit tests
Docs Changes: updated protobuf definition to no longer mention that max lifetime is not implemented for upstream connections
Release Notes: upstream: support max connection duration for upstream connections
Platform Specific Features:
Fixes#15107
Signed-off-by: John Esmet <john.esmet@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9a4a861a6b22959205fb70454bcdf238e3ebd4f9
Adds support for using the matching API in the route table. This wires up using the generic match as part of a virtual host, making it possible to define a match tree that results in Route actions that reuses the same routing actions currently in use by the router.
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 94d00135bd9f0f7701c89c7a9220691e51068aec
This PR currently only implements query string modifications when using a gRPC authorization server.
Signed-off-by: John Esmet <john.esmet@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c42a018d332920f3e523f1a0409b6056bd805853
Adds a new API field for http health checks that allows specifying ranges of status codes that are considered retriable. If these status codes are received, those failures will contribute towards the configured unhealthy threshold rather that immediately considering the cluster member unhealthy as is the case today.
Signed-off-by: Weston Carlson <wez470@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 42f9fc3b000fbc01fa5d500cc071f477bebaa638
To fix: #13965
grpc_json envoy filter adds a new field 'query_param_unescape_plus` to enable the support of converting "+" to space in query parameters.
The actual unescape code is implemented in grpc-httpjson-transcoding.
Risk Level: None
Testing: integration tests
Docs Changes: None
Release Notes: Yes
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1ba355b5e9f00cda595d5b52e3390d473fa5ecce
Based on the dicsussion in the issue https://github.com/envoyproxy/envoy/issues/17410, this PR adds
implementation for ability to add rbac policy to filter upstream ip addresses for dynamically
resolved domains (by dynamic proxy filter).
Signed-off-by: Jojy George Varghese <jojy_varghese@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 53f95570a7e9d7fa5414a4bc145852524fa017ed
This is a first step towards https://github.com/envoyproxy/envoy/issues/17920
A single proto (kafka mesh) has been swapped from using the udpa
file_status annotation to the xds file_status annotation to avoid a
large amount of churn and a forthcoming migration of many alpha/wip
protos to non alpha/wip. The rest will be audited and swapped in
future PRs. This single one was done to make sure the doc machinary
works properly.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ f0f17a3caa75106a9e28b99edc27dd09c1bed488
This PR adds some more description around max_connection_duration in the Timeout FAQs.
Commit Message: add more description for max_connection_duration in timeout faqs.
Additional Description: -
Risk Level: N/A
Testing: N/A
Docs Changes: Added some more description around max_connection_duration in the Timeout FAQs.
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2e8efdefef86f7749aee3ca30d0752218a07ca8a
Risk Level: low
Testing: new unit tests. integration test TODO in a follow up
Docs Changes: n/a
Release Notes: will land with integration test.
Fixes#18034
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 7f63632be6b08193550041c4069e63f557b16c5d
This was built for Envoy Mobile, but will allow generic modification
of router behavior between retries. Currently it only supports modifying
upstream socket options (to in practice impact interface binding), but
in the future is likely to be extended to modify timeouts, retry back
off times, request headers, etc.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5b1015cffbf6e02a7ccec9c12a6b7f246f8f3d30
Allows ensuring continual progress of individual request attempts.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ b500a0a655809f518ed30a05ceb7262a02dbc537
Adds a new optional param called override_auto_sni_header which can be used to populate the upstream SNI value from an arbitrary header other than Host/Authority.
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5c146696351be2bac731abd501333fbac824d919
This includes validation for upgrade connects per Ryan's offline advice.
n.b. this should be a no-op for HTTP (where there is no mechanism to send both) and HTTP/2 (where nghttp2 validates) so not currently calling out in release notes.
Risk Level: low
Testing: new integration tests
Docs Changes: inline
Release Notes: n/a (quic alpha)
co-author: @DavidSchinazi
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 2d934e1e618714bab0ae7f2dcfd6a0531212dd6c
- Removed the JsonV1Serializer and added exception for HTTP_JSON_V1version in Serializer creation.
- Specified collector_endpoint_version in the test
- Removed the default value for endpoint_, it is redundant here because in the zipkin.proto, it has PGV rule [(validate.rules).string = {min_len: 1}], so we always need to provide the config for this field.
- Modified the ConstructBuffer test to create the buffer using ZipkinConfig::HTTP_JSON
Risk Level: LOW
Testing: CI
Signed-off-by: Tianyu Xia <tyxia@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ db74e313b3651588e59c671af45077714ac32cef
- Add cluster header to weighted cluster proto. This enables the ability of routing to the cluster specified in the request_header for weighted cluster (i.e. multiple upstreams) case. name and cluster_header will be oneof cluster_specifiter field in the next release. Currently, they can only be regular fields due to compatibility issue.
- Add the validation logic (PGV annotation + runtime check)
- Add 3 unit tests for invalid weighted cluster configs.
Note: I have implemented the core implementation and tested it with end-to-end
integration test/example locally. Those changes will be in a separate PR once this API change is approved.
Risk Level: Low
Testing: CI, added an integration test for implementation of this API locally
Signed-off-by: Tianyu Xia <tyxia@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ef70185f3ac241d09eabfe15c65b0d631134f74f
Stop generating v4alpha protos as it won't land in foreseeable future.
This fixes go-control-plane sync because of it fails to generate contrib API correctly.
Risk Level: Medium
Testing: CI
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ e453c6c613206da749e3ff645e2d92f534535f3e
Enables `LOAD_BALANCING_POLICY_CONFIG` enum value in `LbPolicy` and supports typed load balancers specified in `load_balancing_policy`. Continues work done by Charlie Getzen <charliegetzenlc@gmail.com> in #15827.
Custom load balancers specified by `load_balancing_policy` are created as implementations of `ThreadAwareLoadBalancer`. Thread-local load balancers can be implemented as thread-aware load balancers that contain no logic at the thread-aware level, i.e. the purpose of the thread-aware LB is solely to contain the factory used to instantiate the thread-local LBs. (In the future it might be appropriate to provide a construct that abstracts away thread-aware aspects of `ThreadAwareLoadBalancer` for LBs that don't need to be thread-aware.)
A cluster that uses `LOAD_BALANCING_POLICY_CONFIG` may not also set a subset LB configuration. If the load balancer type makes use of subsetting, it should include a subset configuration in its own configuration message. Future work on load balancing extensions should include moving the subset LB to use load balancing extensions.
Similarly, a cluster that uses `LOAD_BALANCING_POLICY_CONFIG` may not set the `CommonLbConfig`, and it is not passed into load balancer creation (mostly owing to its dubious applicability as a top level configuration message to hierarchical load balancing policy). If the load balancer type makes use of the `CommonLbConfig`, it should include a `CommonLbConfig` in the configuration message for the load balancing policy.
Considerations for migration of existing load balancers:
- pieces of the `ThreadAwareLoadBalancerBase` implementation are specific to the built-in hashing load balancers and should be moved into a base class specifically for hashing load balancers. As it stands, custom load balancing policies are required to implement a `createLoadBalancer()` method even if the architecture of the LB policy does not require a hashing load balancer. I think we would also benefit from disentangling `ThreadAwareLoadBalancerBase` from `LoadBalancerBase`, as the former never actually does any host picking.
- as we convert existing thread-local load balancers to thread-aware load balancers, new local LBs will be re-created upon membership changes. We should provide a mechanism allowing load balancers to control whether this rebuild should occur, e.g. a callback that calls `create()` for thread-aware LBs by default, which can be overridden to do nothing for thread-local LBs.
Risk Level: low
Testing: brought up a cluster with a custom load balancer specified by `load_balancing_policy`; new unit tests included
Docs Changes: n/a
Release Notes: Enable load balancing policy extensions
Platform Specific Features: n/a
Fixes#5598
Signed-off-by: Eugene Chan <eugenechan@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e31bc1edec3bb80760a1442869cc442d123e9adc
use one destination port range rule to cover thousands of port rules in RBAC permissions, adding convenience for writing configuration and making matching quicker
Risk Level: Low
Testing: Unit
Docs Changes: N/A
Release Notes: Added
Platform Specific Features: N/A
Fixes#16039
Signed-off-by: Xie Zhihao <zhihao.xie@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0d2418e9f19d50197ed237dfe5497c715d3c99f0
Replace the confusing word with official defination
Signed-off-by: Le Yao <le.yao@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3a4baf64a5c300739b7ce47128c1e62fd2a38f33
#17110 the EnvoyMobileHttpConnectionManager but it turns out it's instantiated either as a standard network filter (needs a name) or as an API listener (which only accepted HttpConnectionManager)
Fixing both issues.
Risk Level: low
Testing: unit tests
Docs Changes: n/a
Release Notes: n/a
Part of envoyproxy/envoy-mobile#1540
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 463eda2f3895fbb24c1fcd085a15d00d12a94079
1) Deprecate existing reuse_port field
2) Add new enable_reuse_port field which uses a WKT
3) Make the new default hot restart aware so the default is
not changed during hot restart.
4) Allow the default to be reverted using the
"envoy.reloadable_features.listener_reuse_port_default_enabled"
feature flag.
5) Change listener init so that almost all error handling occurs on
the main thread. This a) vastly simplifies error handling and
b) makes it so that we pre-create all sockets on the main thread
and can use them all during hot restart.
6) Change hot restart to pass reuse port sockets by socket/worker
index. This works around a race condition in which a draining
listener has a new connection on its accept queue, but it's
never accepted by the old process worker. It will be dropped.
By passing all sockets (even reuse port sockets) we make sure
the accept queue is fully processed.
Fixes https://github.com/envoyproxy/envoy/issues/15794
Risk Level: High, scary stuff involving hot restart and listener init
Testing: New and existing tests. It was very hard to get the tests to pass which gives me more confidence.
Docs Changes: N/A
Release Notes: Added
Platform Specific Features: N/A
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ ba474ac375418d5529a30a9510a8ff5f0a5ada9a
Adding a core.v3.TypedExtensionConfig typed_dns_resolver_config for DNS resolver
in API definition. This configuration is to support DNS resolution as a first
class Envoy extension. This API change is the first step for that task.
This configuration is to replace above dns_resolution_config.
By default envoy supports c-ares DNS or apple DNS resolvers. This extension can be used
to configure other DNS resolver types.
This configuration is optional. In case it is missing, the default behavior is in place,
which means Envoy will either use c-ares DNS library or apple DNS library based on
the compiling flag. When this configuration is in place, Envoy will use the configured
DNS resolver carried in the extension typed_config field.
In case both typed_dns_resolver_config and dns_resolution_config are configured,
typed_dns_resolver_config take precedence.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b65b397652e5a627a9f3b0adcfe840d80dd57c03
Commit Message: upstream -- allow clusters to skip waiting on warmup for initialization
Additional Description: this reduces server startup time, but might cause initial 500s for requests made on unresolved clusters. Further work might be needed there if operators use this new config option.
Risk Level: low - new config option. Default uses legacy behavior.
Testing: added unit tests
Docs Changes: added.
Release Notes: updated
Signed-off-by: Jose Nino <jnino@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ f2906f5ce372814b8e6f688a0e1766703d8b56f2
This is a new extension point that will allow for dynamic cluster selection.
The plugin configured by it will be responsible for returning a cluster to
Envoy through its API (to be defined). Since the cluster returned is dynamic,
a new field is added to Route to list all the clusters it may return. This
allows for proxy implementations that are not using wildcard CDS queries to
pre-fetch clusters.
This feature may ultimately replace the FilterAction mechanism, as it provides
the same functionality for known use cases, but is simpler to implement and
use.
Signed-off-by: Doug Fawley <dfawley@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6dc4092fc161b8fcb5f25a972e4783116692d53c
data-plane-api(Azure Pipelines)