Provides a configuration point for a load balancer that can divide endpoints into subsets addressable by route metadata.
See discussion in envoyproxy/envoy#1279.
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
This is a fix for a potential race that exists in the gRPC
implementation today. Namely:
1. Envoy sends a DiscoveryRequest at X with resources {A, B}
2. Management server responds with DiscoveryResponse at X+1.
3. Envoy decides (for whatever reason) to change resources before
beceiving the X+1 response. It sends a DiscoveryRequest at X
with {A, B, C}.
4. Management server treats the X DiscoveryRequest update as a NACK
for the X+1 DiscoveryResponse.
Turns out that files with just service methods don't get loaded into the
descriptor pool automatically in C++. So, needed to have some messages
in ads.proto. Turns out this was a good opportunity to move some of the
messages that were related to discovery out of base.proto.
This shouldn't break the API, since everything is in the envoy.api.v2
packge space.
Needed for empty resource responses to allow the xDS API the response is
pointing at to be identified. In non-empty resource responses, the
type_url is embedded in the Any messages.
This is a design-level update to bootstrap.proto, that plumbs in the
remaining top-level config from v1. It will probably have some small
changes made beyond this as we implement.
Notable differences to v1 are:
* Static/dynamic resources are clearly delineated at top-level, clusters no longer belong to the ClusterManager object.
* Stats sinks are a repeated list of opaque configs, similar to filter.
* Some simplifications to object types, e.g. RLS no longer specifies type (do we want to preserve the v1 generality here?).
Also renamed RLDS back to RLS, I'll admit that it didn't make sense to
cram it into the xDS namespace, it's really a very distinct service on
the data plane and shouldn't be bundled with the control plane services.
Since we may want to use a resolver plugin in most places, it doesn't
make sense to have this strong separation between the two in the API.
Also bonus renumbering cleanup in LDS.
Previously, we had a complex way of inferring total error requests from
map value aggregation. This PR removes the error maps for now, providing
simple scalar totals instead. This will simplify
https://github.com/lyft/envoy/issues/1286.
We expect to add the error maps as an additional mechanism, orthogonal to
the scalar totals, later on, as standard proto extension.
For envoy/#1411
Adding it in a structured proto because in the long run I anticipate us wanting to have per-cluster port ranges we bind to and it makes sense to me if we're going to eventually allow the bootstrap and cluster config to interact that we stick all the interacting bits in another message.
Add code points for original dst service discovery and load balancer
types, as well as for the cleanup interval configuration option.
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
Since we expeceted both node name and cluster in v1, it makes sense to
continue providing this to management servers. We don't need to use
metadata for cluster if it is required.
At Google, we need to support cluster queries that contain ':', so this
seems a useful feature to retain in v2 as a means to do that (rather
than trying to retrofit this to the internal cluster naming in Envoy).
Stephan Zuercher
Piotr Sikora
Matt Rice
htuch
hennna
Gary Brown
Matt Rice
Neri Marschik
Jose Ulises Nino Rivera
alyssawilk
jrajahalme
Robert Faulk