- 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
This also fixes a bug with existing keepalive, where if the interval were larger than the idle timeout, it would send new pings and never time out.
Risk Level: medium (data plane change, changes existing ping logic)
Testing: unit tests
Docs Changes: n/a
Release Notes:
Fixes#16313
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 79343be05c9528462b51af10b49d5fffe6e173e5
Commit Message: make quic proof source and crypto streams extensions. Add config for default ones. If not specified in config, the default ones will be used.
Risk Level: low
Testing: existing tests passed
Part of #2557
Co-authored-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ beb5a93b08bd0c48a2a7dd2f40ca13bcdb0ed40e
The HTTP Gzip filter has been disabled in v1.17 by default. Now we can remove it completely. Also the code common for the gzip filter and for the generic compressor filter is moved to source/extensions/filters/http/compressor.
Risk Level: Low
Testing: unit tests
Docs Changes: removed the page about the Gzip filter
Release Notes: added a note about the removal to current.rst
Signed-off-by: Dmitry Rozhkov <dmitry.rozhkov@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ dc2cddeef3ef06febe4c8f9f40b3dd98e1b273bc
Currently, envoy ignores the value of present match. This commit adjust
envoy's behavior. When the value is True, envoy will check the header
present. When the value is False, envoy will check the header absent.
Signed-off-by: He Jie Xu <hejie.xu@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9a7a7ede474780c2bd8fe59e7a93e537204cfe31
Commit Message: To prevent long event loop when too many UDP packets are in the queue, limit how many packets to read in each event loop. If haven't finished reading, artifacts a READ event to continue in the next event loop.
Additional Description:
Add numPacketsExpectedPerEventLoop() callback to UdpListenerCallback, so that QUIC listener can tell how many packets it wants to read in each loop. The actually number of packets read are still bound by MAX_NUM_PACKETS_PER_EVENT_LOOP (6000).
Quic listener returns numPacketsExpectedPerEventLoop() based on number of connections it has at the moment and the configured envoy::config::listener::QuicProtocolOptions.packets_to_read_to_connection_count_ratio.
Made InjectableSingleton really thread safe.
Risk Level: medium, other than quic listener, other UdpListenerCallbacks return max size_t for numPacketsExpectedPerEventLoop(). This will cause those callbacks to read 6000 packets per READ event.
Testing: added udp listener unit tests.
Fixes#16335#16278
Part of #16198#16493
Signed-off-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8db01a4a7ab41268d28c323a0f3f80efae8af977
Marks the matching API more clearly as experimental and updates the composite filter security posture to reflect this.
Signed-off-by: Snow Pettersen <snowp@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ b6039234e526eeccdf332a7eb041729aaa1bc286
grid: Plumb the AlternateProtocolCache down to the grid from the UpstreamClusterManager.
Create a new AlternateProtocolsCacheOptions proto message for configuring an AlternateProtocolCache, and add this message to AutoHttpConfig.
Create a new AlternateProtocolCacheManager class for fetching/creating a Cache based on the config.
Modify the AlternateProtocolCache to store state per thread. (Does not yet synchronize this state across threads)
Risk Level: Low
Testing: Unit tests
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
Signed-off-by: Ryan Hamilton <rch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 964de6c2a166bb7f66a9293a2e2e8cb6040dfbf2
Allow http route and cluster metadata to contain typed metadata in Any in addition to Struct format
#13986.
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 178c0886ff5e4f61067843080260de590c522e64
This fixes the refs in protos and removes the sed operations for build
The benefits are:
- less indirection in proto refs
- (small) speedup of build
- simplify docs build
- simplify reuse of proto comments (eg generating jsonschemas)
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45ec050f91407147ed53a999434b09ef77590177
This allows self-contained bootstrap without extra token files.
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ a5020ce885592e8e3a5d9bb644554a30c0f79a18
Commit Message: Add initial stream and connection level flow control windows to envoy.config.core.v3.QuicProtocolOptions which is be used in QUIC listener config and Http3 upstream cluster config.
Risk Level: low
Testing: re-enable more Http3 downstream protocol test.
Part of #2557#12930#14829
Signed-off-by: Dan Zhang <danzh@google.com>
Co-authored-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fe62d976a26faa46efc590a48a734f11ee6545f9
If listener1 redirects the connection to listener2, the balancer field in listener2 decides whether to rebalance.
Previously we rely on the rebalancing at listener1, however, the rebalance is weak because listener1 is likely to
not own any connection and the rebalance is no-op.
Risk Level: MID. Rebalance may introduce latency. User needs to clear rebalancer field of listener2 to recover the original behavior.
Fix#15146#16113
Signed-off-by: Yuchen Dai <silentdai@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3e9678019e4d6244d9d066f1e6c8336360281f77
data-plane-api(Azure Pipelines)