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.
2476 Commits
2 Branches
0 Tags
18 MiB
Tag: Branch: Tree: 651df3704b
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '651df3704b'
${ noResults }
data-plane-api/envoy/extensions/transport_sockets/tls/v3/BUILD

15 lines
387 B
Raw Normal View History Unescape

Fix proto_sync.py (#12434) Fix path in proto_sync.py generated comments and regenerate. Signed-off-by: wzshiming <wzshiming@foxmail.com> Mirrored from https://github.com/envoyproxy/envoy @ 8c1ad4cb9e0617d43b325a47b6785ea4b57ae475
4 years ago
# DO NOT EDIT. This file is generated by tools/proto_format/proto_sync.py.
api/build: automatically generate BUILD files. (#8506) This provides canonical BUILD formatting and puts protoxform in charge of being able to determine import paths, without having to worry about Bazel implications. Part of #8082. Risk level: Low Testing: tools/proto_sync.py, visual inspection of diffs. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ e53f40f0e5ccc84fca5cd350416fe0f2accf8229
5 years ago
api/build: switch to only package level targets in API. (#8495) As part of #8082, we want to be able to (1) automatically generate BUILD files and (2) treat packages as atomic from a "upgrade / do not upgrade" decision perspective. This is simplified by having our BUILD targets at package granularity, since this is what the protoxform plugin operates on. This PR broadens the package-level treatment that was already introduced for Go in #8003 to Python and C++. This simplifies BUILD files significantly and opens the way to automated generation. There is some technical debt introduced, since all visibility controls have been removed. This is slated for reintroduction in https://github.com/envoyproxy/envoy/issues/8491. As a bonus (useful for BUILD file generation), also removed the inconsistency in BUILD package target naming for packages in envoy.api.* and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg. Risk level: Low (but this will break internal builds and require BUILD fixups to consuming projects). Testing: bazel test //test/... @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 4e858f17fe08224c9c089240908ccd0c518e01a7
5 years ago
load("@envoy_api//bazel:api_build_system.bzl", "api_proto_package")
api: clone v2[alpha] to v3alpha. (#8125) This patch establishes a v3alpha baseline API, by doing a simple copy of v2[alpha] dirs and some sed-style heuristic fixups of BUILD dependencies and proto package namespaces. The objective is provide a baseline which we can compare the output from tooling described in #8083 in later PRs, providing smaller visual diffs. The core philosophy of the API migration is that every step will be captured in a script (at least until the last manual steps), api/migration/v3alpha.sh. This script will capture deterministic migration steps, allowing v2[alpha] to continue to be updated until we finalize v3. There is likely to be significant changes, e.g. in addition to the work scoped for v3, we might want to reduce the amount of API churn by referring back to v2 protos where it makes sense. This will be done via tooling in later PRs. Part of #8083. Risk level: Low Testing: build @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 085d72b490c124a02849812798f5513a8df9ae72
5 years ago
licenses(["notice"]) # Apache 2
api: organize go_proto_libraries (#8003) Fixes #7982 Defines a package level proto library and its associated internal go_proto_library. Deletes all existing api_go_proto_library, api_go_grpc_library, and go_package annotations in protos (they are not required and pollute the sources). I deliberately avoided touching anything under udpa since it's being moved to another repository. Risk Level: low Testing: build completes Signed-off-by: Kuat Yessenov <kuat@google.com> Mirrored from https://github.com/envoyproxy/envoy @ d504fde0ffd97017d1ddff8caa9a3b46bba9ae48
5 years ago
api_proto_package(
config: breadcrumb annotations to infer earlier API message versions. (#9166) This PR avoids having to include an API type database in the Envoy build by introducing a message annotation option that allows Envoy to determine earlier corresponding message types via descriptor inspection. The ApiTypeDb is now ApiTypeOracle and utilizes these annotations. Risk level: Low Testing: Existing API and verison upgrade tests pass. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 297f7a73b3f93bccf8af73c0a555ae52bce6cecb
5 years ago
deps = [
xds: restructure CertificateProvider fields (#17201) When these fields were originally added, we didn't fully understand how the `CertificateValidationContext` configuration worked. A `CertificateProvider` cannot provide a full `CertificateValidationContext` proto; it provides only the CA certs (i.e., the `trusted_ca` field within the `CertificateValidationContext` proto). So this PR makes the following changes: - Duplicates the `CertificateProvider` and `CertificateProviderInstance` messages from `CommonTlsContext` as `CertificateProviderPlugin` and `CertificateProviderPluginInstance` outside of `CommonTlsContext` (in common.proto instead of tls.proto). (Note that this also paves the way for reusing these messages for SPIFFE validation in the future.) - Adds new `CertificateProviderPlugin` and `CertificateProviderPluginInstance` fields to `CertificateValidationContext`, as an alternative to the existing `trusted_ca` field. (Added annotations to make this a `oneof` in the future.) - In `CommonTlsContext`, I have deprecated the `validation_context_certificate_provider` and `validation_context_certificate_provider_instance` fields both in the `validation_context_type` oneof and in `CombinedValidationContext`. - In `CommonTlsContext`, I have replaced the `tls_certificate_certificate_provider` and `tls_certificate_certificate_provider_instance` fields with new fields that use the new messages outside of `CommonTlsContext`. Risk Level: Low Testing: N/A Docs Changes: Included in PR Release Notes: N/A Platform Specific Features: N/A Signed-off-by: Mark D. Roth <roth@google.com> Mirrored from https://github.com/envoyproxy/envoy @ b29d6543e7568a8a3e772c7909a1daa182acc670
3 years ago
"//envoy/annotations:pkg",
api: freeze v3 API. (#9694) In which we convert every v3alpha reference to v3. In future revs of the stable API versioning policy, we will develop better tooling to support > 2 alpha and stable versions. For v3, it seems reasonable to just mv v3alpha to v3, since there should be no external consumers yet. Risk level: Low Testing: bazel test //test/..., CI. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
5 years ago
"//envoy/config/core/v3:pkg",
"//envoy/type/matcher/v3:pkg",
update upda dependency (#9262) Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ 4997d02fbf551e54bd569fd0e0ccbcf7e3362516
5 years ago
"@com_github_cncf_udpa//udpa/annotations:pkg",
config: breadcrumb annotations to infer earlier API message versions. (#9166) This PR avoids having to include an API type database in the Envoy build by introducing a message annotation option that allows Envoy to determine earlier corresponding message types via descriptor inspection. The ApiTypeDb is now ApiTypeOracle and utilizes these annotations. Risk level: Low Testing: Existing API and verison upgrade tests pass. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 297f7a73b3f93bccf8af73c0a555ae52bce6cecb
5 years ago
],
api: clone v2[alpha] to v3alpha. (#8125) This patch establishes a v3alpha baseline API, by doing a simple copy of v2[alpha] dirs and some sed-style heuristic fixups of BUILD dependencies and proto package namespaces. The objective is provide a baseline which we can compare the output from tooling described in #8083 in later PRs, providing smaller visual diffs. The core philosophy of the API migration is that every step will be captured in a script (at least until the last manual steps), api/migration/v3alpha.sh. This script will capture deterministic migration steps, allowing v2[alpha] to continue to be updated until we finalize v3. There is likely to be significant changes, e.g. in addition to the work scoped for v3, we might want to reduce the amount of API churn by referring back to v2 protos where it makes sense. This will be done via tooling in later PRs. Part of #8083. Risk level: Low Testing: build @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 085d72b490c124a02849812798f5513a8df9ae72
5 years ago
)