Some sites where we consume HeaderValue, e.g. in Google gRPC client library metadata, require
non-empty keys as a precondition. This seems a general property; there shouldn't be any use case for
a header key that is empty.
Found with server_fuzz_test under oss-fuzz (issue 9373). As a bonus, also fixed another proto
descriptor crash that occurs with this corpus addition due to missing proto descriptor pool entries
in server_fuzz_test.
Risk level: Low
Testing: New server_fuzz corpus entry.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8ed7c157c4b672763ae74e526e69ef43dda52549
This allows users to specify literal socket options that may not be compatible with upstream kernels or available in precompiled Envoy binaries.
Risk Level: Low
Testing:
Existing tests pass plus new test to cover new functionality.
Partial fix for #3661.
Signed-off-by: Trevor Schroeder <trevors@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 20c0454545761c254180f77948304083406757be
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>
There are several main changes in this PR:
Create envoy.api.v2.core packages to break circular dependencies from xDS on to subpackages on to base protos.
Create individual packages for each filter and add independent versioning to each filter.
Add visibility constraints to prevent formation of dependency cycles.
Add gogoproto annotations to improve go code generation.
After moving xDS service definitions and top-level resource protos back to envoy.core.api.v2, cycles were created, since the second-level definitions depend on base protobuf definitions, and are in turn included from xDS; however xDS and base definitions are in the same package.
The solution is to split the base protos into another package, envoy.api.v2.core. That eliminates dependency cycles (validated using go-control-plane).
Added a few gogoproto annotations to improve golang code generation.
Signed-off-by: Kuat Yessenov <kuat@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>
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>
This patch clarifies the relationship between the CLI flags for local
service configuration and the bootstrap node identifier, where these
concepts are also expressed.
Signed-off-by: Harvey Tuch <htuch@google.com>
These were lost in my backlog. Required a PGV fix for cross-package enum
validation to deal with the TODOs, see
https://github.com/lyft/protoc-gen-validate/issues/42.
Signed-off-by: Harvey Tuch <htuch@google.com>
* Added PGV C++ generation support. This (hopefully temporarily)
abandons using native proto_library in favor of pgv_cc_proto_library.
We maintain build support for proto_library for the glorious future in
which we write a Bazel aspect to run PGV against the native
proto_library shadow graph.
* Replace min_len with min_bytes on strings, until PGV gets not-empty or
min_len support for C++.
* Various fixups for places where the PGV plugin objected to
annotations.
Signed-off-by: Harvey Tuch <htuch@google.com>
1) Do RDS other than rate limit. This is large enough will do that next.
2) Manually order top level in v2 with better titles
3) Random other fixes
Note also that I'm going to manually reorder the protos in some cases in a
follow up so the docs make a bit more sense for a casual reader.
Signed-off-by: Matt Klein <mklein@lyft.com>
* [#not-implemented-hide:] will hide a message/enum/field from docs.
* [#not-implemented-warn:] will add a "Not implemented yet" warning to a
message/enum/field.
* [#v2-api-diff:<text>] will add a note indicating v2 API difference to
a message/enum/field.
* Switched title annotation to [#protodoc-title:<text>] for consistency.
Signed-off-by: Harvey Tuch <htuch@google.com>
Instead of having TOC elements like api/base.proto, we could add a title to protos with prefix
protodoc-title: <title>. These will be converted into page titles and stripped from the docs before rendering.
Signed-off-by: Shriram Rajagopalan <shriram@us.ibm.com>
Turns out that files with just service methods don't get loaded into the
descriptor pool automatically in C++. So, needed to have some messages
in ads.proto. Turns out this was a good opportunity to move some of the
messages that were related to discovery out of base.proto.
This shouldn't break the API, since everything is in the envoy.api.v2
packge space.
Needed for empty resource responses to allow the xDS API the response is
pointing at to be identified. In non-empty resource responses, the
type_url is embedded in the Any messages.
Since we may want to use a resolver plugin in most places, it doesn't
make sense to have this strong separation between the two in the API.
Also bonus renumbering cleanup in LDS.
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.
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.
* 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.
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.
data-plane-api(CircleCI)
Matt Klein
Kuat
Piotr Sikora
Brian Pane
Jose Ulises Nino Rivera
htuch
William Chang
alyssawilk
Stephan Zuercher
Lizan Zhou
Shriram Rajagopalan
Matt Klein