Without a distinction between the root and subdir, we can't watch for
symlink swaps that cover multiple layers.
Risk level: Low
Testing: additional test expects added.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 49b5a915324e44b9445e3fc5434e0deffaf3f94f
This PR provides the TDS API config. The implementation and docs will be
added in a followup, the idea is to unblock some projects that depend on
the details here.
Risk level: Low
Testing: @envoy_api build
Part of #6708
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ad2cacc4215477526dc61f838db8a7ddf55f4cc6
To support TDS and to provide operator flexibility in how it relates to
existing runtime layering, this PR introduces support for explicit
control over layering. This eliminates the distinguished role of
subdirectory and override_subdirectory, for example, in favor of
arbitrary disk overlay layers.
This PR deprecates the existing runtime configuration in favor of the
new layered variant.
As a bonus, the PR fixes some of the runtime stats and related docs.
Risk level: Low
Testing: various unit tests (including server_test) additions.
Part of #6708.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4dafba65baaf9769723f895761268eed31af629b
As a first step towards TDS, add support for proto/JSON representations of the runtime virtual file
system and plumb this into bootstrap.
"numerator" and "denominator" are now reserved keywords and can't be used in runtime keys; this
simplifies parsing significantly. It is not expected that these are widely used, due to the
difficulty of ensuring atomicity if representing fractions, but this is technically a runtime API
breaking change.
Risk level: Medium (due to the reserved word changes).
Testing: Unit and server tests added.
Part of #6708
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ eb699ab2d53aadf2c5a26ed02fcc1e7de1df7d8a
Reintroduce dispatcher stats previously reverted in #6649. Dispatcher stats are now gated on a new bootstrap config parameter, enable_dispatcher_stats, and disabled by default.
Risk Level: Low
Testing: Manually verified that config is respected (see #6582, this still requires integration tests).
Docs Changes: Included a note about how statsd doesn't play well with these high-volume histograms.
Signed-off-by: Dan Rosen <mergeconflict@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 481a127f5ade32e5590b4e8b8271576e44643082
* api: add proto options for java
* add ci for checking proto options
Signed-off-by: Penn (Dapeng) Zhang <zdapeng@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 02659d411332e9f20d229f482931c15304ea17fd
This is a follow up to #4726. In #4726, the access log path became optional, but the admin field
was not itself marked optional. This then led to server_fuzz_test trivially passing due to an early
PGV validation exception, and ~20 bugs being closed out by oss-fuzz. This PR completes the admin
optionality changes.
Risk Level: Low
Testing: Unit tests updated.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 86790c2367558160282d8b0afa1c5e4698e2fed3
Now that Envoy can function without an admin listener (#4486), there's no need to specify path or
even an empty admin message, so relax this requirement.
Risk Level: Low
Testing: bazel test //test/...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 570a403b8882ea34309bbe73209fee41417fa10e
Accept bootstrap configs that don't specify an admin port, and simply
don't run the admin server in that case.
Signed-off-by: Fred Douglas <fredlas@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0fb5efc50ef2b03ab0073f947ebfcf886c4a32b1
Add SDS feature in the doc.
For #4471
Risk Level: None
Testing: None
Docs Changes:
Yes, update the doc
Signed-off-by: Wayne Zhang <qiwzhang@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ef690f25af83a6bfcd6c2af4fe82a94918ccd161
To encourage users to use v2 configuration. Related to #2100.
Risk Level: N/A, documentation change.
Testing: N/A
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Taiki Ono <taiki-ono@cookpad.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1d46c75024ebe3c5449647f8bbb9d5dcc532f836
adds the required visibility rules and delegates the rest to the generic
api_proto_library. I tested the change by doing the following without
getting errors.
./ci/run_envoy_docker.sh './ci/do_ci.sh docs'
I changed the BUILD files using the following commands.
/envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/api_proto_library(/api_proto_library_internal(/g'
envoy/api$ find . -type f -name BUILD | xargs sed -i -e 's/"api_proto_library"/"api_proto_library_internal"/g'
Signed-off-by: mickey <mickeyju@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4b871c0ab9350882271a490adcee44e613ed9807
Added a health discovery service config option in bootstrap.proto.
There is skeleton code for this service in source/common/upstream/health_discovery_service.cc
and an integration test that tests connectivity between envoy running hds and a management server.
This work is for #1310.
Risk Level: Low
Signed-off-by: Lilika Markatou <lilika@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 1413d5697c9a6c5c43d7b3d23bdab23cc8c2604b
*Risk Level*: None
*Testing*: bazel test //test/...
*Docs Changes*: n/a
*Release Notes*: n/a
Found with buildifier.
Signed-off-by: Piotr Sikora <piotrsikora@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 0e8964c83f359916ecbf9c01a03ade3c92aac479
This change does several things:
1) Clarifies how we handle xDS version_info in responses and sets us up
for both top-level/transactional versions as well as per-resource
versions in the future.
2) Moves the config_dump admin endpoint to the v2alpha namespace so that
we can iterate on it in the future.
3) Fills out the config dump proto for the remaining resource types.
These are not implemented but are here to force a discussion about
how we want to handle versions moving forward.
4) Fixes RDS static config dump to actually work and add better tests.
5) Wire up version for the RDS config dump on a per-resource basis.
Once we agree on the general version semantics I will be following up
with dump capability of the remaining resource types.
Part of https://github.com/envoyproxy/envoy/issues/2421
Part of https://github.com/envoyproxy/envoy/issues/2172
Fixes https://github.com/envoyproxy/envoy/issues/3141
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ ada758739907628b50079b9adfccf5481ec9fc5f
I went through and reorganized things to make the v2 docs more
human browsable. I also did a few misc cleanups. There is a lot
more to do here which I'm hoping to find a contractor to pay to
work on, but this is a step in the right direction.
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>