New admin endpoint /tap/config_ids

Title: New admin endpoint /tap/config_ids

Description:

Currently, the /tap admin endpoint makes it easy to start trace captures on Envoy instances that you are familiar with the configuration for. However, as an Envoy operator unfamiliar with reading the Envoy /config_dump output, determining the valid config_id strings that can be used in a /tap request can be difficult. This is currently a sticking point at Uber, and I imagine is a common sticking point when getting started with the /tap endpoint.

Currently, the best way I have found for generating a list of config_ids is to hit the /config_dump endpoint and pipe the output into grep searching for the string "config_id". Unfortunately, this often results in long lists of seemingly duplicate config_ids, which is still unclear for an envoy operator unfamiliar with the Envoy configuration. One approach we could take to solve this issue is to flesh out the command pipeline above to parse the /config_dump output. While this would work, I imagine it would introduce some unneeded complexity and that this functionality could be better implemented elsewhere.

This change proposes an alternate solution to the problem of obtaining config_id strings by introducing a new admin endpoint at /tap/config_ids that would dump a newline-separated list of valid "config_id" strings for the given Envoy host.

Implementation:

Our proposed Implementation for this feature is to pull the config_id_map stored in the AdminHandler into its own singleton class and make it accessible to the AdminHandler and a new ConfigIdsHandler class. The ConfigIdsHandler class will have a handler method registered as an admin handler in the same way as other admin handlers like /config_dump.

Uber currently has the resources to take on the development of this feature, and we would appreciate feedback on our proposal!