This change updates Envoy to consider the load balancing configuration
set in load_balancing_policy, regardless of what is set in lb_policy.
Previously the load_balancing_policy field was only considered if lb_policy
was set to LOAD_BALANCING_POLICY_CONFIG.
Going forward the approach is to only use the load_balancing_policy field
and the extensible configuration mechanism it provides to configure
all load balancing policies, which makes lb_policy deprecated.
This change still preserves backward compatibility, allowing old clients
to continue using the lb_policy field and new ones to switch to just
considering load_balancing_policy.
Commit Message: Prefer the load_balancing_policy cluster field over lb_policy
Additional Description: This change updates Envoy to consider the load
balancing configuration set in load_balancing_policy, regardless of what
is set in lb_policy.
Risk Level: Low
Testing: New unit tests for upstream_impl.cc
Docs Changes: Documentation to follow once consensus on this
change is reached.
Release Notes: Not currently user impacting as backward compatibility
is maintained.
Platform Specific Features: None.
Signed-off-by: Terry Wilson <tmwilson@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ bc641dbb9157460b346fa0d3ef387f05e5ce9881
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
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 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
Adding a deprecated API version annotation to deprecated fields and enum values in proto files.
This is part of the work on adding minor/patch versioning work.
Risk Level: Low (adding annotation to existing protos).
Testing: Added and modified tests for the tooling (in tools/testdata).
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5a8bfa20dc3c85ecb61826d122696ecaa75dffa0
* Re-purpose alt_stat_name for other observability use-cases: access logging, tracing, and admin dumps through a new ClusterInfo field, `observabilityName()`.
Signed-off-by: Asra Ali <asraa@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5551e0a3e442cca24d76eeea76e8b9dc5f894303
Changed logic in config verification when max_ejection_time is not specified
and base_ejection_time is larger than max_ejection_time's default.
Signed-off-by: Christoph Pakulski <christoph@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 12df7d09222af273828ed114e5254caeba65d658
Add information about known extension categories (types) to extension documentation
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 7adc0393221467fcae18052c1f7caf0cb6048d2e
Fixing "warning: Import ... but not used" warnings from protoc
Risk Level: Low
Testing: manually built protos
Signed-off-by: Chris Heisterkamp <cheister@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 209b8f96498162834856a4330f27deafdf7e0518
* Send x-envoy-immediate-health-check-fail on all responses that the
health check filter processes, not just non-HC responses.
* Exclude hosts from load balancing when x-envoy-immediate-health-check-fail
is received.
* Can be reverted via the envoy.reloadable_features.health_check.immediate_failure_exclude_from_cluster
feature flag.
Fixes https://github.com/envoyproxy/envoy/issues/9246
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ deed328494064bf28e09055c1cda4e3a3cdd6b67
As per discussion summarized in
#13555 (comment), we will not use structured
xdstp:// names/locators in the API initially. Instead, we will re-use existing string fields for
names and special case any name with a xdstp: prefix. We leave open the option of introducing
structured representation, in particular for efficiency wins, at a later point.
Risk level: Low (not in use yet)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d1ded6b381ca92cbacb2e0683adf997239b12272
Replacing the http-protocol-specific fields in the cluster config with a new plugin
Risk Level: medium
Testing: updated tests to use the new config
Docs Changes: updated docs to use the new config
Release Notes: deprecation notes in the PR
Deprecated: all http-specific cluster config.
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 7554d61bccf136638bdfb383c10d049dc8bd3790
As per the decision to move the cncf/udpa repository to cncf/xds branding.
Also updated cncf/udpa hash and updated identifier handling (moved from repeated to a flat string).
Risk level: Low (the only breaking API changes affect not-implemented-hide fields).
Testing: New unit tests for path components.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8c4a3c77a7de016a118aacc4cea933951b85e589
This is a follow up to 2c60632.
This forces all callers to think about multiple header values. There may be places that we want
to support multiple values, but none of them are security critical and this change should be
functionally equivalent to what exists today.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4d77fc802c3bc1c517e66c54e9c9507ed7ae8d9b
Risk Level: LOW
Testing: Unit and format
Fixes#10535
Signed-off-by: Abhay Narayan Katare <abhay.katare@india.nec.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6321e5d95f7e435625d762ea82316b7a9f7071a4
This does predictive (peekahead) prefetch for WRR, RR, and Random schedulers, and plumbing it up to the connection manager, which will currently only use it to prefetch 1 connection (see TODO for follow-up plans)
Risk Level: Medium (refactors LBs somewhat - should be no-op)
Testing: new unit tests
Docs Changes: n/a
Release Notes: n/a
Part of #2755
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 5875f23b60aeeb49e038596d8de36446c6728f5d
Currently, the maglev hash algorithm default to table size to 65537.
It is the recommended size by a paper but it is better if the user
can set this value.
This patch introduces a new MaglevLbConfig that contains table
size of maglev.
So, now, the user can set the table size of maglev by their situation.
Signed-off-by: DongRyeol Cha <dr83.cha@samsung.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5fd73ca889aa12618c626c96bb33fde4707f8bf0
This can be used in similar situations to maglev/ring, but can be used when the host selection must remain the same for existing sessions even if more hosts are added to the cluster.
In a test with 1500 endpoints, updating 50 (remove 50, add 50 different ones) took:
without new setting: ~500ms
with new setting (this PR): ~4ms
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 724df08c329c8270509e2a8568be90fd43d597c1
This is as described in the paper https://arxiv.org/abs/1608.01350; Logic followed is similar to what's in haproxy.
Signed-off-by: Santosh Cheler <santosh.cheler@appdynamics.com>
Mirrored from https://github.com/envoyproxy/envoy @ 760a164640acf75a8009ac89b5ff06f78a733221
Add connect_pool_per_downstream_connection flag to the cluster config (disabled by default)
Add a hashKey method to Connection in order to be able to hash on the connection ID
Signed-off-by: Craig Radcliffe <craig.radcliffe@broadcom.com>
Mirrored from https://github.com/envoyproxy/envoy @ 76a1b24dd511bb5b3a38da3e84c9003ccadc64ce
Implementing per-upstream prefetching, useful for high QPS or latency-sensitive services.
Risk Level: low (off by default)
Testing: new unit tests, integration test
Docs Changes: n/a
Release Notes: not yet
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ f6e90f2966887b25a8b6d5dd7f13ffb32865d66b
Created a new struct for optional cluster stats. Moved timeout budget stats and added request response headers and body stats in the new struct.
Risk Level: Low
Testing: Added test cases
Docs Changes: added
Release Notes: added
Fixes#10308 , Fixes#3621
Signed-off-by: Ranjith Kumar <ranjith.dakshana2015@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ a24c95e4fe035ae5d05691ee2b2bd7011093a9e9
* Add support for making Least Requests LB behave like Round Robin in weighted hosts case
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Perf/logging improvements
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback and cleanup BUILD file
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Make active requests exponent configurable via CDS/runtime
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Validate log message
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Update cluster memory test golden values
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Fix method name
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Explicitly initialize active_request_bias_
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Try to make clang-tidy happy
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Use unique_ptr instead of optional
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Update stats integration test
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Check whether memory footprint is reduced without LB changes
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Use plain double for active request bias
Use a plain double instead of a runtime double to store the per-cluster
active request bias.
Note: The goal of this commit is to evaluate the memory overhead of this
approach. A commit with te Least Requests LB changes might follow if we
deem the memory overhead of this approach acceptable.
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Revert back to approved implementation using RuntimeDouble
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Add extra fields to CDS cluster proto to check memory usage
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Revert "Add extra fields to CDS cluster proto to check memory usage"
This reverts commit a6a285dcee9e0fe618286d3dfbfab98c957dd9c7.
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Add changelog entry
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9f7d44850310999ecbd0cfbe8fadb70db6f258f9
These are currently set as [#not-implemented-hide:]. There should be enough plumbing here to start
implementing the first roadmap steps in #11264, i.e. some simple delta discovery flows with core
LDS/CDS/RDS/EDS/SDS.
I've punted on VHDS and SRDS until later, as these will require special case mapping of their
resource keys into context parameters.
Risk level: Low (Unused API changes).
Testing: Built docs and proto_format.sh.
Part of #11264.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 99471fd8f4ef7406f50cf41cf1cfa22bbdfeacc7
Mainly moving code, but finishes up the series of pluggable upstream PRs.
Additional Description: This unhides the configurable extension point to the cluster for selecting a connection pool and creating an upstream, which can be used for custom business logic in upstream creation.
Risk Level: medium (router refactor)
Testing: with prior PRs
Docs Changes: inline with APIs
Release Notes: added
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 8a9d6155601846d2d256defd09a3c408c6eb4386
split out from #11327
There's a bit of transitive ugliness: declaring the extensions requires security posture, requires stub build files, requires codeowners before the code move, but it'll be pretty short lived.
Risk Level: Low (mostly only APIs)
Testing: n/a
Docs Changes: some of the new docs
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ e8dc25ecec277c0b94d02151de79353a9ba07b4e
data-plane-api(Azure Pipelines)