ads: workaround for proto descriptor issue, file reorg and cleanup. (#169)
Turns out that files with just service methods don't get loaded into the descriptor pool automatically in C++. So, needed to have some messages in ads.proto. Turns out this was a good opportunity to move some of the messages that were related to discovery out of base.proto. This shouldn't break the API, since everything is in the envoy.api.v2 packge space.pull/170/merge
htuch
7 years ago
committed by
GitHub
parent
05ac0aa056
commit
1bed17f9de
13 changed files with 92 additions and 90 deletions
@ -1,20 +0,0 @@ |
||||
syntax = "proto3"; |
||||
|
||||
package envoy.api.v2; |
||||
|
||||
import "api/base.proto"; |
||||
|
||||
import "google/api/annotations.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) { |
||||
} |
||||
} |
||||
@ -0,0 +1,68 @@ |
||||
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; |
||||
} |
||||
|
||||
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; |
||||
} |
||||
Loading…
Reference in new issue