Until the SNI feature arrives, we need this in order to have a usable V2 API plane. I have retained the configuration format as is (comma separated port list, etc.) so as to get a working implementation first.
Signed-off-by: Shriram Rajagopalan <shriram@us.ibm.com>
Instead of having TOC elements like api/base.proto, we could add a title to protos with prefix
protodoc-title: <title>. These will be converted into page titles and stripped from the docs before rendering.
Signed-off-by: Shriram Rajagopalan <shriram@us.ibm.com>
This takes us to the point where address.proto format in a style fairly
similar to the existing docs. There's some missing bits, e.g. oneof/enum
support, nested messages, optional/required, these will come as later
PRs.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mostly Bazel hacking to get a protoc plugin running against the
proto_library graph. The Python plugin doesn't actually do any RST
generation yet, it just runs against each file and dumps the input
proto.
The tool can be run with:
bazel build //api --aspects \
tools/protodoc/protodoc.bzl%proto_doc_aspect --output_groups=rst
There's a snafu with unsandboxed runs in CI, where I can only get it to
work on direct leaf invocations, will fix this in a followup PR.
Signed-off-by: Harvey Tuch <htuch@google.com>
This PR follows thru on https://github.com/envoyproxy/envoy/issues/1873
on the data-plane-api side.
Also, update the Python validation script and added a test to ensure
this is captured in CI to avoid future bit rot.
Signed-off-by: Harvey Tuch <htuch@google.com>
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>
oneof doesn't provide any namespace scoping, so the names looked
too generic where they're used in implementations.
Signed-off-by: Greg Greenway ggreenway@apple.com
Provide the xDS protocol description. This is the contract between the Envoy implementation and management server.
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>
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.
jwfang
ccaraman
Matt Klein
ramaraochavali
tschroed
Lizan Zhou
Shriram Rajagopalan
htuch
Greg Greenway
Stephan Zuercher
Kuat
Daniel Hochman
Jose Ulises Nino Rivera
akonradi
Piotr Sikora
Matt Rice
hennna
Gary Brown
Matt Rice
Neri Marschik