I went through and reorganized things to make the v2 docs more
human browsable. I also did a few misc cleanups. There is a lot
more to do here which I'm hoping to find a contractor to pay to
work on, but this is a step in the right direction.
Signed-off-by: Matt Klein <mklein@lyft.com>
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>
Update documentation to match implementation in envoyproxy/envoy#2440.
Makes the WeightedCluster.total_weight field visible in documentation. Update ClusterWeight.weight and traffic shaping document to match.
Signed-off-by: Stephan Zuercher <stephan@turbinelabs.io>
Add listener_filter_chain to Listener, which is a list of individual
listener filters that make up the filter chain for sockets accepted
with the listener. These filters are run before any in the
'filter_chains', and these filters have the opportunity to manipulate
and augment the connection metadata that is used in connection filter
chain matching. Order matters as the filters are processed
sequentially right after a socket has been accepted by the listener,
and before a connection is created.
As an example the functionality controlled by Listener options
'use_original_dst' and 'use_proxy_proto' can be implemented as
listener filters instead of being hard-wired into Envoy's listener
logic. This makes also extensions (like proxy protocol v2) easier to
implement and deploy.
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
* 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>
In support of https://github.com/envoyproxy/envoy/issues/2200 and some
Google internal needs, we are planning on adding support to Envoy to
allow a configuration (or possibly build) driven decision on whether to
using the existing Envoy in-built Grpc::AsyncClient or
the Google C++ gRPC client library (https://grpc.io/grpc/cpp/index.html).
To move in this direction, the idea is we have the xDS ApiConfigSources,
rate limit service config and other filter configurations point at a
GrpcService object. This can be configured to use an Envoy cluster,
where Grpc::AsyncClient will orchestrate communication, or to contain
the config needed to establish a channel in Google C++ gRPC client
library.
Signed-off-by: Harvey Tuch <htuch@google.com>
As a source of entire Envoy version number. Will use this file in envoy
main repo as well.
By this change, document version string will be changed in development
version:
from: "1.6.0-data-plane-api-${GIT_SHA}"
to: "1.6.0.dev-data-plane-api-${GIT_SHA}"
And in release version, for example, in v1.6.0 release:
from: "1.6.0-tag-v1.6.0"
to: "tag-v1.6.0"
The significant change is dropping the first version number string like
"1.6.0-" in the release version document.
Signed-off-by: Taiki Ono <taiks.4559@gmail.com>
envoyproxy/envoy#2256 adds restrictions to the backing sources for xDS resources. This change documents those restrictions.
Signed-off-by: Jose Nino <jnino@lyft.com>
CertificateValidationContext.trusted_ca is not only for client
certificates, but also for server certs. Change the wording to "peer
certificates".
Also mention that verification is not enabled by default in docs for
UpstreamTlsContext.
Signed-off-by: Peter Schultz <peter.schultz@classmarkets.com>
This patch clarifies the relationship between the CLI flags for local
service configuration and the bootstrap node identifier, where these
concepts are also expressed.
Signed-off-by: Harvey Tuch <htuch@google.com>