* Added PGV C++ generation support. This (hopefully temporarily)
abandons using native proto_library in favor of pgv_cc_proto_library.
We maintain build support for proto_library for the glorious future in
which we write a Bazel aspect to run PGV against the native
proto_library shadow graph.
* Replace min_len with min_bytes on strings, until PGV gets not-empty or
min_len support for C++.
* Various fixups for places where the PGV plugin objected to
annotations.
Signed-off-by: Harvey Tuch <htuch@google.com>
We'd like to add a metadata field to CDS and have it be accessible in Envoy through ClusterInfo and anywhere else general cluster info is available.
Signed-off-by: Matt Rice <mattrice@google.com>
1) Do RDS other than rate limit. This is large enough will do that next.
2) Manually order top level in v2 with better titles
3) Random other fixes
Note also that I'm going to manually reorder the protos in some cases in a
follow up so the docs make a bit more sense for a casual reader.
Signed-off-by: Matt Klein <mklein@lyft.com>
This patch adds an overview page introduced the v2 API concepts via a
worked example. Brought in the entire transitive dep set of protos from
bootstrap.proto, none of these have been cleaned up beyond the minimum
required to have them build under Sphinx.
Also added the ability to link to the underlying proto in messages/enums
from protodoc.py generated RST.
Signed-off-by: Harvey Tuch <htuch@google.com>
Updates the comment to reflect the design decision made in envoyproxy/envoy#1735 and renames subset_keys to subset_selectors.
My reasoning for the rename is that the field is all about determining how endpoints are grouped into subsets. Using the names of metadata keys in the endpoints is only one way and others might be added.
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
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>
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.
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.
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>
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).
This patch adds a static bootstrap proto that is expected to be provided
on the filesystem or command-line. This should enable Envoy to then
either fetch the rest of config from disk or reach out to the various
management servers for the rest of the APIs.
Fixes#93.
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.
While still supporting only 2 priorities today, this PR leaves room for
an additional finite number of priorities via enum extension. Since
we're not planning on reflecting arbitrary downstream priorities in the
upstream connection, we only expect a small number of priorities to be
useful in configuring routes and clusters.
Fixes#1.
As previously pointed out in #9, the empty string is not generally a useful
value in the xDS APIs, so can be be considered equivalent to an unset
field. This is now documented in principles in #28 as well.
Also replace google.protobuf.BytesValue with bytes.
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
Jose Ulises Nino Rivera
Matt Rice
Daniel Hochman
Matt Klein
Jonathan Oddy
Lizan Zhou
Piotr Sikora
Stephan Zuercher
jrajahalme
tschroed
Matt Klein