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.
1337 Commits
2 Branches
0 Tags
17 MiB
Tag: Branch: Tree: 3981b5e8b2
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '3981b5e8b2'
${ noResults }
data-plane-api/envoy/service/endpoint/v3/eds.proto

49 lines
1.7 KiB
Raw Normal View History Unescape

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
syntax = "proto3";
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
package envoy.service.endpoint.v3;
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
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
import "envoy/service/discovery/v3/discovery.proto";
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
import "google/api/annotations.proto";
api: sync v2 -> v3alpha. (#8346) Via ./api/migration/v3alpha.sh. This picks up the changes since the last sync, in particular the major reformat in #8309. Risk level: Low (not used yet). Testing: bazel build @envoy_api//... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ c41cfbf6a33b8115a7e29a2b4a926aad4cd062be
5 years ago
import "google/protobuf/duration.proto";
import "google/protobuf/wrappers.proto";
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
api/config: use resource type annotations to provide type-to-endpoint. (#9566) Previously, type_to_endpoint.cc had a lot of hardcoding, which doesn't scale well with multiple API versions. See https://github.com/envoyproxy/envoy/pull/9526 for an example of the issues encountered. This patch switches to using explicit resource type annotations on service descriptors, which is great for documentation (previously this was sometimes given in comments, sometimes not), and allows for a reflection driven reverse map from resource type URL to endpoints to be built at runtime. Risk level: Low Testing: New unit tests for type_to_endpoint.cc and golden protoxform tests for the new annotations. Fixes #9454. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ cceab393664429a3063d787cf28cade3c8ab01c7
5 years ago
import "envoy/annotations/resource.proto";
[WiP] api: annotate files with package version status. (#10492) Part of https://github.com/envoyproxy/envoy/issues/10355, this patch introduces additional annotations to the API to support automatic inference (and developer documentation) of where the active developer editable version of a file is, and which files are frozen or machine generated. Risk level: Low (API annotations only) Testing: CI Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 4c5f4310bb8a19a38e5377d7a2d2dc6aa4560f47
5 years ago
import "udpa/annotations/status.proto";
import "udpa/annotations/versioning.proto";
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
import "validate/validate.proto";
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
option java_package = "io.envoyproxy.envoy.service.endpoint.v3";
api: options after import (#9413) In order to get file level move annotation, import has to be before options. Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ 062c895f499382ae61dead16db2a7e78b9146525
5 years ago
option java_outer_classname = "EdsProto";
option java_multiple_files = true;
option java_generic_services = true;
[WiP] api: annotate files with package version status. (#10492) Part of https://github.com/envoyproxy/envoy/issues/10355, this patch introduces additional annotations to the API to support automatic inference (and developer documentation) of where the active developer editable version of a file is, and which files are frozen or machine generated. Risk level: Low (API annotations only) Testing: CI Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 4c5f4310bb8a19a38e5377d7a2d2dc6aa4560f47
5 years ago
option (udpa.annotations.file_status).package_version_status = NEXT_MAJOR_VERSION_CANDIDATE;
api: options after import (#9413) In order to get file level move annotation, import has to be before options. Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ 062c895f499382ae61dead16db2a7e78b9146525
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
// [#protodoc-title: EDS]
// Endpoint discovery :ref:`architecture overview <arch_overview_service_discovery_types_eds>`
service EndpointDiscoveryService {
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
option (envoy.annotations.resource).type = "envoy.config.endpoint.v3.ClusterLoadAssignment";
api/config: use resource type annotations to provide type-to-endpoint. (#9566) Previously, type_to_endpoint.cc had a lot of hardcoding, which doesn't scale well with multiple API versions. See https://github.com/envoyproxy/envoy/pull/9526 for an example of the issues encountered. This patch switches to using explicit resource type annotations on service descriptors, which is great for documentation (previously this was sometimes given in comments, sometimes not), and allows for a reflection driven reverse map from resource type URL to endpoints to be built at runtime. Risk level: Low Testing: New unit tests for type_to_endpoint.cc and golden protoxform tests for the new annotations. Fixes #9454. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ cceab393664429a3063d787cf28cade3c8ab01c7
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
// The resource_names field in DiscoveryRequest specifies a list of clusters
// to subscribe to updates for.
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
rpc StreamEndpoints(stream discovery.v3.DiscoveryRequest)
returns (stream discovery.v3.DiscoveryResponse) {
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
}
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
rpc DeltaEndpoints(stream discovery.v3.DeltaDiscoveryRequest)
returns (stream discovery.v3.DeltaDiscoveryResponse) {
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
}
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
rpc FetchEndpoints(discovery.v3.DiscoveryRequest) returns (discovery.v3.DiscoveryResponse) {
option (google.api.http).post = "/v3/discovery:endpoints";
protoxform: format options generically (#9251) Instead of formatting options heuristically, which will erase new annotations without changing protoxform, use proto descriptor to format options, and enforce its order as well. Risk Level: Low Testing: CI Docs Changes: N/A Release Notes: N/A Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ dfe687d49574ef7eb1bf84867bf571e805a2bf97
5 years ago
option (google.api.http).body = "*";
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
}
}
api: split config from service defs for CDS/RDS/EDS/SRDS/TDS. (#9555) This allows for a clean separation of config/service in v3. This is a continuation of #9548. Risk level: Low Testing: bazel test //test/... Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ c3bddaee1912fcd1fedc4786aee830b2e4a7c599
5 years ago
// [#not-implemented-hide:] Not configuration. Workaround c++ protobuf issue with importing
// services: https://github.com/google/protobuf/issues/4221 and protoxform to upgrade the file.
message EdsDummy {
option (udpa.annotations.versioning).previous_message_type = "envoy.api.v2.EdsDummy";
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
}