This PR avoids a situation in which we were losing track of data plane requests as follows:
1. Management server asks Envoy to track load stats for cluster Foo in a LoadStatsResponse for a 10s period. Envoy resets stats for Foo.
2. After the 10s timer, Envoy responds with Foo's stats, resetting them.
3. Management server asks Envoy to track load stats for cluster Foo in a LoadStatsResponse for a 10s period. Envoy resets stats for Foo.
4. After the 10s timer, Envoy responds with Foo's stats, resetting them.
Between 2 and 3, any stats for Foo requests that arrive were previously unaccounted for. We resolve
this (in a relatively backward compatible way) by not making any protocol changes except to require
Envoy to not reset stats for already tracked clusters.
If we were to design LRS from scratch to avoid this, there are better approaches, e.g. making it a
periodic reporting service rather than request-response, but we probably already have a bunch of
existing users of LRS and don't want to break them.
Rist Level: Low
Testing: Modified load_stats_integration_test.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 27c99de910788c2c5ca95a87cee00e55a33da638
adds the required visibility rules and delegates the rest to the generic
api_proto_library. I tested the change by doing the following without
getting errors.
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'
I changed the BUILD files using the following commands.
/envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/api_proto_library(/api_proto_library_internal(/g'
envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/"api_proto_library"/"api_proto_library_internal"/g'
Signed-off-by: mickey <mickeyju@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4b871c0ab9350882271a490adcee44e613ed9807
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Found with buildifier.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e8964c83f359916ecbf9c01a03ade3c92aac479
This enables generating generic service stubs for all the data-plane-api
proto services when generating Java classes with protoc.
This is generally not needed when implementing a gRPC server but in our case we're implementing
it behind our legacy protobuf RPC framework which rely on these stubs. As far as I know the only negative
with enabling these is generating some potentially unnecessary Java classes.
Signed-off-by: Snow Pettersen <snowp@squareup.com>
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>
data-plane-api(CircleCI)
Snow Pettersen
Kuat
Piotr Sikora