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.

api/BUILD

@@ -19,6 +19,7 @@ api_proto_library(
     deps = [
         ":address",
         ":base",
+        ":discovery",
         ":cds",
         ":lds",
     ],
@@ -35,19 +36,6 @@ api_proto_library(
     srcs = ["tls_context.proto"],
 )
 
-api_proto_library(
-    name = "ads",
-    srcs = ["ads.proto"],
-    has_services = 1,
-    deps = [
-        ":base",
-        ":cds",
-        ":eds",
-        ":lds",
-        ":rds",
-    ],
-)
-
 api_proto_library(
     name = "cds",
     srcs = ["cds.proto"],
@@ -55,12 +43,20 @@ api_proto_library(
     deps = [
         ":address",
         ":base",
+        ":discovery",
         ":health_check",
         ":protocol",
         ":tls_context",
     ],
 )
 
+api_proto_library(
+    name = "discovery",
+    srcs = ["discovery.proto"],
+    has_services = 1,
+    deps = [":base"],
+)
+
 api_proto_library(
     name = "eds",
     srcs = ["eds.proto"],
@@ -68,6 +64,7 @@ api_proto_library(
     deps = [
         ":address",
         ":base",
+        ":discovery",
         ":health_check",
     ],
 )
@@ -89,6 +86,7 @@ api_proto_library(
     deps = [
         ":address",
         ":base",
+        ":discovery",
         ":tls_context",
     ],
 )
@@ -108,5 +106,8 @@ api_proto_library(
     name = "rds",
     srcs = ["rds.proto"],
     has_services = 1,
-    deps = [":base"],
+    deps = [
+        ":base",
+        ":discovery",
+    ],
 )

api/ads.proto

@@ -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) {
-  }
-}

api/base.proto

@@ -4,7 +4,6 @@ package envoy.api.v2;
 
 import "api/address.proto";
 
-import "google/protobuf/any.proto";
 import "google/protobuf/duration.proto";
 import "google/protobuf/struct.proto";
 import "google/protobuf/wrappers.proto";
@@ -118,54 +117,6 @@ message HeaderValueOption {
   google.protobuf.BoolValue append = 2;
 }
 
-// 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;
-}
-
 message ApiConfigSource {
   // APIs may be fetched via either REST or gRPC.
   enum ApiType {

api/bootstrap.proto

@@ -8,6 +8,7 @@ package envoy.api.v2;
 
 import "api/address.proto";
 import "api/base.proto";
+import "api/discovery.proto";
 import "api/cds.proto";
 import "api/lds.proto";
 

api/cds.proto

@@ -4,6 +4,7 @@ package envoy.api.v2;
 
 import "api/address.proto";
 import "api/base.proto";
+import "api/discovery.proto";
 import "api/health_check.proto";
 import "api/protocol.proto";
 import "api/tls_context.proto";

api/discovery.proto

@@ -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;
+}

api/eds.proto

@@ -3,6 +3,7 @@ syntax = "proto3";
 package envoy.api.v2;
 
 import "api/base.proto";
+import "api/discovery.proto";
 import "api/health_check.proto";
 
 import "google/api/annotations.proto";

api/filter/BUILD

@@ -7,6 +7,7 @@ api_proto_library(
     srcs = ["http_connection_manager.proto"],
     deps = [
         "//api:base",
+        "//api:discovery",
         "//api:protocol",
         "//api:rds",
     ],

api/filter/http_connection_manager.proto

@@ -3,6 +3,7 @@ syntax = "proto3";
 package envoy.api.v2.filter;
 
 import "api/base.proto";
+import "api/discovery.proto";
 import "api/protocol.proto";
 import "api/rds.proto";
 

api/lds.proto

@@ -8,6 +8,7 @@ package envoy.api.v2;
 
 import "api/address.proto";
 import "api/base.proto";
+import "api/discovery.proto";
 import "api/tls_context.proto";
 
 import "google/api/annotations.proto";

api/rds.proto

@@ -7,6 +7,7 @@ syntax = "proto3";
 package envoy.api.v2;
 
 import "api/base.proto";
+import "api/discovery.proto";
 
 import "google/api/annotations.proto";
 import "google/protobuf/duration.proto";

test/build/BUILD

@@ -6,8 +6,8 @@ api_cc_test(
     name = "build_test",
     srcs = ["build_test.cc"],
     proto_deps = [
-        "//api:ads",
         "//api:cds",
+        "//api:discovery",
         "//api:eds",
         "//api:hds",
         "//api:lds",

test/build/build_test.cc

@@ -1,12 +1,7 @@
 #include <iostream>
 #include <cstdlib>
 
-#include "api/cds.pb.h"
+#include "google/protobuf/descriptor.h"
-#include "api/eds.pb.h"
-#include "api/hds.pb.h"
-#include "api/lds.pb.h"
-#include "api/rls.pb.h"
-#include "api/rds.pb.h"
 
 // Basic C++ build/link validation for the v2 xDS APIs.
 int main(int argc, char *argv[]) {