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>
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>
This PR just fixes enough stuff to get the HTTP connection manager filter
docs building. I want to get this out as it conflicts with other inflight
PRs and some of the work can be split up. E.g., access logging with that
in flight PR.
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>
I changed my mind. This will work better with other projects later.
I will clean up all the stale docs in the website repo once we are
fully converted to the new system.
Signed-off-by: Matt Klein <mklein@lyft.com>
1) Allow release string to be specified by env var
2) Add pre-release warning text
This will be overriden during the official tagged doc builds in the main repo.
Signed-off-by: Matt Klein <mklein@lyft.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>
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>