As discussed and docced up here: envoyproxy/envoy#1980 (comment)
My one remaining concern with this approach is that the clusters all take a cluster config on start-up so they won't all get the benefits of primary/failover mechanics. It looks like static already doesn't get priorities so maybe it's meant to be a super simple start-up option but it seems like it still might benefit from the more advanced features.
For #1929
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Envoy decides to drop (circuit break, drop overload) at the cluster
rather than locality level.
This is a breaking change at the wire level, but the EDS load report API
has not yet been frozen.
Signed-off-by: Harvey Tuch <htuch@google.com>
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.
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.
This significantly simplifies EDS implementation in Envoy, as we can
have EDS updates propagate in the same way and with the same
gRPC/REST/filesystem watch infrastructure we use for LDS/RDS/CDS.
Add metadata to endpoints in EDS.
Allow routes to specify a metadata_match. WeightedClusters can further
specify an additional metadata_match based on weighting.
Log all metadata. It makes sense to have available to the logging
pipeline all metadata used during request processing, not just some
that is explicitly annotated. This then makes available the endpoint's
metadata for log consumption. The tradeoff is that this will increase
log sizes when metadata is plentiful. We may want to consider a way to
filter this in logs in the future.
Fixes#81 and #91.
We can dynamically discover service/method descriptors in Envoy, so we
don't need to generate any C++ stubs for this. This simplifies the
Google import and removes an unnecessary build output.
* Factor all subscription responses to DiscoveryResponse message with an Any
resource type. This further simplifies the Subscription interface in
the Envoy client, as it no longer needs to be templatized on the
response type.
* Replace version_info bytes type with string. This allows plain
strings to be used in JSON representations rather than base64 encoded
strings as required in the canonical proto3 translation of bytes.
* Clarify ACK/NACK semantics with version_info in comments.
Fixes#85.
This PR allows for easier implementation of a unified subscription model
in Envoy for gRPC/REST/inotify filesystem config updates:
* The DiscoveryRequest basically looks the same in all subscription APIs
today, so factored out to DiscoveryRequest.
* xDiscoveryResponse now uses a consistent convention. This will allow
C++ template level duck typing to populate the response in a single
implementation for all APIs. This is mostly relevant for the filesystem
watch implementation, where we need to map from resource names to file
paths, but could also make API server implementation easier
potentially.
This will be useful for Google and other site specific extension of the
resolving of both names and ports. For listeners, ports and bound
addresses can be expressed in a site-specific format. For upstreams,
host names can be resolved using the plugin.
alyssawilk
htuch
Robert Faulk
tschroed
Matt Klein
Rohit Bhoj