diff --git a/envoy/admin/v2/config_dump.proto b/envoy/admin/v2/config_dump.proto deleted file mode 100644 index 45994d81..00000000 --- a/envoy/admin/v2/config_dump.proto +++ /dev/null @@ -1,35 +0,0 @@ -syntax = "proto3"; - -package envoy.admin.v2; - -import "google/protobuf/any.proto"; -import "envoy/api/v2/rds.proto"; - -import "gogoproto/gogo.proto"; - -// [#protodoc-title: ConfigDump] -// [#proto-status: draft] - -// The /config_dump admin endpoint uses this wrapper message to maintain and serve arbitrary -// configuration information from any component in Envoy. -// TODO(jsedgwick) In the future, we may want to formalize this further with an RPC for config_dump, -// and perhaps even with an RPC per config type. That strategy across all endpoints will allow for -// more flexibility w.r.t. protocol, serialization, parameters, etc. -message ConfigDump { - // This map is serialized and dumped in its entirety at the /config_dump endpoint. - // - // Keys should be a short descriptor of the config object they map to. For example, Envoy's HTTP - // routing subsystem might use "routes" as the key for its config, for which it uses the message - // RouteConfigDump as defined below. In the future, the key will also be used to filter the output - // of the /config_dump endpoint. - map configs = 1 [(gogoproto.nullable) = false]; -} - -// Envoy's RDS implementation fills this message with all currently loaded routes, as described by -// their RouteConnfiguration objects. Static routes configured in the bootstrap configuration are -// separated from those configured dynamically via RDS. This message is available at the -// /config_dump admin endpoint. -message RouteConfigDump { - repeated envoy.api.v2.RouteConfiguration static_route_configs = 1 [(gogoproto.nullable) = false]; - repeated envoy.api.v2.RouteConfiguration dynamic_route_configs = 2 [(gogoproto.nullable) = false]; -} diff --git a/envoy/admin/v2/BUILD b/envoy/admin/v2alpha/BUILD similarity index 70% rename from envoy/admin/v2/BUILD rename to envoy/admin/v2alpha/BUILD index 0e1ab5f2..9d2875da 100644 --- a/envoy/admin/v2/BUILD +++ b/envoy/admin/v2alpha/BUILD @@ -7,6 +7,9 @@ api_proto_library( srcs = ["config_dump.proto"], visibility = ["//visibility:public"], deps = [ + "//envoy/api/v2:cds", + "//envoy/api/v2:lds", "//envoy/api/v2:rds", + "//envoy/config/bootstrap/v2:bootstrap", ], ) diff --git a/envoy/admin/v2alpha/config_dump.proto b/envoy/admin/v2alpha/config_dump.proto new file mode 100644 index 00000000..0d68e890 --- /dev/null +++ b/envoy/admin/v2alpha/config_dump.proto @@ -0,0 +1,131 @@ +syntax = "proto3"; + +package envoy.admin.v2alpha; + +import "envoy/api/v2/cds.proto"; +import "envoy/api/v2/lds.proto"; +import "envoy/api/v2/rds.proto"; +import "envoy/config/bootstrap/v2/bootstrap.proto"; + +import "google/protobuf/any.proto"; + +import "gogoproto/gogo.proto"; + +// [#protodoc-title: ConfigDump] + +// The /config_dump admin endpoint uses this wrapper message to maintain and serve arbitrary +// configuration information from any component in Envoy. +// TODO(jsedgwick) In the future, we may want to formalize this further with an RPC for config_dump, +// and perhaps even with an RPC per config type. That strategy across all endpoints will allow for +// more flexibility w.r.t. protocol, serialization, parameters, etc. +message ConfigDump { + // This map is serialized and dumped in its entirety at the /config_dump endpoint. + // + // Keys should be a short descriptor of the config object they map to. For example, Envoy's HTTP + // routing subsystem might use "routes" as the key for its config, for which it uses the message + // RouteConfigDump as defined below. In the future, the key will also be used to filter the output + // of the /config_dump endpoint. + map configs = 1 [(gogoproto.nullable) = false]; +} + +// This message describes the bootstrap configuration that Envoy was started with. This includes +// any CLI overrides that were merged. Bootstrap configuration information can be used to recreate +// the static portions of an Envoy configuration by reusing the output as the bootstrap +// configuration for another Envoy. +message BootstrapConfigDump { + envoy.config.bootstrap.v2.Bootstrap bootstrap = 1 [(gogoproto.nullable) = false]; +} + +// Envoy's listener manager fills this message with all currently known listeners. Listener +// configuration information can be used to recreate an Envoy configuration by populating all +// listeners as static listeners or by returning them in a LDS response. +message ListenersConfigDump { + // This is the *version_info* in the last processed LDS discovery response. If there + // are only static bootstrap listeners, this field will be "". + string version_info = 1; + + // Describes a dynamically loaded cluster via the LDS API. + message DynamicListener { + // This is the per-resource version information. This version is currently taken from the + // *version_info* field at the time that the listener was loaded. In the future, discrete + // per-listener versions may be supported by the API. + string version_info = 1; + + // The listener config. + envoy.api.v2.Listener listener = 2; + } + + // The statically loaded listener configs. + repeated envoy.api.v2.Listener static_listeners = 2 [(gogoproto.nullable) = false]; + + // The dynamically loaded active listeners. These are listeners that are available to service + // data plane traffic. + repeated DynamicListener dynamic_active_listeners = 3 [(gogoproto.nullable) = false]; + + // The dynamically loaded warming listeners. These are listeners that are currently undergoing + // warming in preparation to service data plane traffic. Note that if attempting to recreate an + // Envoy configuration from a configuration dump, the warming listeners should generally be + // discarded. + repeated DynamicListener dynamic_warming_listeners = 4 [(gogoproto.nullable) = false]; + + // The dynamically loaded draining listeners. These are listeners that are currently undergoing + // draining in preparation to stop servicing data plane traffic. Note that if attempting to + // recreate an Envoy configuration from a configuration dump, the draining listeners should + // generally be discarded. + repeated DynamicListener dynamic_draining_listeners = 5 [(gogoproto.nullable) = false]; +} + +// Envoy's cluster manager fills this message with all currently known clusters. Cluster +// configuration information can be used to recreate an Envoy configuration by populating all +// clusters as static clusters or by returning them in a CDS response. +message ClustersConfigDump { + // This is the *version_info* in the last processed CDS discovery response. If there + // are only static bootstrap clusters, this field will be "". + string version_info = 1; + + // Describes a dynamically loaded cluster via the CDS API. + message DynamicCluster { + // This is the per-resource version information. This version is currently taken from the + // *version_info* field at the time that the cluster was loaded. In the future, discrete + // per-cluster versions may be supported by the API. + string version_info = 1; + + // The cluster config. + envoy.api.v2.Cluster cluster = 2; + } + + // The statically loaded cluster configs. + repeated envoy.api.v2.Cluster static_clusters = 2 [(gogoproto.nullable) = false]; + + // The dynamically loaded active clusters. These are clusters that are available to service + // data plane traffic. + repeated DynamicCluster dynamic_active_clusters = 3 [(gogoproto.nullable) = false]; + + // The dynamically loaded warming clusters. These are clusters that are currently undergoing + // warming in preparation to service data plane traffic. Note that if attempting to recreate an + // Envoy configuration from a configuration dump, the warming clusters should generally be + // discarded. + repeated DynamicCluster dynamic_warming_clusters = 4 [(gogoproto.nullable) = false]; +} + +// Envoy's RDS implementation fills this message with all currently loaded routes, as described by +// their RouteConfiguration objects. Static routes configured in the bootstrap configuration are +// separated from those configured dynamically via RDS. Route configuration information can be used +// to recreate an Envoy configuration by populating all routes as static routes or by returning them +// in RDS responses. +message RoutesConfigDump { + message DynamicRouteConfig { + // This is the per-resource version information. This version is currently taken from the + // *version_info* field at the time that the route configuration was loaded. + string version_info = 1; + + // The route config. + envoy.api.v2.RouteConfiguration route_config = 2; + } + + // The statically loaded route configs. + repeated envoy.api.v2.RouteConfiguration static_route_configs = 2 [(gogoproto.nullable) = false]; + + // The dynamically loaded route configs. + repeated DynamicRouteConfig dynamic_route_configs = 3 [(gogoproto.nullable) = false]; +} diff --git a/envoy/config/bootstrap/v2/BUILD b/envoy/config/bootstrap/v2/BUILD index 80736d98..af8cabfc 100644 --- a/envoy/config/bootstrap/v2/BUILD +++ b/envoy/config/bootstrap/v2/BUILD @@ -5,6 +5,7 @@ licenses(["notice"]) # Apache 2 api_proto_library( name = "bootstrap", srcs = ["bootstrap.proto"], + visibility = ["//visibility:public"], deps = [ "//envoy/api/v2:cds", "//envoy/api/v2:lds",