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>
Created new definitions in api_build_system.bzl that wrap
go_proto_library, go_grpc_library, and go_test. Changed rules in api/BUILD and
test/build/BUILD to use these new definitions. In the future these
definitions could be expanded upon for auto generation in api_proto_library.
Signed-off-by: Kyle Myerson <kmyerson@google.com>
Currently clusters can not open both HTTP1.1 and HTTP2 upstream
connections at the same time. When the new cluster option
"auto_http2" is set to "true", the cluster must open an HTTP2 upstream
connection if the downstream connection is HTTP2, and an HTTP1.1
upstream connection if the downstream connection is HTTP1.1. This option
is to have no effect if there is no corresponding downstream
connection.
This functionality removes the need to operate multiple clusters and
routing rules for them when the backends accept both HTTP1.1 and HTTP2
connections, and when the choice of the HTTP protocol is significant,
as with gRPC.
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
We need to track statistics in a client neutral way, since the Google
gRPC client doesn't have upstream stats. This will allow us to track the
gRPC status returned by the remote (or inferred from events such as
client timeouts).
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>
This is intended to capture some recent threads, it can grow as we learn
new lessons.
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
* Fix format.
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>
Included files that should be edited in order to generate the RSTs and DOCs when a new .proto is added to the project.
Signed-off-by: Gabriel <gsagula@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>
Add support for configuration of TCP, HTTP filters to support external authorization cluster.
The filter configuration references an external cluster which is expected to be running the grpc server that supports the service being defined by #296
Signed-off-by: Saurabh Mohan <saurabh+github@tigera.io>
jrajahalme
Ryan
Stephan Zuercher
Brian Pane
Bogdan Drutu
htuch
Hong Zhang
Nicholas Johns
Chris Roche
Taiki Ono
Dhi Aurrahman
ramaraochavali
Jose Ulises Nino Rivera
kmyerson
Matt Klein
Matt Rice
mandarjog
William Thurston
alyssawilk
Alexey Baranov
Gabriel Sagula
ljmatkins
William Chang
Saurabh Mohan
Reuven Lazarus
Andrew Dunham