Due to there's actually no `HTTP/1.1` with gRPC format link. To avoid misunderstanding, I've adjusted the sequence and placed the **similar** wire format in gRPC over HTTP/2. The updated link is equivalent to wire format link in gRPC guide.
Signed-off-by: Tzu-Chiao Yeh <su3g4284zo6y7@gmail.com>
We are changing the procedure to require contributors to add
release notes directly to this repo as they do changes. It's
too much work for the releaser to transfer them over. I'm
going to do this for 1.6.0 but I'm putting this stub in here
so that any ungoing changes that are going to sneak into 1.6.0
can get added directly.
Signed-off-by: Matt Klein <mklein@lyft.com>
See envoyproxy/envoy#2771 for context
I will add documentation once the interfaces and placement of these things is settled. Current location (new admin package) was agreed upon as a good start with @htuch but i don't feel strongly about that or naming.
Signed-off-by: James Sedgwick <jsedgwick@lyft.com>
This is a follow-up PR of #325.
I mistook to add an unnecessary field here. What actually we need is just making dog_statsd_specifier oneof field, not adding tcp_cluster_name field.
We can safely drop this field because users has ended up with
initializing errors if they had specified this field.
[critical][main] source/server/server.cc:71] error initializing configuration '/envoy.yaml': Address must be a socket or pipe
This field has
never been used in envoy repo: 7d03b231c7/source/server/config/stats/dog_statsd.cc (L19-L23)
Signed-off-by: Taiki Ono <taiki-ono@cookpad.com>
Add an option "freebind" in LDS for listeners and the BindConfig which
is used for outgoing upstream connections. If true, set IP_FREEBIND
socket option. Defaults to false.
PR description will be updated with Envoy implementation PR# once it is
created.
Signed-off-by: Dan Noé <dpn@google.com>
Unhide the request_headers_to_add, response_headers_to_add, and response_headers_to_remove fields in ClusterWeight. Update HTTP conn manager docs related to same.
Doc update for envoyproxy/envoy#2765.
Signed-off-by: Stephan Zuercher stephan@turbinelabs.io
Add a "transparent" option to Listener to set the SOL_IP/IP_TRANSPARENT option on listen sockets, which allows using Envoy with the iptables TPROXY target.
Unlike the iptables REDIRECT target, TPROXY allows preserving both the source and destination IP addresses and ports of accepted connections.
API changes for: envoyproxy/envoy#2719
Signed-off-by: Romain Lenglet <romain@covalent.io>
* tcp proxy: add metadata_match to tcp proxy config
This should allow the tcp proxy to target a specific subset of endpoints
in a cluster by matching on the metadata, similar to what is currently
possible in the http_connection_manager filter.
See https://github.com/envoyproxy/envoy/issues/2696
Signed-off-by: Snow Pettersen <snowp@squareup.com>
V1 configuration does not support ip tagging. This pr cleans references to IP Tagging in V1 configs.
Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>
1) Add ability to runtime filter to configure default, divisor, and
whether independent randomness is used.
2) Also add LE to the comparison filter.
Signed-off-by: Matt Klein <mklein@lyft.com>
In the proxy we've added an Unauthorized response flag. This PR adds the same to filter access logs.
Once this PR is merged it will be possible to set the flag in source/common/access_log/grpc_access_log_impl.cc
See also, comment in envoyproxy/envoy#2415
Signed-off-by: Saurabh Mohan <saurabh+github@tigera.io>
This enables generating generic service stubs for all the data-plane-api
proto services when generating Java classes with protoc.
This is generally not needed when implementing a gRPC server but in our case we're implementing
it behind our legacy protobuf RPC framework which rely on these stubs. As far as I know the only negative
with enabling these is generating some potentially unnecessary Java classes.
Signed-off-by: Snow Pettersen <snowp@squareup.com>
Updates the L7 IP tagging filter proto, v1 configuration documentation and overview documentation.
Signed-off-by: Constance Caramanolis <ccaramanolis@lyft.com>
v2 api changes: Use oneof to specify header match options, based on value(exact_match), regex or range.
The existing value and regex fields will be deprecated. Use the header_match_specfier oneof instead.
Add a new range.proto (envoy.type.v2) for the range type definition.
The SInt64Range message is defined in envoy.type.v2 range.proto.
It consists of start and end (inclusive, exclusive) sint64 values.
v1 api: Add a range_match object to the route headers json. Presence of this object indicates range based route match.
Example: For the below route config:
{
"prefix": "/",
"cluster": "PartitionB",
"name": "PartitionKey",
"range_match": { "start": 0, "end": 10}
}
In the incoming request, if the PartitionKey header value = 0, route match succeeds. Route match fails if the header value = 10, -10, "somestring".
This feature can be used for request routing with Service Fabric stateful services, to route to the desired partition with the [ranged partitioning scheme](https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-concepts-partitioning#ranged-partitioning-scheme)
Signed-off-by: Kavya Kotacherry <kavyako@microsoft.com>
This PR adds a new section to the Getting Started guide entitled "Other Use Cases" which show how Envoy can be used in specific situations. The thought is that users may want to use an Envoy distribution instead of Envoy itself for specific scenarios.
I also added a tutorial on how to use the open source Ambassador project to deploy Envoy as an API Gateway in Kubernetes, with an example that mirrors the google smoketest that is also used in the getting started.
Signed-off-by: Richard Li <richard@datawire.io>
There is no way to modify the response of PING on a running Redis server without restarting it. This makes it painful to terminate an instance. All inflight requests plus requests until ejection by active or passive healthcheck will fail.
Signed-off-by: Daniel Hochman <danielhochman@users.noreply.github.com>
this patch adds support for dynamically generating redirect msg based on
a request received by modifying the matched prefix or path.
ref: envoyproxy/envoy#2343
Signed-off-by: Madhavan Balasubramanian <bmadhavan@ebay.com>
Fixes issue #396. Once this is approved, will make Envoy side changes.
Signed-off-by: Rama rama.rao@salesforce.com
Signed-off-by: Rama <rama.rao@salesforce.com>