syntax = "proto3"; package envoy.api.v2; import "api/base.proto"; import "google/protobuf/any.proto"; // See https://github.com/lyft/envoy-api#apis for a description of the role of // ADS and how it is intended to be used by a management server. ADS requests // have the same structure as their singleton xDS counterparts, but can // multiplex many resource types on a single stream. The type_url in the // DiscoveryRequest/DiscoveryResponse provides sufficient information to recover // the multiplexed singleton APIs at the Envoy instance and management server. service AggregatedDiscoveryService { // This is a gRPC-only API. rpc StreamAggregatedResources(stream DiscoveryRequest) returns (stream DiscoveryResponse) { } } // A DiscoveryRequest requests a set of versioned resources of the same type for // a given Envoy node on some API. message DiscoveryRequest { // The version_info provided in the request messages will be the version_info // received with the most recent successfully processed response or empty on // the first request. It is expected that no new request is sent after a // response is received until the Envoy instance is ready to ACK/NACK the new // configuration. ACK/NACK takes place by returning the new API config version // as applied or the previous API config version respectively. Each type_url // (see below) has an independent version associated with it. string version_info = 1; Node node = 2; // List of resources to subscribe to, e.g. list of cluster names or a route // configuration name. If this is empty, all resources for the API are // returned. LDS/CDS expect empty resource_names, since this is global // discovery for the Envoy instance. The LDS and CDS responses will then imply // a number of resources that need to be fetched via EDS/RDS, which will be // explicitly enumerated in resource_names. repeated string resource_names = 3; // Type of the resource that is being requested, e.g. // "type.googleapis.com/envoy.api.v2.ClusterLoadAssignment". This is implicit // in requests made via singleton xDS APIs such as CDS, LDS, etc. but is // required for ADS. string type_url = 4; // nonce corresponding to DiscoveryResponse being ACK/NACKed. See above // discussion on version_info and the DiscoveryResponse nonce comment. This // may be empty if no nonce is available, e.g. at startup or for non-stream // xDS implementations. string response_nonce = 5; } message DiscoveryResponse { string version_info = 1; repeated google.protobuf.Any resources = 2; // Canary is used to support two Envoy command line flags: // * --terminate-on-canary-transition-failure. When set, Envoy is able to // terminate if it detects that configuration is stuck at canary. Consider // this example sequence of updates: // - Management server applies a canary config successfully. // - Management server rolls back to a production config. // - Envoy rejects the new production config. // Since there is no sensible way to continue receiving configuration // updates, Envoy will then terminate and apply production config from a // clean slate. // * --dry-run-canary. When set, a canary response will never be applied, only // validated via a dry run. bool canary = 3; // Type URL for resources. This must be consistent with the type_url in the // Any messages for resources if resources is non-empty. This effectively // identifies the xDS API when muxing over ADS. string type_url = 4; // For gRPC based subscriptions, the nonce provides a way to explicitly ack a // specific DiscoveryResponse in a following DiscoveryRequest. Additional // messages may have been sent by Envoy to the management server for the // previous version on the stream prior to this DiscoveryResponse, that were // unprocessed at response send time. The nonce allows the management server // to ignore any further DiscoveryRequests for the previous version until a // DiscoveryRequest bearing the nonce. The nonce is optional and is not // required for non-stream based xDS implementations. string nonce = 5; }