Add an option to dump the current effective config file #2421
Comments
mattklein123
added
enhancement
mattklein123
changed the title
|
thats super great handy feature +100 |
|
+1000. Debugging config for outlier detection with istio/envoy has been pretty difficult without a way to see what the acutal configuration the envoy sidecar is using. |
|
+1 -- would love to be able to gauge whether perf problems I'm working on would impact Istio and other applications that have raised performance issues. Having a way to dump a config would hopefully make it easier to repro real world cases to ensure I'm optimizing for the right thing. |
|
+1 |
|
+1 @htuch any chance someone could take a look at this. Would love to be able to get a dump back in ADS form (or some other stable API) that we could rely on when writing complex integration tests in Istio to detect when configuration has propagated. |
|
I'll work on this - I'll try to prioritize it as there seems to be a lot of interest |
|
@gsagula is interested in taking a look. @jsedgwick can you coordinate with @gsagula and decide how to approach this? Please ping me on Slack for more detail. |
|
@htuch It makes more sense to assign it to @jsedgwick |
|
Cool, reassigned to @jsedgwick. |
|
+1 |
htuch
pushed a commit
that referenced
this issue
Mar 27, 2018
This is a step towards dumping configs in proto form. There is a new config_dump endpoint, which spits out all registered configs. It's pretty-printed JSON for now; obviously we can play with format/serialization. Anyone can add a config via the ConfigTracker object that hangs off Admin. ConfigTracker makes the whole thing RAII-y, so that the list of config providers is maintained opaquely. This means the end user doesn't have to worry about ownership, capturing this, etc. Contrast with current unenforced pair of addHandler/removeHandler. This sort of managed weak ownership can be useful all over envoy; just in this diff I left a comment where something like ConfigTracker would delete a bunch of fragile code and confusion. I will genericize it in a future diff though, so let's focus on the functionality here and try to punt on extended discussion of this component and its possibilities. To demonstrate all the structured admin/config dumping scaffolding, I implemented it all for routes. See the data-plane-api PR (envoyproxy/data-plane-api#532) for context. But you can see how other config_dump handlers and, hopefully, all admin endpoints can be turned into structured, arbitrarily consumable proto via this setup. Risk Level: Medium. New feature on admin subsystem, intended to be minimally intrusive into rest of server Testing: New + existing unit. Tested locally with sudo ./bazel-bin/source/exe/envoy-static -c examples/front-proxy/front-envoy.yaml Output looks like: https://gist.github.com/jsedgwick/3a46408a9728ccef9a63d32b4c463c2b Docs Changes: I put TODO doxme everywhere I plan to add docs once the code/API is agreed upon. I won't merge this PR until docs are in. Release Notes: TODO pending consensus on this PR Issues: Makes progress on #2421, #2172 API Changes:] envoyproxy/data-plane-api#532 Deprecated: Current routes endpoint should be considered marked for deletion, but I'll do that in a subsequent PR. There should be some nice cleanup in addition to code deletion with this change. Signed-off-by: James Sedgwick <[email protected]>
mattklein123
added a commit
that referenced
this issue
Apr 24, 2018
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 #2421 Part of #2172 Fixes #3141 Signed-off-by: Matt Klein <[email protected]>
mattklein123
added a commit
that referenced
this issue
May 8, 2018
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 #2421 Part of #2172 Fixes #3141 Signed-off-by: Matt Klein <[email protected]>
mattklein123
pushed a commit
to envoyproxy/data-plane-api
that referenced
this issue
May 8, 2018
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 envoyproxy/envoy#2421 Part of envoyproxy/envoy#2172 Fixes envoyproxy/envoy#3141 Signed-off-by: Matt Klein <[email protected]> Mirrored from https://github.com/envoyproxy/envoy @ ada758739907628b50079b9adfccf5481ec9fc5f
mattklein123
added a commit
that referenced
this issue
May 10, 2018
This completes initial implementation of the /config_dump admin endpoint, allowing for detailed display of the currently loaded Envoy configuration, including versions of each resource. Fixes #2421 Fixes #2172 Signed-off-by: Matt Klein <[email protected]>
mattklein123
added a commit
that referenced
this issue
May 11, 2018
This completes initial implementation of the /config_dump admin endpoint, allowing for detailed display of the currently loaded Envoy configuration, including versions of each resource. Note that this does not include output for EDS. That work is tracked in #3362. Fixes #2421 Fixes #2172 *Risk Level*: Low *Testing*: Unit/integration *Docs Changes*: Added *Release Notes*: Added Signed-off-by: Matt Klein <[email protected]>
mattklein123
pushed a commit
to envoyproxy/data-plane-api
that referenced
this issue
May 11, 2018
This completes initial implementation of the /config_dump admin endpoint, allowing for detailed display of the currently loaded Envoy configuration, including versions of each resource. Note that this does not include output for EDS. That work is tracked in envoyproxy/envoy#3362. Fixes envoyproxy/envoy#2421 Fixes envoyproxy/envoy#2172 *Risk Level*: Low *Testing*: Unit/integration *Docs Changes*: Added *Release Notes*: Added Signed-off-by: Matt Klein <[email protected]> Mirrored from https://github.com/envoyproxy/envoy @ a2a5fc1df1541ebe0b0cd761f3e77212dbf70e5f
Shikugawa
pushed a commit
to Shikugawa/envoy
that referenced
this issue
Mar 28, 2020
* fixing the plugins Signed-off-by: Kuat Yessenov <[email protected]> * ammend Signed-off-by: Kuat Yessenov <[email protected]> * update to use filter state Signed-off-by: Kuat Yessenov <[email protected]> * fixes Signed-off-by: Kuat Yessenov <[email protected]> * update to use simpler API Signed-off-by: Kuat Yessenov <[email protected]> * updates Signed-off-by: Kuat Yessenov <[email protected]> * forgot to initialize ints Signed-off-by: Kuat Yessenov <[email protected]> * second attempt Signed-off-by: Kuat Yessenov <[email protected]> * simplify Signed-off-by: Kuat Yessenov <[email protected]> * pull latest Signed-off-by: Kuat Yessenov <[email protected]> * fix bug Signed-off-by: Kuat Yessenov <[email protected]> * update formatting Signed-off-by: Kuat Yessenov <[email protected]> * merge fix Signed-off-by: Kuat Yessenov <[email protected]> * build fix Signed-off-by: Kuat Yessenov <[email protected]> * copy traffic direction Signed-off-by: Kuat Yessenov <[email protected]> * update envoy SHA Signed-off-by: Kuat Yessenov <[email protected]>
jpsim
added a commit
that referenced
this issue
Nov 28, 2022
Now that we've integrated with rules_xcodeproj and that's working well. Signed-off-by: JP Simard <[email protected]>
jpsim
added a commit
that referenced
this issue
Nov 29, 2022
Now that we've integrated with rules_xcodeproj and that's working well. Signed-off-by: JP Simard <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Would be great to be able to dump the effective envoy.json file at run time. When using xDS it can be tough to tell exactly what the configuration envoy thinks is being used. It would be handy for debugging that we could just take the config, tweak it, compare it, and maybe even run it outside of the xDS config environment.
something like
/dump_configfor the admin server would be great.The text was updated successfully, but these errors were encountered: