add support for warm on init flag for redis cluster
Signed-off-by: Rama Chavali <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ bb546b0e65932a47d160b0b6e676f43381d6aa00
If present, force http-parser (if value is false) or BalsaParser (if value is true). If not present, parser is selected based on envoy.reloadable_features.http1_use_balsa_parser.
Tracking issue: #21245
Signed-off-by: Bence Béky bnc@google.com
Commit Message: [balsa] Add Http1ProtocolOptions field to override HTTP/1 parser.
Additional Description:
Risk Level: low
Testing: n/a
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: n/a
Signed-off-by: Bence Béky <bnc@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 80530fd0a32e242327c684cfe262d88e0f5eacbb
This reverts commit 1f4f60003ea4331e71d661a536e6c4dcdf23f8db.
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 27cab5153d080bce2715395325da43267e04a009
This commit marks the `grpc_service` of the opentelemtry configuration as optional and if the resulting field is empty, the plugin will abstain from sending the trace data to any collection service.
This means that the opentelemetry plugin will still generate and propagate trace headers, but they will no longer be sent to the collector.
Signed-off-by: Ashish Banerjee <ashish.banerjee@solo.io>
Mirrored from https://github.com/envoyproxy/envoy @ c424ab9b0165357b715866ee2906cf3fc717e4e8
This pulls the validation listener manager code into an extension, such that there's no hard-coded dependency on the TCP listener code. It should be a no-op for Envoy and a slight memory improvement for Envoy Mobile which does not support or use validation mode.
Risk Level: low
Testing: n/a
Docs Changes: n/a
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ ec9099786796da6f834a6d562d0c3939c342a5e1
Adding envoy.reloadable_features.use_api_listener to control if the regular listener manager or the api listener manager is used. note this does not use the usual reloadable or restart flags mechanism (due to it not being loaded at the time) but instead checks for the string literal in bootstrap YAML.
Risk Level: low
Testing: new integration test
Docs Changes: n/a
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ a9d852b50511c1ff59a96815a38811f9853b00ed
Adds additional validation that the sum of weights of weighted clusters in a route does not exceed max uint32.
Risk Level: low - although this is a new validation, previously there was a similar validation when total_weight was used.
Testing: Added unit test
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0a2f59240b4b005be0a9a5824c5e6c1604028d86
Signed-off-by: Thomas van Noort thomas.vannoort@datadoghq.com
Commit Message: ratelimit: allow metadata descriptors to be skipped
Risk Level: low
Testing: added unit tests
Docs Changes: per the protobuf definitions
Release Notes: N/A
Platform Specific Features: N/A
Additional Description:
The default behaviour was to skip calling the rate limiting service whenever the metadata key was not found and the default value was not set. This was not correctly documented (nor tested) since it mentioned that only the descriptor was skipped whereas the rate limiting service was skipped altogether.
This adds a skip_if_absent field in the same spirit as for the request headers action: if set to true it skips the descriptor but still calls the rate limiting service, otherwise it skips the rate limiting service.
Note that the deprecated dynamic metadata action does not support this field and defaults to false.
Mirrored from https://github.com/envoyproxy/envoy @ 40fb636fb3ba7d502625614ed613d4e97e140b3e
This allows setting socket options without specifying an address to
bind for upstream connections.
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7010984aeffe27aea0e6cbf452ef7c20139c6a43
This PR is going to add an optional flag in the Endpoint.HealthCheckConfig to disable or enable active health check for it. E.g. Envoy will only use the health status from EDS for a subset of endpoints. This can support mixed/hybrid network groups.
Note, it will impact all type of clusters if health checker is configured, e.g. EDS, strict_dns.
However, we skip the endpoint with disable flag at message level for HDS.
Risk Level: Medium
Testing: unit and integration tests
Signed-off-by: Boteng Yao <boteng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ fcfb1cd1d68f47d0fcacea693d76e1866ca2fde0
Signed-off-by: Kuat Yessenov kuat@google.com
Commit Message: Add another option to read principal from the filter state instead of metadata. The use case is passing the value from a network filter to an HTTP filter (RBAC), and the dynamic metadata does not support inheritance. For tunneled requests, the principal needs to be set at the tunnel connection, not the internal connection used for HTTP processing.
Risk Level: low
Testing: unit
Docs Changes: none
Release Notes: none
Mirrored from https://github.com/envoyproxy/envoy @ 91eccaf7d75161676e90adae58722c4bfa7d0c2e
Any Envoy users who customize their pre-built extensions will need to evaluate if they need this cluster.
Risk Level: medium
Testing: n/a
Docs Changes: n/a
Release Notes: inline
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 1d60a116413a0422b2df50e5f6ef8b553caba53b
remove an extra dot in docs
Signed-off-by: Peter Jausovec <peter.jausovec@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 82667905a934826576e817a8222b0e1117b79b15
make QUIC connection ID generation an extension point with currently in-use EnvoyDeterministicConnectionIdGenerator as the default implementation.
Additional Description: fix some previously unused QUICHE build targets.
Risk Level: low, control plane change
Testing: added new unit tests
Docs Changes: docs/root/api-v3/config/quic/quic_extensions.rst
Release Notes: N/A
API Considerations: interface naming and documentation
Signed-off-by: Dan Zhang <danzh@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 02ebc03205cfae5b26ce890050b9d1b6e0c2d1f5
Since the ipv4 and ipv6 have different socket option flags, when using multiple addresses, the user has to specify different socket options for the ipv4 address and the ipv6 address.
For the listener, the additional address can be the Ipv6 address, then it should be able to set an Ipv6 flag corresponding to the ipv4 one. Add socket_option field for each additional address.
For the upstream, the endpoint can be ipv4 or ipv6, currently, the user can specify the ipv4 and ipv6 local bind address in the bind config, but there is only a global socket_options that apply to both the ipv4 and ipv6 addresses. Add socket_options for each extra source address. https://envoyproxy.slack.com/archives/C78HA81DH/p1664228598624269
Risk Level: low
Testing: n/a
Docs Changes: API doc
Release Notes: n/a
Platform Specific Features: n/a
Signed-off-by: He Jie Xu <hejie.xu@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ 601cf012144a6d212879b315efa51e9cdf177878
Risk Level: low
Testing: n/a
Signed-off-by: He Jie Xu <hejie.xu@intel.com>
Mirrored from https://github.com/envoyproxy/envoy @ b1208ec4fd311d86086a99fb5f9f76d16af3a9ee
Add a "canonical suffix" list to the Alt-Svc cache so that Alt-Svc entries can be shared across origins which share the same hostname suffix.
Risk Level: Low
Testing: New unit tests
Docs Changes: Update proto docs
Release Notes: Updated
Signed-off-by: Ryan Hamilton <rch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2b67ce314da75f304d7f65d05155bcee7c7d18e1
Commit Message: Currently, there can be multiple built-in regexes targeting the same tag name, and in fact there's at least one case where this occurs:
466e78586a/source/common/config/well_known_names.cc (L133)466e78586a/source/common/config/well_known_names.cc (L136)
This change prevents a second tag value for a given name being from being extracted, to meet Prometheus' requirements.
Having two alternate ways of generating the same tag value allows them to be expressed using two distinct regexes, which are easier to understand, and possible for the infrastructure to optimize with the prefix-map. This situation also occurs with Istio/Wasm, which for reasons that elude me, generate stats with two very different syntaxes both meaning HTTP Response Code, and adds those extractors using configuration.
An alternate approach is to add complexity to the regex processing to allow matches in an ORed regex, which is a bit confusing, and results in regexes that cannot be optimized well by our current system. There is no one prefix that can be used to reduce the set of regexes that need to be evaluated against every stat, and the long regexes with captures are hard for humans to read. See https://github.com/envoyproxy/envoy/pull/22791
The disadvantage of allowing multiple regexes to generate the same tag, is that it may create more scenarios where a stats sink like Prometheus may be given multiple tags with the same name, and it would be good to get some notion that this is OK. Currently such cases would be rejected during process startup (for CLI-based tags) or during config processing.
I opened this up for review to initiate this discussion, but want to make sure various stakeholders have a chance to weigh in. Though no protobufs were changed structurally in this PR, it's kind of an API change (with .proto comments) and should probably be approved as one.
Additional Description:
Risk Level: medium
Testing: //test/...
Docs Changes: changed comments in proto file that previously indicated dups were not allowed
Release Notes:
Platform Specific Features:
Fixes: https://github.com/envoyproxy/envoy/issues/22591
Signed-off-by: Joshua Marantz <jmarantz@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 45f062466a40216d29117320ede012d087ca1318
Updating documentation to make clearer this issue: #3058
Risk Level: Low since it's just documentation?
Testing: Didn't do any -- happy to but was too lazy to set up my environment 😅
Docs Changes: Specifically for outlier detection, I was confused that 5xx mapped -- for TCP traffic -- to connection failures
Release Notes: Updated documentation on outlier detection
Fixes#3058
Signed-off-by: Steven Chu <stevenc1@gmail.com>
Signed-off-by: Steven Chu <stevenchu@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 118b15a6b2491d46731a27f3a6b8eed3f643fa00
This PR will implement issue detailed here and described below: #7763
Match Patterns and Templates
Wildcard support based on match patterns and templates.
A match pattern matches an incoming URL path.
Match patterns support glob operators to match URL text and variable definitions to bind matched text to names.
Template patterns are used to re-write URLs.
Template patterns build new URLs and may reference variables bound by a match pattern.
Match Examples
/**.m3u8 would match /foo.m3u8 and /foo/bar.m3u8.
/{dir_name}/*.ts would match /example/file.ts and bind dir_name="example" for a later template match to use.
/{dir_name}/**.ts would match /example/path/file.ts and bind dir_name="example" for a later template match to use. This would also match /example/.ts, which may or may not be a desired behavior.
/{path=v1/*}/{file=*.ts} would match /v1/example/movie.ts (binding path="v1/example" and file="movie"), but would not match /v0/example/movie.ts.
See post for full details and example:
#7763 (comment)
Risk Level:
Testing:
Unit tests. Both both internal matching/rewrite library and config/data plane changes.
Signed-off-by: silverstar195 <seanmaloney@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8cfc61f916cf52ce8bce6710686e9d4fca2c06bd
data-plane-api(Azure Pipelines)