Changes: Fixes coverage test hang.
No change to core logic from #6692.
Signed-off-by: Karthik Reddy <rekarthik@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 27b3e48e8d754dcb956dca58888c7dbfde7ceec8
total_issued_requests field tracks the count of requests issued since
the last report. This field will be used for global load balancing
decisions.
Envoy maintains a stats counter rq_total to track total
requests made. By latching this counter when load reporting period
begins, we are able to count the total requests issued in a load
reporting interval. This information is then used to populate the field
total_issued_requests.
Risk Level: Low
Testing: //test/integration:load_stats_reporter passes.
Signed-off-by: Karthik Reddy <rekarthik@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ cdddf54e8548036703ee928335a44c3b503b988b
This new field gives LRS management server the extra info that two clusters may be using the same set of hosts to serve, and it's the management server's call whether to aggregate on the clusterStats.
Risk Level: LOW (new field)
Testing: unit test
Fixes#5986
Signed-off-by: Xin Zhuang <stevenzzz@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f5bb174c5f2f598df497cec04b0e144af9612570
* api: add proto options for java
* add ci for checking proto options
Signed-off-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 02659d411332e9f20d229f482931c15304ea17fd
Description: This field is used to carry opaque and implementation
dependent information of the upstream endpoints. The information may
be used by management server for debugging purposes.
Example: Consider a requirement of per 'user' load stastics for
debugging. Envoy will embed user info into the metadata field for
every upstream endpoint it sends load to. This user information will
be used by management server for debugging.
Sample message:
message ClusterStats {
cluster_name = ...
message UpstreamLocalityStats {
locality = ...
message UpstreamEndpointStats {
address = "endpoint1"
metadata = { "user" : "alice"}
...
}
message UpstreamEndpointStats {
address = "endpoint1"
metadata = { "user" : "bob"}
...
}
message UpstreamEndpointStats {
address = "endpoint2"
metadata = { "user" : "alice"}
...
}
message UpstreamEndpointStats {
address = "endpoint3"
metadata = { "user" : "bob"}
...
}
}
}
Risk Level: Low
Testing: Compiles successfully.
Signed-off-by: Karthik Reddy <rekarthik@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8d8cb4a7c63b74633b0b459af9104143b13f657f
This PR contains changes to implement feature requested in issue #3823
- Adding DropOverload in eds policy which can be used to specify
drop_percentage per category.
- Adding DroppedRequests in load_report which can report deliberately
dropped requests for each category.
Signed-off-by: vishalpowar <vishal.powar@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 3ee3aa34d826fa1783c201fbf99dfec3a21eed53
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
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)
Daniel Hochman
Kuat