Chiebot-Mirror
/
data-plane-api
mirror of https://github.com/envoyproxy/data-plane-api.git
8
0
Fork 0
Code Issues Projects Releases Wiki Activity
[READ ONLY MIRROR] Envoy REST/proto API definitions and documentation. (grpc依赖)
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
942 Commits
2 Branches
0 Tags
17 MiB
Tag: Branch: Tree: 330567f09b
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '330567f09b'
${ noResults }
data-plane-api/docs/BUILD

101 lines
4.6 KiB
Raw Normal View History Unescape

Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
licenses(["notice"]) # Apache 2
package_group(
name = "docs",
packages = [
"//docs",
],
)
# TODO(htuch): Grow this to cover everything we want to generate docs for, so we can just invoke
# bazel build //docs:protos --aspects tools/protodoc/protodoc.bzl%proto_doc_aspect --output_groups=rst
proto_library(
name = "protos",
deps = [
admin: add support for displaying san in certs end point (#4566) *Description*: Adds support for displaying Subject Alternate Names as a comma separated list of string in `/certs` admin end point *Risk Level*: Low *Testing*: Automated *Docs Changes*: Updated *Release Notes*: Updated Signed-off-by: Rama <rama.rao@salesforce.com> Mirrored from https://github.com/envoyproxy/envoy @ 7403314b0b255a89ab284b7ed0eead5a5f4aecfd
6 years ago
"//envoy/admin/v2alpha:certs",
admin: add json serialized proto for /clusters (#3478) Added the /clusters?format=json admin endpoint along with a proto representation of /clusters. Risk Level: Low Testing: Added a unit test for the new format. Docs Changes: Added a brief description on the admin docs and linked to the more detailed proto definition. Release Notes: Added release notes. Fixes #2020 Signed-off-by: Matt Rice <mattrice@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 64605338ef040a949c5ea205bdd472a8fe42306c
7 years ago
"//envoy/admin/v2alpha:clusters",
admin: complete /config_dump (#3340) This completes initial implementation of the /config_dump admin endpoint, allowing for detailed display of the currently loaded Envoy configuration, including versions of each resource. Note that this does not include output for EDS. That work is tracked in https://github.com/envoyproxy/envoy/issues/3362. Fixes https://github.com/envoyproxy/envoy/issues/2421 Fixes https://github.com/envoyproxy/envoy/issues/2172 *Risk Level*: Low *Testing*: Unit/integration *Docs Changes*: Added *Release Notes*: Added Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ a2a5fc1df1541ebe0b0cd761f3e77212dbf70e5f
7 years ago
"//envoy/admin/v2alpha:config_dump",
docs: add memory proto docs (#4611) Description: While working on certs changes, I realized that memory proto doc links were missing. This PR adds them. Risk Level: Low Signed-off-by: Rama <rama.rao@salesforce.com> Mirrored from https://github.com/envoyproxy/envoy @ 7600419d74aaa0d52c5f56f1a2b35c7ce05a76a0
6 years ago
"//envoy/admin/v2alpha:memory",
stats: export mutex contention data (#4750) Signed-off-by: James Buckland <jbuckland@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 0287a6feb03e773ed8a15955536bb8285d0ae4a6
6 years ago
"//envoy/admin/v2alpha:mutex_stats",
docs: remove v1 docs (#4943) We no longer allow running v1 config, and users can look at old docs if they want to see the v1 docs still. Also fix a doc issue in the /server_info admin endpoint. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ 8aba108eda816ea29dc80b973a1387257cd209c6
6 years ago
"//envoy/admin/v2alpha:server_info",
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
"//envoy/admin/v2alpha:tap",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/api/v2:cds",
"//envoy/api/v2:discovery",
"//envoy/api/v2:eds",
"//envoy/api/v2:lds",
"//envoy/api/v2:rds",
"//envoy/api/v2/cluster:circuit_breaker",
"//envoy/api/v2/cluster:outlier_detection",
"//envoy/api/v2/core:protocol",
"//envoy/api/v2/listener",
"//envoy/api/v2/ratelimit",
"//envoy/api/v2/route",
access log service: cleanup and docs (#3494) Fixes https://github.com/envoyproxy/envoy/issues/743 This is a general cleanup of all of the access logging documentation. I have reorganized a bunch of things and hidden the various gRPC logging fields that are not implemented yet. I've also moved the existing tap protos into a new "output" directory. This is the best name I could come up for cleanly separating output data that might be stored outside of any service or configuration. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ c15019e79c832d9f0a09468affaadabc4be3e115
7 years ago
"//envoy/config/accesslog/v2:als",
"//envoy/config/accesslog/v2:file",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/bootstrap/v2:bootstrap",
Add redis cluster (#6446) Signed-off-by: Henry Yang <hyang@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ ac1757f17c5902a13a416953c78c5c77a00f72e7
6 years ago
"//envoy/config/cluster/redis:redis_cluster",
tap transport: refactor to use common tap framework (#5724) This commit refactors the tap transport socket to use the common tap extension configuration and tap matching infrastructure. More match conditions will be added in a future PR as well as additional cleanups that have been marked with TODOs. One result of this PR is that the HTTP tap filter can now have a static configuration as well as write to a file per tap sink. All future tap PRs should be smaller and more targeted after this one. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ f37ebdc14f4c0adf0e90aabddae833355c0cec1b
6 years ago
"//envoy/config/common/tap/v2alpha:common",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/accesslog/v2:accesslog",
dubbo_proxy: Refactor the DubboProxy filter (#6410) Description: Refactor the DubboProxy filter Risk Level: low Testing: unit test Docs Changes: inline Release Notes: add routing capabilities for the Dubbo protocol Signed-off-by: leilei.gll <leilei.gll@alibaba-inc.com> Mirrored from https://github.com/envoyproxy/envoy @ db7f12427ffedebba5891e724f2ef39d3405c81e
6 years ago
"//envoy/config/filter/dubbo/router/v2alpha1:router",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/buffer/v2:buffer",
http filter: add CSRF filter (#6470) Signed-off-by: Derek Schaller <dschaller@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ eaaa918be9f1eff5768a65e28dbbd509c7652cc3
6 years ago
"//envoy/config/filter/http/csrf/v2:csrf",
ext_authz: v2Alpha migration and documentation improvements (#5672) Signed-off-by: Gabriel <gsagula@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ a15dbc921a8e8082277904315f981ffd160f936a
6 years ago
"//envoy/config/filter/http/ext_authz/v2:ext_authz",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/fault/v2:fault",
"//envoy/config/filter/http/gzip/v2:gzip",
Header to metadata filter (#2436) (#3633) Add support for extracting dynamic metadata from requests. This can then be used as static metadata would be used (e.g.: for subset load balancer metadata matches, logging, etc). Risk Level: Low Testing: unit-test Docs Changes: Basic docs. Release Notes: N/A Signed-off-by: Raul Gutierrez Segales <rgs@pinterest.com> Mirrored from https://github.com/envoyproxy/envoy @ 827c0a548ab38d55debe00587ee27253786befad
7 years ago
"//envoy/config/filter/http/header_to_metadata/v2:header_to_metadata",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/health_check/v2:health_check",
ip tagging filter: update proto and add documentation (#506) Updates the L7 IP tagging filter proto, v1 configuration documentation and overview documentation. Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>
7 years ago
"//envoy/config/filter/http/ip_tagging/v2:ip_tagging",
doc: add doc for Jwt_authn filter (#4527) update doc for jwt_authn http filter format config.proto comment for doc add a new rst file: docs/root/configuration/http_filters/jwt_authn_filter.rst Risk Level: None Docs Changes: Yes Signed-off-by: Wayne Zhang <qiwzhang@google.com> Mirrored from https://github.com/envoyproxy/envoy @ d101ae7decfdae148f53ea9d2220444c726dfbfd
6 years ago
"//envoy/config/filter/http/jwt_authn/v2alpha:jwt_authn",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/lua/v2:lua",
"//envoy/config/filter/http/rate_limit/v2:rate_limit",
authz: RBAC HTTP filter + utilities (#3455) Signed-off-by: Chris Roche <croche@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ d519097e9d0f914cac7362f8bafc8623ba2c09db
7 years ago
"//envoy/config/filter/http/rbac/v2:rbac",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/router/v2:router",
"//envoy/config/filter/http/squash/v2:squash",
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
"//envoy/config/filter/http/tap/v2alpha:tap",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/http/transcoder/v2:transcoder",
[docs] original src listener filter docs (#5539) Signed-off-by: Kyle Larose <kyle@agilicus.com> Mirrored from https://github.com/envoyproxy/envoy @ a3645c1ff295442f86834b82df769605539e4108
6 years ago
"//envoy/config/filter/listener/original_src/v2alpha1:original_src",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/network/client_ssl_auth/v2:client_ssl_auth",
dubbo_proxy: Refactor the DubboProxy filter (#6410) Description: Refactor the DubboProxy filter Risk Level: low Testing: unit test Docs Changes: inline Release Notes: add routing capabilities for the Dubbo protocol Signed-off-by: leilei.gll <leilei.gll@alibaba-inc.com> Mirrored from https://github.com/envoyproxy/envoy @ db7f12427ffedebba5891e724f2ef39d3405c81e
6 years ago
"//envoy/config/filter/network/dubbo_proxy/v2alpha1:dubbo_proxy",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/network/ext_authz/v2:ext_authz",
"//envoy/config/filter/network/http_connection_manager/v2:http_connection_manager",
"//envoy/config/filter/network/mongo_proxy/v2:mongo_proxy",
"//envoy/config/filter/network/rate_limit/v2:rate_limit",
rbac: add rbac network filter. (#4083) Signed-off-by: Yangmin Zhu <ymzhu@google.com> Mirrored from https://github.com/envoyproxy/envoy @ c283439b6b020df64e6a1af4b3ab41d4099f4738
6 years ago
"//envoy/config/filter/network/rbac/v2:rbac",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/filter/network/redis_proxy/v2:redis_proxy",
"//envoy/config/filter/network/tcp_proxy/v2:tcp_proxy",
thrift: allow translation between downstream and upstream protocols (#4136) We use the new extension_protocol_options field on Cluster to allow clusters to be configured with a transport and/or protocol. Downstream requests are automatically translated to the upstream dialect and upstream responses are translated back to the downstream's dialect. Moves the TransportType and ProtocolType protobuf enums out of the ThriftProxy message to allow their re-use in ThriftProtocolOptions. *Risk Level*: low *Testing*: integration test *Docs Changes*: added thrift filter docs *Release Notes*: n/a Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io> Mirrored from https://github.com/envoyproxy/envoy @ c91625ed829a4ec4123bab8b4e6b223f67d88e4a
6 years ago
"//envoy/config/filter/network/thrift_proxy/v2alpha1:thrift_proxy",
thrift: rate limiter filter (#4603) Introduces a rate limiter filter for thrift requests, implemented as a decoder filter that works in conjunction with the thrift router filter. Risk Level: low Testing: unit tests Doc Changes: inline with proto definitions Release notes: updated Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io> Mirrored from https://github.com/envoyproxy/envoy @ 6ac936f2750c39a8b4fb232d6ddc4802f4e6aeee
6 years ago
"//envoy/config/filter/thrift/rate_limit/v2alpha1:rate_limit",
thrift_proxy: configurable decoder filters (#4458) Modifies the thrift proxy to allow configurable decoder filters. *Risk Level*: low *Testing*: unit tests *Docs Changes*: inline *Release Notes*: updated Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io> Mirrored from https://github.com/envoyproxy/envoy @ 05cb4189f201f9f7187d214ee31a91e7741696b8
6 years ago
"//envoy/config/filter/thrift/router/v2alpha1:router",
s/grpc_credentials/grpc_credential/ in api (#3595) Fixes #3584 Description: Risk Level: Low Testing: existing tests / CI Docs Changes: Release Notes: Signed-off-by: Lizan Zhou <zlizan@google.com> Mirrored from https://github.com/envoyproxy/envoy @ e931af6a84013a934a40f817d941e6b745cbca26
7 years ago
"//envoy/config/grpc_credential/v2alpha:file_based_metadata",
health check: add custom health checker (#596) This patch adds the extension health check, with redis as the first example. Signed-off-by: Dhi Aurrahman <dio@rockybars.com>
7 years ago
"//envoy/config/health_checker/redis/v2:redis",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/metrics/v2:metrics_service",
"//envoy/config/metrics/v2:stats",
"//envoy/config/ratelimit/v2:rls",
authz: RBAC HTTP filter + utilities (#3455) Signed-off-by: Chris Roche <croche@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ d519097e9d0f914cac7362f8bafc8623ba2c09db
7 years ago
"//envoy/config/rbac/v2alpha:rbac",
Add overload manager to bootstrap config (#4038) Initialize on startup and add documentation (issue #373) Risk Level: low Testing: unit tests Docs Changes: add docs for overload manager Signed-off-by: Elisha Ziskind <eziskind@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 14140ad83293d2cb4fcf356064ed98c3bffa295b
6 years ago
"//envoy/config/resource_monitor/fixed_heap/v2alpha:fixed_heap",
overload: add a file-based injected resource monitor (#4298) This allows injecting a synthetic resource pressure from a file, primarily intended for use in integration tests to force envoy into an overloaded state. Testing: unit tests Docs Changes: docs updated to reference new resource monitor Signed-off-by: Elisha Ziskind eziskind@google.com Mirrored from https://github.com/envoyproxy/envoy @ 12957a29bd2627bc0bba921603bd5869a449be47
6 years ago
"//envoy/config/resource_monitor/injected_resource/v2alpha:injected_resource",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/config/trace/v2:trace",
transport capture: rename to tap (#5666) This is a rename PR only. It renames the capture transport socket and associated tools to the tap transport socket. It also updates some documentation. In a subsequent PR I'm going to refactor the tap transport socket to use the new common tap framework so that the tap transport socket can be configured via admin, the HTTP tap filter can write to a file, the tap transport socket can have matching, etc. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ 7a5849f2a8bcc55fa16da3eaee94d9c99a11147c
6 years ago
"//envoy/config/transport_socket/tap/v2alpha:tap",
access log service: cleanup and docs (#3494) Fixes https://github.com/envoyproxy/envoy/issues/743 This is a general cleanup of all of the access logging documentation. I have reorganized a bunch of things and hidden the various gRPC logging fields that are not implemented yet. I've also moved the existing tap protos into a new "output" directory. This is the best name I could come up for cleanly separating output data that might be stored outside of any service or configuration. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ c15019e79c832d9f0a09468affaadabc4be3e115
7 years ago
"//envoy/data/accesslog/v2:accesslog",
upstream: Outlier ejection proto logging (#5517) Signed-off-by: Kateryna Nezdolii <nezdolik@spotify.com> Mirrored from https://github.com/envoyproxy/envoy @ 5c1d28e7294dc5aca7be8b682f573d51c31d045a
6 years ago
"//envoy/data/cluster/v2alpha:outlier_detection_event",
health check: structured active healthcheck logging (#3176) Signed-off-by: James Sedgwick <jsedgwick@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ a5da0783828d21a2a90d1088134967a7201f0210
6 years ago
"//envoy/data/core/v2alpha:health_check_event",
tap: add HTTP request/response body tapping (#5823) 1) Add request/response body tapping 2) Add buffered body limits (TBI for transport socket) 3) Add the JSON_BODY_AS_BYTES and JSON_BODY_AS_STRING output formats for convenience when the body is known to be human readable. 4) Add JSON output for the file per tap sink. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ 9a06dc0777d2809195cb1fc414b05ae7c0660193
6 years ago
"//envoy/data/tap/v2alpha:common",
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
"//envoy/data/tap/v2alpha:http",
transport capture: rename to tap (#5666) This is a rename PR only. It renames the capture transport socket and associated tools to the tap transport socket. It also updates some documentation. In a subsequent PR I'm going to refactor the tap transport socket to use the new common tap framework so that the tap transport socket can be configured via admin, the HTTP tap filter can write to a file, the tap transport socket can have matching, etc. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ 7a5849f2a8bcc55fa16da3eaee94d9c99a11147c
6 years ago
"//envoy/data/tap/v2alpha:transport",
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
"//envoy/data/tap/v2alpha:wrapper",
access log service: cleanup and docs (#3494) Fixes https://github.com/envoyproxy/envoy/issues/743 This is a general cleanup of all of the access logging documentation. I have reorganized a bunch of things and hidden the various gRPC logging fields that are not implemented yet. I've also moved the existing tap protos into a new "output" directory. This is the best name I could come up for cleanly separating output data that might be stored outside of any service or configuration. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ c15019e79c832d9f0a09468affaadabc4be3e115
7 years ago
"//envoy/service/accesslog/v2:als",
ext_authz: v2Alpha migration and documentation improvements (#5672) Signed-off-by: Gabriel <gsagula@gmail.com> Mirrored from https://github.com/envoyproxy/envoy @ a15dbc921a8e8082277904315f981ffd160f936a
6 years ago
"//envoy/service/auth/v2:attribute_context",
"//envoy/service/auth/v2:external_auth",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
"//envoy/service/discovery/v2:ads",
"//envoy/service/load_stats/v2:lrs",
"//envoy/service/metrics/v2:metrics_service",
rate-limit: remove legacy service support (#4881) Signed-off-by: Venil Noronha <veniln@vmware.com> Mirrored from https://github.com/envoyproxy/envoy @ ed3f5f48a8a5d4baf6c98ac27c1e9a79fbde4d2e
6 years ago
"//envoy/service/ratelimit/v2:rls",
tap: introduce HTTP tap filter (#5515) This is a MVP for the HTTP tap filter. It includes minimal infrastructure for the following: 1. Generic tap configuration which in the future will be used for static config, XDS config, etc. In this MVP the tap can be configured via a /tap admin endpoint. 2. Generic output configuration which in the future will be used for different output sinks such as files, gRPC API, etc. In this MVP the tap results are streamed back out the /tap admin endpoint. 3. Matching infrastructure. In this MVP only matching on request and response headers are implemented. Both logical AND and logical OR matches are possible. 4. In this MVP request/response body is not considered at all. 5. All docs are included and with all the caveats the filter is ready to use for the limited cases it supports (which are likely still to be useful). There is a lot of follow on work which I will do in subsequent PRs. This includes: 1. Merging the existing capture transport socket into this framework. 2. Implementing body support, both for matching on body contents as well as outputting body data. 3. Tap rate limiting so too many streams do not get tapped. 4. gRPC matching. Using reflection and loaded proto definitions, it will be possible to match on gRPC fields. 5. JSON matching. If the body parses as JSON, we can allow matching on JSON fields. Part of https://github.com/envoyproxy/envoy/issues/1413. Signed-off-by: Matt Klein <mklein@lyft.com> Mirrored from https://github.com/envoyproxy/envoy @ cf80045587240d494e54e9772949bc9af5eda61f
6 years ago
"//envoy/service/tap/v2alpha:common",
access log: runtime filter enhancements (#490) 1) Add ability to runtime filter to configure default, divisor, and whether independent randomness is used. 2) Also add LE to the comparison filter. Signed-off-by: Matt Klein <mklein@lyft.com>
7 years ago
"//envoy/type:percent",
Support range based header matching for request routing. (#475) v2 api changes: Use oneof to specify header match options, based on value(exact_match), regex or range. The existing value and regex fields will be deprecated. Use the header_match_specfier oneof instead. Add a new range.proto (envoy.type.v2) for the range type definition. The SInt64Range message is defined in envoy.type.v2 range.proto. It consists of start and end (inclusive, exclusive) sint64 values. v1 api: Add a range_match object to the route headers json. Presence of this object indicates range based route match. Example: For the below route config: { "prefix": "/", "cluster": "PartitionB", "name": "PartitionKey", "range_match": { "start": 0, "end": 10} } In the incoming request, if the PartitionKey header value = 0, route match succeeds. Route match fails if the header value = 10, -10, "somestring". This feature can be used for request routing with Service Fabric stateful services, to route to the desired partition with the [ranged partitioning scheme](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning#ranged-partitioning-scheme) Signed-off-by: Kavya Kotacherry <kavyako@microsoft.com>
7 years ago
"//envoy/type:range",
rbac: add metadata support to rbac filter (#3638) Signed-off-by: Yangmin Zhu <ymzhu@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 9e7a3ab6fdf4c55557c3a06a6f7f1fa9c7a4ad7e
7 years ago
"//envoy/type/matcher:metadata",
"//envoy/type/matcher:number",
"//envoy/type/matcher:string",
Move envoy.api.v2 core protos to envoy.api.v2.core and organize filters (#452) There are several main changes in this PR: Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos. Create individual packages for each filter and add independent versioning to each filter. Add visibility constraints to prevent formation of dependency cycles. Add gogoproto annotations to improve go code generation. After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package. The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane). Added a few gogoproto annotations to improve golang code generation. Signed-off-by: Kuat Yessenov <kuat@google.com>
7 years ago
],
)