At Google, we need to support cluster queries that contain ':', so this
seems a useful feature to retain in v2 as a means to do that (rather
than trying to retrofit this to the internal cluster naming in Envoy).
* rds: add source IP and (generated) cookie hash policies.
There is room to grow the affinity policy now to arbitrary hashing on
connection properties (e.g. 3 tuple, 5 tuple, etc.) but we only care
about source IP address today.
Fixes#69.
* Clarify TTL wording.
* Document passive vs. generated cookie affinity behaviors.
This significantly simplifies EDS implementation in Envoy, as we can
have EDS updates propagate in the same way and with the same
gRPC/REST/filesystem watch infrastructure we use for LDS/RDS/CDS.
We've committed to a bunch of work (and will continue to) beyond just
adding proto APIs and gRPC in v2. This PR is a move towards being more
systematic about tracking this going forward.
Direction is implied at the C++ type level, putting this in the config
is redundant and can making changes to the C++ implementations difficult
to synchronize between binary and config.
Fixes#63.
Rename ForwardAction to RouteAction as requests are not really "forwarded". There is fair amount of mutation, traffic splitting, neither of which implies "forwarding". c.f. Istio route rules.
Add metadata to endpoints in EDS.
Allow routes to specify a metadata_match. WeightedClusters can further
specify an additional metadata_match based on weighting.
Log all metadata. It makes sense to have available to the logging
pipeline all metadata used during request processing, not just some
that is explicitly annotated. This then makes available the endpoint's
metadata for log consumption. The tradeoff is that this will increase
log sizes when metadata is plentiful. We may want to consider a way to
filter this in logs in the future.
Fixes#81 and #91.
This patch adds a static bootstrap proto that is expected to be provided
on the filesystem or command-line. This should enable Envoy to then
either fetch the rest of config from disk or reach out to the various
management servers for the rest of the APIs.
Fixes#93.
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).
When doing logging to RPC endpoints in proto format we need to know two
config details:
The RPC endpoint. This is a string like the path, but rather than
semantic overloading make this explicit.
Custom headers to include. We'll populate all of the names fields in
the AccessLog proto but users can also specify custom request and
response headers they want to log.
* Factor all subscription responses to DiscoveryResponse message with an Any
resource type. This further simplifies the Subscription interface in
the Envoy client, as it no longer needs to be templatized on the
response type.
* Replace version_info bytes type with string. This allows plain
strings to be used in JSON representations rather than base64 encoded
strings as required in the canonical proto3 translation of bytes.
* Clarify ACK/NACK semantics with version_info in comments.
Fixes#85.
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.
htuch
alyssawilk
Robert Faulk
Shriram Rajagopalan
Matt Klein
tschroed
Dan Noé
Lizan Zhou
Rohit Bhoj