For envoy/#1411
Adding it in a structured proto because in the long run I anticipate us wanting to have per-cluster port ranges we bind to and it makes sense to me if we're going to eventually allow the bootstrap and cluster config to interact that we stick all the interacting bits in another message.
Add code points for original dst service discovery and load balancer
types, as well as for the cleanup interval configuration option.
Signed-off-by: Jarno Rajahalme <jarno@covalent.io>
Since we expeceted both node name and cluster in v1, it makes sense to
continue providing this to management servers. We don't need to use
metadata for cluster if it is required.
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.
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.
htuch
alyssawilk
jrajahalme
Robert Faulk
Shriram Rajagopalan
Matt Klein
tschroed
Dan Noé