Currently host level stats in clusters proto uses map so they are outputted in random order. This PR changes it to list so that the order is predictable.
Risk Level: Low
Testing: Added automated tests
Docs Changes: N/A
Release Notes: N/A
Signed-off-by: Rama <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ 69474b39878d74354a1fb0b14d41f362839540e8
Fixes the order of config_dump elements - bootstrap, clusters, listeners and routes will come in that order. Note that inside each of them, ordering is not guaranteed. This is a step in moving towards complete ordering.
Risk Level: Low
Testing: Added Automated tests
Docs Changes: Updated
Release Notes: N/A
Signed-off-by: Rama <rama.rao@salesforce.com>
Mirrored from https://github.com/envoyproxy/envoy @ 51d274be76119efff76fdafaa2f49fdd479f2def
I think this broke in a recent refactor.
Signed-off-by: Matt Klein <mklein@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 866597fcb8cc3cdd53a767d66755506036261f3c
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 the /clusters?format=json admin endpoint along with a proto representation of /clusters.
Risk Level: Low
Testing: Added a unit test for the new format.
Docs Changes: Added a brief description on the admin docs and linked to the more detailed proto definition.
Release Notes: Added release notes.
Fixes#2020
Signed-off-by: Matt Rice <mattrice@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 64605338ef040a949c5ea205bdd472a8fe42306c
This adds a new google.protobuf.Timestamp last_updated field to BootstrapConfigDump, ListenersConfigDump, ClustersConfigDump, and RoutesConfigDump, representing the time when the configs under that category were last updated.
Additionally, the ProdSystemTimeSource::instance_ singleton is passed through several layers of interfaces. This is to make testing easier, but I would love to find a workaround for injecting a MockSystemTimeSource closer to the point where it is needed in the tests.
Risk Level: Low
Testing:
Several tests were modified / updated to compare the dumped time (always 1234567890 seconds since epoch time) by using a MockSystemTimeSource which always returned 1234567890.
Recreated PR based off #3641.
Signed-off-by: James Buckland <jbuckland@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ a22d96046d5292d99bd7f3c4ccce5f05fb52ffc7
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
Validated the full push-to-master to data-plane-api, so this time it should work.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ bf1073f04db95b674575c9f96fc821a5537774b2
See envoyproxy/envoy#2771 for context
I will add documentation once the interfaces and placement of these things is settled. Current location (new admin package) was agreed upon as a good start with @htuch but i don't feel strongly about that or naming.
Signed-off-by: James Sedgwick <jsedgwick@lyft.com>