API: Unready Targets Dump

[ping-sun]

Description: Taking advantage of the new feature introduced in #12035, which introduced quick visibility for init managers to check unready targets, this pull request adds protobuf message for unready targets and enables admin to dump configs of unready targets. An example of config dump for listeners’ unready targets is given in this pull request.

Introduce InitDumpHandler with handlerInitDump method to help dump information of unready targets.
Add dumpUnreadyTargets function for init::manager.

The new proto introduced:

// Dumps of unready targets of envoy init managers. Envoy's admin fills this message with init managers,
// which provides the information of their unready targets.
message UnreadyTargetsDumps {
  // Message of unready targets information of an init manager.
  message UnreadyTargetsDump {
    // Name of the init manager. Example: "init_manager_xxx".
    string name = 1;

    // Names of unready targets of the init manager. Example: "target_xxx".
    repeated string target_names = 2;
  }

  // The dumps of unready targets of all init managers.
  repeated UnreadyTargetsDump unready_targets_dumps = 1;
}

[htuch]

Is this actually configuration? It's definitely implied by configuration when interpreted by Envoy, but I'm wondering if it belongs on a different endpoint. @envoyproxy/api-shepherds

[ping-sun]

Is this actually configuration? It's definitely implied by configuration when interpreted by Envoy, but I'm wondering if it belongs on a different endpoint. @envoyproxy/api-shepherds

I suppose it does not belong to an actual endpoint. This is just a protobuf message designed to show the unready targets in configs.

[htuch]

I think it's kind of weird to include as part of config dump, but I'll defer to what other @envoyproxy/api-shepherds reckon. @mattklein123 as well as he did the original config dump.

[mattklein123]

+1, can we spit this out somewhere else? This is not really config in the normal sense of the word. Maybe a new /init_manager or other endpoint?

[ping-sun]

got it. I will move it somewhere else, and create a new init_dump.proto

[lizan]

Sorry I'm late to this thread, I feel this should be part of config_dump, otherwise it will be hard to tell what config made the targets unready, querying two endpoints might end up in inconsistent (racy) dump.

[htuch]

Isn't this a problem that applies to the admin endpoint in general? If we query /config_dump and /clusters, we might see inconsistent output. Same goes for /listeners. Would it make sense to try solve this through some mechanism for batching, e.g. an API endpoint, rather than trying to atomically group things?

[lambdai]

I feel like /config_dump or the potential is an inspection endpoint.
The configs/targets are stale as soon as these init manager status are on the wire.

[ping-sun]

rst has been updated.

[ping-sun]

I've removed unready targets from config dumps and introduced a new init_dump to display that information. @mattklein123 @htuch

[lambdai]

Could you update the commit message reflecting the new init dump endpoint ?
And also in docs/root/version_history/current.rst

[ping-sun]

Could you update the commit message reflecting the new init dump endpoint ?
And also in docs/root/version_history/current.rst

Sure, Updated

[htuch]

/lgtm api

[htuch]

@lizan @dio will leave the rest of the PR for you folks, API LGTM.

[ping-sun]

I noticed that config_dump has been sealed in a unique class ConfigDumpHandler, so I followed this behavior and moved my init_dump in a new lib as well.