This PR makes the following fatal by default:
from cluster.proto: ORIGINAL_DST_LB, tls_context, extension_protocol_options
from health_check.proto: use_http2
from route_components.proto: allow_origin regex, pattern, method, regex_match, value
from http_connection_manager.proto: operation_name
from trace.proto: HTTP_JSON_V1
from string.proto: regex
Risk Level: Medium (who knows who is using them)
Testing: test framework updates
Docs Changes: n/a
Release Notes: n/a
Originally #8847
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 33100e8bbeca057e23d07e46e42c51376700f872
Changing from relative name to absolute name, and fixing the fatal-by-defaults that were broken by the v3 switch.
The old way to allow fatal-by-defaults was
envoy.deprecated_features:proto_file.proto:field_name
the new way is
envoy.deprecated_features:full.namespace.field_name
When we switched to v3, all the hard-coded v2 names stopped working. This reinstates them via hopefully more permanent proto annotation.
The only remaining ugly bit is that unfortunately the full namespace and field name are the v3 versions even if the original config was v2. Between @htuch and I we should fix that before merging.
Risk Level: Medium
Testing: added new unit tests
Docs Changes: updated
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 156d7c90083c196a206c07fc03b2de6be8260bd3
This is a followup to #9301, where it was not possible to deprecate a
field on DiscoveryRequest as we were previously assuming identical v2/v3
transport protocols. After this deprecation, build_version can't appear
in v3 messages, and we need to convert back to a true v2
DiscoveryRequest prior to JSON serializing for REST.
There's more work to be done in the future, when we add new v3-only
fields, but this should work for 1.13.0. Future work tracked at
https://github.com/envoyproxy/envoy/issues/9619.
Risk level: Low
Testing: coverage of the behaviors for both gRPC and REST config sources
is provided by api_version_integration_test (failing previously as soon
as build_version was deprecated).
Fixes#9604
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0ee6212b02bdab7b3d66e868449ac93556e63118
Description: add auto_sni flag on cluster that executes to change sni field on sni field automatically.
Risk Level: Low
Testing: Unit Test
Docs Changes: Added
Release Notes: Added
Signed-off-by: shikugawa <rei@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 18ec59136e7a265556ca1d660dd7eb103182ea3a
Report extension information in the Node message.
Risk Level: Low
Testing: Unit Tests
Docs Changes: N/A
Release Notes: N/A
Fixes: #8332
Signed-off-by: Yan Avlasov <yavlasov@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ f5efe4a9bedf0ef7b03324f9bfda50118a0555c4
This PR extends #9468 to support a distinct notion of transport and
resource API version. The intuition here is that the opaque resources
(and their type URLs) can be delivered via either v2 or v3 xDS, and the
DiscoveryRequest etc. messages have their own versioning.
Currently, the v2 and v3 transport protocols are indistinguishable
modulo service endpoint. As v3 evolves, e.g. with #9301, differences
will be introduced. At this point it will be necessary to have enhanced
support in the gRPC mux and HTTP subscription modules to handle the
protocol differences.
This is technically a breaking v2 API change, but since the field it
breaks was only added today, I think it's safe to assume it is not in
use yet.
Risk level: Low
Testing: Integration tests added to validate service endpoint and type
URL selection based on transport/resource version.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ df0582765f8cc01a2f5901b068783f6bba9366f0
Description:
Move packages around for #8120 and #8121
Risk Level: Med around messing up build.
Testing: CI
Docs Changes: in API/STYLE.md
Release Notes: N/A (v3alpha is not in use yet)
Fixes#8120
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 1371f2ef46582a72b5b3971147bd87c534011731
Fixes server_fuzz_test fuzz bugs:
* QUIC upstream not implemented in prod, so the fuzzer removes the HTTP3 codec types for http health checks
* PGV validate throws a not yet implemented error on URIs. I removed this check for now and replaced with a TODO. If I catch the std::exception that is thrown and bypass it with a warning statement in the logs, we skip over other validations, which means that any fuzz test or user using this uri field will be in danger of failing because of other invalid fields @JimmyCYJ. PGV issue tracked: envoyproxy/protoc-gen-validate#303
Fixes OSS-Fuzz Issues:
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19614https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19689
Signed-off-by: Asra Ali <asraa@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ b7dcf083876f5d34d0dde5df535989a81dfa8023
It enables to specify API versioning for xDS for #8421, allow to write like this config
eds_cluster_config:
eds_config:
version: V2
api_config_source:
api_type: GRPC
grpc_services:
envoy_grpc:
cluster_name: eds_cluster
Risk Level: Low
Testing: unit test(maybe it is needed to add integration test)
Signed-off-by: shikugawa <rei@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ e3717b54b8d91d1862b096f73efbe96086862183
Modifies the protodoc tool to tag required duration fields as required.
Adds documentation around HttpHealthCheck.expected_statuses to clarify
what's expected of the Int64Range. Tags two Uint32Value fields as required
since they were implicitly treated as such (and generated missing field
exceptions when unset).
Risk Level: low
Testing: existing tests pass
Docs Changes: yes
Release Notes: n/a
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9263763e0a68961ee10fe63bc534d2546ed38376
In order to get file level move annotation, import has to be before options.
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 062c895f499382ae61dead16db2a7e78b9146525
Instead of formatting options heuristically, which will erase new annotations without changing protoxform, use proto descriptor to format options, and enforce its order as well.
Risk Level: Low
Testing: CI
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ dfe687d49574ef7eb1bf84867bf571e805a2bf97
Add a new field sts_service into GoogleGrpc call credential options which support Envoy to exchange token. See grpc/grpc#19032 and grpc/grpc#19587.
Signed-off-by: JimmyCYJ jimmychen.0102@gmail.com
Risk Level: Low
Testing: Unit test
Signed-off-by: Jimmy Chen <jimmychen.0102@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 46e65a498df7c920065a769860753076f9de16e7
This reverts commit 80aedc1c4a1aecc1616bd1563450c69d04e9568f.
Revert "config: rename NewGrpcMuxImpl -> GrpcMuxImpl (#8919)"
This reverts commit 6d505533304731fcc97041adce1f735431a703d7.
Revert "config: reinstate #8478 (unification of delta and SotW xDS), reverted by #8939 (#8974)"
This reverts commit a37522cf3f15639c8afeb7402f505044815fcf85.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 38adf1f02e95cf7a7078cdaa39032b62ca1e2ebf
This reverts commit 443bc3345b0e3db99a3df03d52f317697b99d5d7.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ df6d3bc453167a8e9fd29662280859b4f56f0af8
Wires up the upstream side of HTTP/1.1 header formatting and documents the header casing behavior.
Signed-off-by: Snow Pettersen <snowp@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 86420eb64a750fd6025cf5efc8b846c8fe63f0c9
Adds a configuration option that will convert all header keys into
Proper-Case. This is useful to allow Envoy to respond with headers
that match the casing of other systems, to ensure that the wire format
of responses is unchanged when migrating to Envoy.
Fixes#8463
Signed-off-by: Snow Pettersen <snowp@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 7846427d7aafb9e023c38bb6e704262f7c724c92
Generate or format next free field annotation via protoxform.
Risk Level: low
Testing: N/A
Docs Changes: N/A
Release Notes: N/A
Fixes#8429
Signed-off-by: Yi Tang <ssnailtang@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 986173ed516dcc1c3dea7db90659ed993d0aad75
This patch moves away from the paradigm of sed-style upgrading of every v2
package to v3alpha. Instead, an additional type analysis phase is
performed prior to protoxform by a protoc plugin known as the "type
whisperer".
The type whisperer produces structured type dependency information for
each .proto. The tools/type_whisperer/typedb_gen.py tool then knits
these together to provide an API-wide type dependency graph. This is
then used to determine which types need upgrading (either they have
breaking changes or transitively depend on types with such changes).
Only packages with upgraded types now undergo the v2 -> v3alpha
transition.
The API type database is checked into
source/common/config/api_type_db.pb. This may seem a strange location,
but in the future we will include the type database as a build artifact
for the Envoy binary, as it will be used by the reflection-based version
converter to find the type upgrade path for input proto.
Risk level: Low (the v3alpha protos are not used yet).
Testing: fix_format, manual inspection of diffs, bazel test //test/...,
docs build.
Part of #8082Fixes#8490
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ad57b58cfbb256af41a467260dce2a8013b7a7fa
Adds a max request and response header count limit with default value
100. This value is configurable in the bootstrap. Runtime configurations
envoy.reloadable_features.http_connection_manager.max_request_headers_count
and
envoy.reloadable_features.http_connection_manager.max_response_headers_count
override the default limit of 100.
Both the codecs and the HCM perform this check.
Signed-off-by: Asra Ali <asraa@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5c122a35ebd7d3f7678b0f1c9846c1e282bba079
This provides canonical BUILD formatting and puts protoxform in charge
of being able to determine import paths, without having to worry about
Bazel implications.
Part of #8082.
Risk level: Low
Testing: tools/proto_sync.py, visual inspection of diffs.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e53f40f0e5ccc84fca5cd350416fe0f2accf8229
As part of #8082, we want to be able to (1) automatically generate BUILD
files and (2) treat packages as atomic from a "upgrade / do not upgrade"
decision perspective. This is simplified by having our BUILD targets at
package granularity, since this is what the protoxform plugin operates
on.
This PR broadens the package-level treatment that was already introduced
for Go in #8003 to Python and C++. This simplifies BUILD files
significantly and opens the way to automated generation.
There is some technical debt introduced, since all visibility controls
have been removed. This is slated for reintroduction in
https://github.com/envoyproxy/envoy/issues/8491.
As a bonus (useful for BUILD file generation), also removed the
inconsistency in BUILD package target naming for packages in envoy.api.*
and envoy.type.*. E.g. //envoy/api/v2:v2 is now //envoy/api/v2:pkg.
Risk level: Low (but this will break internal builds and require BUILD
fixups to consuming projects).
Testing: bazel test //test/... @envoy_api//...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4e858f17fe08224c9c089240908ccd0c518e01a7
* [#not-implemented-warn:] was barely used and its purposes are better
served by [#not-implemented-hide:].
* [#proto-status:] was there for an earlier style of versioning, where
APIs were "frozen" or "draft", etc. Now we have semantic versioning
and a regular API clock as per #6271.
Part of #8371.
Risk level: Low (docs only).
Testing: Docs rebuild.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 2c4b6f2b3d614a15f312e34f4664ebeb96d07d12
This patch introduces a new tool, protoxform, that will be the basis of
the v2 -> v3 migration tooling. It operates as a Python protoc plugin,
within the same framework as protodoc, and provides the ability to
operate on protoc AST input and generate proto output.
As a first step, the tool is applied reflexively on v2, and functions as
a formatting tool. In later patches, this will be added to
check_format/fix_format scripts and CI.
Part of #8082.
Risk level: medium (it's possible that some inadvertent wire changes
occur, if they do, this patch should be rolled back).
Testing: manual inspection of diff, bazel test //test/..., some
grep/diff scripts to ensure we haven't lost any comments.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 08b123a8321d359ea66cbbc0e2926545798dabd3
* Move trailing detached comments that protoc ignores to some anchored place. In the near future,
this will be enforced by check_format.
* Remove comments on reserved fields; we won't be using reserved in v3 and it's a bit of a pain
preserving them.
Risk level: Low
Testing: Docs build, diff inspection, comparison against output of proto transform tool.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 22712d26c427091a47324b5f05fd0b493ee4be01
Some example regexes were rendered incorrectly on envoyproxy.io. I chose
to try to find all the example regexes and make them literal text. This
way the regexes are syntactically correct both in the raw proto and on
the doc site. Also found an H2 protocol option with a missing paragraph
due to a blank line vs. empty comment line.
Risk: low, comment-only
Testing: n/a
Docs: updated
Release Notes: n/a
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 35b459f064ff465fc9f0f04a3f0e2adf7f85a5bc
Remove gogoproto annotations. They can be replaced with a custom gogoproto compiler (e.g. something like https://github.com/gogo/googleapis/tree/master/protoc-gen-gogogoogleapis). I have an experimental version of it to validate that it's possible to re-apply important annotations in the compiler.
Risk Level: low
Testing: builds
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ e7f0b7176efdc65f96eb1697b829d1e6187f4502
Fixes#7982
Defines a package level proto library and its associated internal go_proto_library.
Deletes all existing api_go_proto_library, api_go_grpc_library, and go_package annotations in protos (they are not required and pollute the sources).
I deliberately avoided touching anything under udpa since it's being moved to another repository.
Risk Level: low
Testing: build completes
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d504fde0ffd97017d1ddff8caa9a3b46bba9ae48
Omit the node identifier from subsequent discovery requests on the same stream.
Restricted to non-incremental xDS for tractability.
Risk Level: low, affects xDS protocol but guarded by an option
Testing: Unit/integration tests are updated
Docs Changes: xDS spec clarification
Release Notes: omit the node identifier from subsequent discovery requests
Fixes: #7860
Signed-off-by: Kuat Yessenov <kuat@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 8e07e8297d7d5e68cf6d6d7e49ba98d2500cdef7
data-plane-api(CircleCI)