Signed-off-by: Adam Kotwasinski <adam.kotwasinski@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c2630addb1ac2984531c07317af5f9dd882b2a01
Commit Message: Allow specifying resource detectors for the OpenTelemetry tracer via a new configuration resource_detectors. The resource detector reads from the env variable OTEL_RESOURCE_ATTRIBUTES which is defined by the OTel specification. The detector returns a resource object populated with the detected attributes, which is sent as part of the OTLP request.
Additional Description: This PR adds the "foundation" for building other resource detectors in Envoy. It is based on the OTel collector implementation. Users can configure multiple resource detectors, and they work together to "merge" all the detected attributes into a single resource object, which is then part of the OTLP message exported.
Risk Level: Low
Testing: Multiple unit tests, that cover all new code/scenarios. I also did manual testing, running Envoy locally with the OTel tracer + env resource detector enabled. Resource attributes detected from my environment is successfully exported as seen in the Jaeger screenshot.
resource-detectors-env-jaeger
Docs Changes: Not sure if I should add/where. Happy to do it.
Release Notes: N/A
Platform Specific Features: N/A
[Optional Runtime guard:] N/A
[Optional Fixes#28929]
Here is how the new config is used:
tracing:
provider:
name: envoy.tracers.opentelemetry
typed_config:
"@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
grpc_service:
envoy_grpc:
cluster_name: opentelemetry_collector
timeout: 0.250s
service_name: envoy-gRPC-exporter
resource_detectors: # --> NEW CONFIG
- name: envoy.tracers.opentelemetry.resource_detectors.environment
typed_config:
"@type": type.googleapis.com/envoy.extensions.tracers.opentelemetry.resource_detectors.v3.EnvironmentResourceDetectorConfig
Signed-off-by: Joao Grassi <joao.grassi@dynatrace.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4eaa1f866164eee5d51e46406bcb31d8dec99bdd
API to address gaps with the downstream Istio filter to finish upstreaming.
Issue: #29681
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e9366f2b34be537b1b30ed17a4fd75b4715b5990
* Add new idea for selecting hosts among those not selected yet.
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Change how we choose full table scan
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Remove cout
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Fix Tests for load_balancer_impl_test
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Fix format and make sure full scan happens only when selected or the number of choices is larger than the size.
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Enable new option on extesions api only
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Fix Integration tests.
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Add release notes for full scan in least request LB.
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Fix ref for release note.
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Fix release notes
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
* Update release note
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
---------
Signed-off-by: Leonardo da Mata <ldamata@spotify.com>
Signed-off-by: Leonardo da Mata <barroca@gmail.com>
Co-authored-by: Leonardo da Mata <ldamata@spotify.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3ea2bc40590c1a48f26e8297ae55d7a6d08083e9
* http api: new disable flag to disable a filter in the filter chain by default
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* complete development
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* more tests to verify the new feature
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* add release note
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* fix link
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* fix test
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* Update api/envoy/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto
Co-authored-by: Matt Klein <mattklein123@gmail.com>
Signed-off-by: code <wangbaiping@corp.netease.com>
* Update changelogs/current.yaml
Co-authored-by: Matt Klein <mattklein123@gmail.com>
Signed-off-by: code <wangbaiping@corp.netease.com>
* Update source/common/http/filter_chain_helper.h
Co-authored-by: Matt Klein <mattklein123@gmail.com>
Signed-off-by: code <wangbaiping@corp.netease.com>
* fix spelling error
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
* fix ci
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
---------
Signed-off-by: wbpcode <wangbaiping@corp.netease.com>
Signed-off-by: code <wangbaiping@corp.netease.com>
Co-authored-by: Matt Klein <mattklein123@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9be3183433f30e9a726add174c80fd32cf6b7202
Prior to this PR the name field in HeaderValueExtractor could have been any string. This limits it to valid HTTP header names.
Risk Level: low
Testing: Added fuzz test
Fixes fuzz issue 60277
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 61a1a867c276e81bc0cb5ccd4a11fced7500d03f
* compression: add per-route remove_accept_encoding_header
The use case: envoy is handling compression for all routes by default,
but some routes _may_ be able to handle compression better than
envoy (e.g. by serving precompressed assets), or they may not, in which
case envoy should still compress. The existing per-route compression
configuration, which only consists of "entirely disabling compression",
is not acceptable for this use case.
Signed-off-by: Ian Kerins <git@isk.haus>
Mirrored from https://github.com/envoyproxy/envoy @ 24efd20cfc69f664cb1c94e83537e940fcbb1e2d
Commit Message: docs: add warnings about client cert validation
Additional Description:
Add a warning to TlsContextMatchOptions.validated that the validation
status will always be false for resumed TLS sessions, as validation is
not currently performed upon TLS session resumption.
Add a similar warning to the Lua filter API documentation, regarding the
peerCertificateValidated() method. Fix a couple of existing typos here.
Risk Level: low
Testing: manual (built docs site)
Docs Changes: proto comments and Lua filter API docs
Release Notes: n/a
Platform Specific Features: n/a
Related to #21235
Mirrored from https://github.com/envoyproxy/envoy @ cd92acff8ed6b8f6a513c11b20a8ddb8b16ea14f
Commit Message: Adds a new extension to set the filter state
Risk Level: low
Testing: done
Docs Changes: yes
Release Notes: yes
Issue: #29813
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 025d49f78410841e6caa26c1e42465c17f168e91
Commit Message: The API is now used in many places and must follow safe deprecation practices.
Additional Description:
Risk Level: low
Testing: none
Docs Changes:
Release Notes:
Platform Specific Features:
Mirrored from https://github.com/envoyproxy/envoy @ be01f8ae38ab48d38ab28dac9a682d789fa4bc09
Commit Message: Fix the default config for port migration. It's supposed to be 4 PTOs, but it was incorrectly set to 1.
Risk Level: low
Testing: integration tests
Docs Changes: n/a
Release Notes: n/a
Platform Specific Features: client only.
Signed-off-by: Renjie Tang <renjietang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 61afc661ba3b02ae01dd74951c3bee4a1bfb2326
Clean up erroneous toolshed dependency. Noop name update to libcirclhist.
Signed-off-by: moderation <michael@sooper.org>
Mirrored from https://github.com/envoyproxy/envoy @ 147c893e867dc7a8cd5967efcccc8ab394fcdfee
As this is used in the api as well as Envoy itself the dep has
been moved there.
Signed-off-by: phlax <phlax@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ b0fec2ecdd54cf8a92a04a6d2481cdacd65c9d36
Additional Description:
Risk Level: Low
Testing: Ut/Integrated Test
Docs Changes:
Release Notes:
Platform Specific Features:
Signed-off-by: Felix Du <durd07@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 6092cdcc2f4cce51c7c6409b4452e52d0a185f42
[ZK filter] Add per opcode request/response byte counters
Additional Description: Currently, the ZK filter only reports total request/response bytes. This PR adds the feature to report per opcode request/response bytes counters. These new metrics will be controlled by enable_per_opcode_request_response_bytes. Its default value is false, which means these metrics will not be emitted by default.
With the per opcode request/response bytes counters, plus existing per opcode request/response counters, we are able to get the average request/response size of each opcode. This gives us more observability of ZK.
Risk Level: low
Testing: unit tests
Docs Changes: This PR updates the ZK filter doc.
Release Notes: See changelogs/current.yaml
API Considerations: Add enable_per_opcode_request_bytes and enable_per_opcode_response_bytes to ZK proto.
Signed-off-by: Zhewei Hu <zhu@pinterest.com>
Mirrored from https://github.com/envoyproxy/envoy @ 91fd29408f0e788f2180746c55bc34d395d24e11
update-envoy[bot]