This PR allows for easier implementation of a unified subscription model
in Envoy for gRPC/REST/inotify filesystem config updates:
* The DiscoveryRequest basically looks the same in all subscription APIs
today, so factored out to DiscoveryRequest.
* xDiscoveryResponse now uses a consistent convention. This will allow
C++ template level duck typing to populate the response in a single
implementation for all APIs. This is mostly relevant for the filesystem
watch implementation, where we need to map from resource names to file
paths, but could also make API server implementation easier
potentially.
While still supporting only 2 priorities today, this PR leaves room for
an additional finite number of priorities via enum extension. Since
we're not planning on reflecting arbitrary downstream priorities in the
upstream connection, we only expect a small number of priorities to be
useful in configuring routes and clusters.
Fixes#1.
* Allow multiple CIDR ranges to be provided for the prefix match. This
is useful when you have the same listener config in multiple subnets,
each subnet with the same suffix allocation of VIPs and the CIDR prefix
assigned by region/zone, e.g. when using the GCP subnetworks feature.
E.g. the service is on 0.0.0.37 in subnetworks 10.1.0.0 in US and
10.2.0.0 in Asia.
* Add source IP/port matching similar to existing TCP proxy filter. This
moves the route configuration from the TCP proxy filter to the
FilterChainMatch, making it also available to HTTP connections.
Fixes#6 and #36.
TCP proxy filter now has an idle timeout and the source match (and rest
of route match as well) are now in the FilterChainMatch in
https://github.com/lyft/envoy-api/pull/49.
Fixes#23, #45.
There are multiple uses for opaque metadata that is associated with the
specific listener/filter chain/route that a request matches on:
1. Logging. Similar to header values, we can log the metadata values.
A listener might belong to a higher level concept in the
configuration language that generated LDS protos, e.g. there might be
a rule identifier expressed. This metadata allows logs to reflect the
rule identifier.
2. Future custom stats backends might use metadata to guide where and
how stats are emitted. E.g. the metadata might include information
about which stats collector to emit to.
3. Proprietary filters can receive additional inputs via the metadata.
The per-filter metadata generalizes and replaces the opaque_config in
RDS ForwardAction.
The metadata is structured such that each filter's metadata is under the
reverse DNS namespace defined by the filter. Shared metadata may be
arranged by coordinating on the reverse DNS namespace.
As an example, the "envoy.http_connection_manager.access_log" filter
namespace is suggested to be used for HTTP access logging.
Fixes#33.
This tool will take a LDS response message with holes where opaque
filter configs should go, and fill them with the Struct equivalent of
the protos supplied for the filter configs. It emits both output
text proto and JSON.
To generate example output listeners.pb and listeners.json, run bazel
build //examples/service_envoy:listeners_files.
SPKI doesn't change when certificate is reissued, so it works better
with short-lived certificates.
This is also the same format as used in HTTP Public Key Pinning.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
As previously pointed out in #9, the empty string is not generally a useful
value in the xDS APIs, so can be be considered equivalent to an unset
field. This is now documented in principles in #28 as well.
Also replace google.protobuf.BytesValue with bytes.
This will be useful for Google and other site specific extension of the
resolving of both names and ports. For listeners, ports and bound
addresses can be expressed in a site-specific format. For upstreams,
host names can be resolved using the plugin.
htuch
tschroed
Lizan Zhou
Matt Klein
Rohit Bhoj
Piotr Sikora
Harvey Tuch