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>
* protodoc: make protodoc fast again.
Some low hanging fruit optimizations. This takes address.proto.rst build
from ~21s to ~1.7s.
Signed-off-by: Harvey Tuch <htuch@google.com>
These were lost in my backlog. Required a PGV fix for cross-package enum
validation to deal with the TODOs, see
https://github.com/lyft/protoc-gen-validate/issues/42.
Signed-off-by: Harvey Tuch <htuch@google.com>
* 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>
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>
I will defer RDS into another PR. I will also do another cleanup
pass over all of this later but want to get most of this in place
first.
Signed-off-by: Matt Klein <mklein@lyft.com>
This should provide an example of how to do the .proto doc linking,
refactoring and constraint addition for the full API.
Signed-off-by: Harvey Tuch <htuch@google.com>
* [#not-implemented-hide:] will hide a message/enum/field from docs.
* [#not-implemented-warn:] will add a "Not implemented yet" warning to a
message/enum/field.
* [#v2-api-diff:<text>] will add a note indicating v2 API difference to
a message/enum/field.
* Switched title annotation to [#protodoc-title:<text>] for consistency.
Signed-off-by: Harvey Tuch <htuch@google.com>
* Import @com_lyft_protoc_gen_validate for validate.proto annotations.
* Example annotation in address.proto (BindConfig).
* Process optional/required annotations in protodoc.
Signed-off-by: Harvey Tuch <htuch@google.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>
This tool will take a LDS response message with holes where opaque
filter configs should go, and fill them with the Struct equivalent of
the protos supplied for the filter configs. It emits both output
text proto and JSON.
To generate example output listeners.pb and listeners.json, run bazel
build //examples/service_envoy:listeners_files.