* 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>
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.
This is a design-level update to bootstrap.proto, that plumbs in the
remaining top-level config from v1. It will probably have some small
changes made beyond this as we implement.
Notable differences to v1 are:
* Static/dynamic resources are clearly delineated at top-level, clusters no longer belong to the ClusterManager object.
* Stats sinks are a repeated list of opaque configs, similar to filter.
* Some simplifications to object types, e.g. RLS no longer specifies type (do we want to preserve the v1 generality here?).
Also renamed RLDS back to RLS, I'll admit that it didn't make sense to
cram it into the xDS namespace, it's really a very distinct service on
the data plane and shouldn't be bundled with the control plane services.
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.
This is useful in Travis CI (and also internally at Google in our CI) to
validate basic build/link of the protos.
This exposed a small issue with API compatibility. Since we don't have
additional package namespaces for each individual API, there was a
conflict between the RateLimit mesage in RLDS and RDS. The quick fix was
to move the RLDS message inside the response object (this is fine as
nobody is using the v2 RLDS yet, open to alternatives including per-xDS
API namespaces).
htuch
alyssawilk
Matt Klein
ramaraochavali
Piotr Sikora