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.
1342 Commits
2 Branches
0 Tags
18 MiB
Tag: Branch: Tree: bbc765afe5
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bbc765afe5'
${ noResults }
data-plane-api/envoy/admin/v3/mutex_stats.proto

34 lines
1.3 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.admin.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
[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";
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
import "udpa/annotations/versioning.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.admin.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
option java_outer_classname = "MutexStatsProto";
option java_multiple_files = true;
api: freeze of v2 API, cut v4alpha API. (#10672) This patch performs a major version freeze and bump by modifying package_version_status, using the tooling developed in #10636. Specifically: v2 APIs are frozen (except for where they are the latest in their package history and still active) v3 APIs are transitioned to be active Candidate v4alpha APIs are generated (not used by Envoy yet) Fixes #10355 Risk level: medium (entire API's files are modified, visually verified to ensure things look sane, all tests pass) Testing: CI Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ 549164c42cae84b59154ca4c36009e408aa10b52
5 years ago
option (udpa.annotations.file_status).package_version_status = ACTIVE;
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: MutexStats]
// Proto representation of the statistics collected upon absl::Mutex contention, if Envoy is run
// under :option:`--enable-mutex-tracing`. For more information, see the `absl::Mutex`
// [docs](https://abseil.io/about/design/mutex#extra-features).
//
// *NB*: The wait cycles below are measured by `absl::base_internal::CycleClock`, and may not
// correspond to core clock frequency. For more information, see the `CycleClock`
// [docs](https://github.com/abseil/abseil-cpp/blob/master/absl/base/internal/cycleclock.h).
message MutexStats {
update upda dependency (#9262) Signed-off-by: Lizan Zhou <lizan@tetrate.io> Mirrored from https://github.com/envoyproxy/envoy @ 4997d02fbf551e54bd569fd0e0ccbcf7e3362516
5 years ago
option (udpa.annotations.versioning).previous_message_type = "envoy.admin.v2alpha.MutexStats";
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
// The number of individual mutex contentions which have occurred since startup.
uint64 num_contentions = 1;
// The length of the current contention wait cycle.
uint64 current_wait_cycles = 2;
// The lifetime total of all contention wait cycles.
uint64 lifetime_wait_cycles = 3;
}