Mpuncel/hedging impl

.gitignore

@@ -5,6 +5,7 @@ BROWSE
 *.bzlc
 .cache
 .classpath
+.clwb/
 /ci/bazel-*
 /ci/prebuilt/thirdparty
 /ci/prebuilt/thirdparty_build

WORKSPACE

@@ -15,7 +15,7 @@ load("@envoy_api//bazel:repositories.bzl", "api_dependencies")
 
 api_dependencies()
 
-load("@io_bazel_rules_go//go:def.bzl", "go_register_toolchains", "go_rules_dependencies")
+load("@io_bazel_rules_go//go:deps.bzl", "go_register_toolchains", "go_rules_dependencies")
 
 go_rules_dependencies()
 

api/XDS_PROTOCOL.md

@@ -288,35 +288,33 @@ admin:
 
 ### Incremental xDS
 
-Incremental xDS is a separate xDS endpoint available for ADS, CDS and RDS that
-allows:
-
-  * Incremental updates of the list of tracked resources by the xDS client.
-    This supports Envoy on-demand / lazily requesting additional resources. For
-    example, this may occur when a request corresponding to an unknown cluster
-    arrives.
-  * The xDS server can incrementally update the resources on the client.
-    This supports the goal of scalability of xDS resources. Rather than deliver
-    all 100k clusters when a single cluster is modified, the management server
-    only needs to deliver the single cluster that changed.
-
-An xDS incremental session is always in the context of a gRPC bidirectional
+Incremental xDS is a separate xDS endpoint that:
+
+  * Allows the protocol to communicate on the wire in terms of resource/resource
+    name deltas ("Delta xDS"). This supports the goal of scalability of xDS
+    resources. Rather than deliver all 100k clusters when a single cluster is
+    modified, the management server only needs to deliver the single cluster
+    that changed.
+  * Allows the Envoy to on-demand / lazily request additional resources. For
+    example, requesting a cluster only when a request for that cluster arrives.
+
+An Incremental xDS session is always in the context of a gRPC bidirectional
 stream. This allows the xDS server to keep track of the state of xDS clients
-connected to it. There is no REST version of Incremental xDS.
+connected to it. There is no REST version of Incremental xDS yet.
 
-In incremental xDS the nonce field is required and used to pair a
-[`IncrementalDiscoveryResponse`](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/discovery.proto#discoveryrequest)
-to a [`IncrementalDiscoveryRequest`](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/discovery.proto#discoveryrequest)
+In the delta xDS wire protocol, the nonce field is required and used to pair a
+[`DeltaDiscoveryResponse`](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/discovery.proto#deltadiscoveryresponse)
+to a [`DeltaDiscoveryRequest`](https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/discovery.proto#deltadiscoveryrequest)
 ACK or NACK.
 Optionally, a response message level system_version_info is present for
 debugging purposes only.
 
-`IncrementalDiscoveryRequest` can be sent in 3 situations:
+`DeltaDiscoveryRequest` can be sent in 3 situations:
   1. Initial message in a xDS bidirectional gRPC stream.
-  2. As an ACK or NACK response to a previous `IncrementalDiscoveryResponse`.
+  2. As an ACK or NACK response to a previous `DeltaDiscoveryResponse`.
      In this case the `response_nonce` is set to the nonce value in the Response.
      ACK or NACK is determined by the absence or presence of `error_detail`.
-  3. Spontaneous `IncrementalDiscoveryRequest` from the client.
+  3. Spontaneous `DeltaDiscoveryRequest` from the client.
      This can be done to dynamically add or remove elements from the tracked
      `resource_names` set. In this case `response_nonce` must be omitted.
 
@@ -326,8 +324,8 @@ client spontaneously requests the "wc" resource.
 
 ![Incremental session example](diagrams/incremental.svg)
 
-On reconnect the xDS Incremental client may tell the server of its known resources
-to avoid resending them over the network.
+On reconnect the Incremental xDS client may tell the server of its known
+resources to avoid resending them over the network.
 
 ![Incremental reconnect example](diagrams/incremental-reconnect.svg)
 

api/bazel/repository_locations.bzl

@@ -1,8 +1,8 @@
-BAZEL_SKYLIB_RELEASE = "0.6.0"
-BAZEL_SKYLIB_SHA256 = "eb5c57e4c12e68c0c20bc774bfbc60a568e800d025557bc4ea022c6479acc867"
+BAZEL_SKYLIB_RELEASE = "0.7.0"
+BAZEL_SKYLIB_SHA256 = "2c62d8cd4ab1e65c08647eb4afe38f51591f43f7f0885e7769832fa137633dcb"
 
-GOGOPROTO_RELEASE = "1.2.0"
-GOGOPROTO_SHA256 = "957c8f03cf595525d2a667035d9865a0930b3d446be0ab6eb76972934f925b00"
+GOGOPROTO_RELEASE = "1.2.1"
+GOGOPROTO_SHA256 = "99e423905ba8921e86817607a5294ffeedb66fdd4a85efce5eb2848f715fdb3a"
 
 OPENCENSUS_RELEASE = "0.1.0"
 OPENCENSUS_SHA256 = "4fd21cc6de63d7cb979fd749d8101ff425905aa0826fed26019d1c311fcf19a7"

api/envoy/admin/v2alpha/server_info.proto

@@ -128,4 +128,7 @@ message CommandLineOptions {
 
   // See :option:`--restart-epoch` for details.
   uint32 restart_epoch = 24;
+
+  // See :option:`--cpuset-threads` for details.
+  bool cpuset_threads = 25;
 }

api/envoy/api/v2/cds.proto

@@ -36,8 +36,7 @@ service ClusterDiscoveryService {
   rpc StreamClusters(stream DiscoveryRequest) returns (stream DiscoveryResponse) {
   }
 
-  rpc IncrementalClusters(stream IncrementalDiscoveryRequest)
-      returns (stream IncrementalDiscoveryResponse) {
+  rpc DeltaClusters(stream DeltaDiscoveryRequest) returns (stream DeltaDiscoveryResponse) {
   }
 
   rpc FetchClusters(DiscoveryRequest) returns (DiscoveryResponse) {
@@ -51,7 +50,7 @@ service ClusterDiscoveryService {
 // [#protodoc-title: Clusters]
 
 // Configuration for a single upstream cluster.
-// [#comment:next free field: 38]
+// [#comment:next free field: 39]
 message Cluster {
   // Supplies the name of the cluster which must be unique across all clusters.
   // The cluster name is used when emitting
@@ -95,9 +94,25 @@ message Cluster {
     // for an explanation.
     ORIGINAL_DST = 4;
   }
-  // The :ref:`service discovery type <arch_overview_service_discovery_types>`
-  // to use for resolving the cluster.
-  DiscoveryType type = 2 [(validate.rules).enum.defined_only = true];
+
+  // Extended cluster type.
+  message CustomClusterType {
+    // The type of the cluster to instantiate. The name must match a supported cluster type.
+    string name = 1 [(validate.rules).string.min_bytes = 1];
+
+    // Cluster specific configuration which depends on the cluster being instantiated.
+    // See the supported cluster for further documentation.
+    google.protobuf.Any typed_config = 2;
+  }
+
+  oneof cluster_discovery_type {
+    // The :ref:`service discovery type <arch_overview_service_discovery_types>`
+    // to use for resolving the cluster.
+    DiscoveryType type = 2 [(validate.rules).enum.defined_only = true];
+
+    // The custom cluster type.
+    CustomClusterType cluster_type = 38;
+  }
 
   // Only valid when discovery type is EDS.
   message EdsClusterConfig {

api/envoy/api/v2/core/config_source.proto

@@ -32,6 +32,13 @@ message ApiConfigSource {
     REST = 1;
     // gRPC v2 API.
     GRPC = 2;
+    // Using the delta xDS gRPC service, i.e. DeltaDiscovery{Request,Response}
+    // rather than Discovery{Request,Response}. Rather than sending Envoy the entire state
+    // with every update, the xDS server only sends what has changed since the last update.
+    //
+    // DELTA_GRPC is not yet entirely implemented! Initially, only CDS is available.
+    // Do not use for other xDSes. TODO(fredlas) update/remove this warning when appropriate.
+    DELTA_GRPC = 3;
   }
   ApiType api_type = 1 [(validate.rules).enum.defined_only = true];
   // Cluster names should be used only with REST. If > 1

api/envoy/api/v2/discovery.proto

@@ -102,33 +102,32 @@ message DiscoveryResponse {
   core.ControlPlane control_plane = 6;
 }
 
-// IncrementalDiscoveryRequest and IncrementalDiscoveryResponse are used in a
-// new gRPC endpoint for Incremental xDS. The feature is not supported for REST
-// management servers.
+// DeltaDiscoveryRequest and DeltaDiscoveryResponse are used in a new gRPC
+// endpoint for Delta xDS.
 //
-// With Incremental xDS, the IncrementalDiscoveryResponses do not need to
-// include a full snapshot of the tracked resources. Instead
-// IncrementalDiscoveryResponses are a diff to the state of a xDS client.
-// In Incremental XDS there are per resource versions which allows to track
-// state at the resource granularity.
-// An xDS Incremental session is always in the context of a gRPC bidirectional
+// With Delta xDS, the DeltaDiscoveryResponses do not need to include a full
+// snapshot of the tracked resources. Instead, DeltaDiscoveryResponses are a
+// diff to the state of a xDS client.
+// In Delta XDS there are per resource versions, which allow tracking state at
+// the resource granularity.
+// An xDS Delta session is always in the context of a gRPC bidirectional
 // stream. This allows the xDS server to keep track of the state of xDS clients
 // connected to it.
 //
-// In Incremental xDS the nonce field is required and used to pair
-// IncrementalDiscoveryResponse to a IncrementalDiscoveryRequest ACK or NACK.
+// In Delta xDS the nonce field is required and used to pair
+// DeltaDiscoveryResponse to a DeltaDiscoveryRequest ACK or NACK.
 // Optionally, a response message level system_version_info is present for
 // debugging purposes only.
 //
-// IncrementalDiscoveryRequest can be sent in 3 situations:
+// DeltaDiscoveryRequest can be sent in 3 situations:
 //   1. Initial message in a xDS bidirectional gRPC stream.
-//   2. As a ACK or NACK response to a previous IncrementalDiscoveryResponse.
+//   2. As a ACK or NACK response to a previous DeltaDiscoveryResponse.
 //      In this case the response_nonce is set to the nonce value in the Response.
 //      ACK or NACK is determined by the absence or presence of error_detail.
-//   3. Spontaneous IncrementalDiscoveryRequest from the client.
+//   3. Spontaneous DeltaDiscoveryRequest from the client.
 //      This can be done to dynamically add or remove elements from the tracked
 //      resource_names set. In this case response_nonce must be omitted.
-message IncrementalDiscoveryRequest {
+message DeltaDiscoveryRequest {
   // The node making the request.
   core.Node node = 1;
 
@@ -138,18 +137,18 @@ message IncrementalDiscoveryRequest {
   // required for ADS.
   string type_url = 2;
 
-  // IncrementalDiscoveryRequests allow the client to add or remove individual
+  // DeltaDiscoveryRequests allow the client to add or remove individual
   // resources to the set of tracked resources in the context of a stream.
   // All resource names in the resource_names_subscribe list are added to the
   // set of tracked resources and all resource names in the resource_names_unsubscribe
   // list are removed from the set of tracked resources.
-  // Unlike in non incremental xDS, an empty resource_names_subscribe or
+  // Unlike in state-of-the-world xDS, an empty resource_names_subscribe or
   // resource_names_unsubscribe list simply means that no resources are to be
   // added or removed to the resource list.
   // The xDS server must send updates for all tracked resources but can also
   // send updates for resources the client has not subscribed to. This behavior
-  // is similar to non incremental xDS.
-  // These two fields can be set for all types of IncrementalDiscoveryRequests
+  // is similar to state-of-the-world xDS.
+  // These two fields can be set for all types of DeltaDiscoveryRequests
   // (initial, ACK/NACK or spontaneous).
   //
   // A list of Resource names to add to the list of tracked resources.
@@ -158,15 +157,17 @@ message IncrementalDiscoveryRequest {
   // A list of Resource names to remove from the list of tracked resources.
   repeated string resource_names_unsubscribe = 4;
 
-  // This map must be populated when the IncrementalDiscoveryRequest is the
-  // first in a stream. The keys are the resources names of the xDS resources
+  // This map must be populated when the DeltaDiscoveryRequest is the
+  // first in a stream (assuming there are any resources - this field's purpose is to enable
+  // a session to continue in a reconnected gRPC stream, and so will not be used in the very
+  // first stream of a session). The keys are the resources names of the xDS resources
   // known to the xDS client. The values in the map are the associated resource
   // level version info.
   map<string, string> initial_resource_versions = 5;
 
-  // When the IncrementalDiscoveryRequest is a ACK or NACK message in response
-  // to a previous IncrementalDiscoveryResponse, the response_nonce must be the
-  // nonce in the IncrementalDiscoveryResponse.
+  // When the DeltaDiscoveryRequest is a ACK or NACK message in response
+  // to a previous DeltaDiscoveryResponse, the response_nonce must be the
+  // nonce in the DeltaDiscoveryResponse.
   // Otherwise response_nonce must be omitted.
   string response_nonce = 6;
 
@@ -176,24 +177,27 @@ message IncrementalDiscoveryRequest {
   google.rpc.Status error_detail = 7;
 }
 
-message IncrementalDiscoveryResponse {
+message DeltaDiscoveryResponse {
   // The version of the response data (used for debugging).
   string system_version_info = 1;
 
   // The response resources. These are typed resources that match the type url
-  // in the IncrementalDiscoveryRequest.
+  // in the DeltaDiscoveryRequest.
   repeated Resource resources = 2 [(gogoproto.nullable) = false];
 
   // Resources names of resources that have be deleted and to be removed from the xDS Client.
   // Removed resources for missing resources can be ignored.
   repeated string removed_resources = 6;
 
-  // The nonce provides a way for IncrementalDiscoveryRequests to uniquely
-  // reference a IncrementalDiscoveryResponse. The nonce is required.
+  // The nonce provides a way for DeltaDiscoveryRequests to uniquely
+  // reference a DeltaDiscoveryResponse. The nonce is required.
   string nonce = 5;
 }
 
 message Resource {
+  // The resource's name, to distinguish it from others of the same type of resource.
+  string name = 3;
+
   // The resource level version. It allows xDS to track the state of individual
   // resources.
   string version = 1;

api/envoy/api/v2/rds.proto

@@ -33,8 +33,7 @@ service RouteDiscoveryService {
   rpc StreamRoutes(stream DiscoveryRequest) returns (stream DiscoveryResponse) {
   }
 
-  rpc IncrementalRoutes(stream IncrementalDiscoveryRequest)
-      returns (stream IncrementalDiscoveryResponse) {
+  rpc DeltaRoutes(stream DeltaDiscoveryRequest) returns (stream DeltaDiscoveryResponse) {
   }
 
   rpc FetchRoutes(DiscoveryRequest) returns (DiscoveryResponse) {

api/envoy/config/filter/http/ext_authz/v2/ext_authz.proto

@@ -3,8 +3,8 @@ syntax = "proto3";
 package envoy.config.filter.http.ext_authz.v2;
 
 option java_outer_classname = "ExtAuthzProto";
-option java_package = "io.envoyproxy.envoy.config.filter.http.ext_authz.v2";
 option java_multiple_files = true;
+option java_package = "io.envoyproxy.envoy.config.filter.http.ext_authz.v2";
 option go_package = "v2";
 
 import "envoy/api/v2/core/base.proto";
@@ -16,7 +16,8 @@ import "envoy/type/matcher/string.proto";
 import "validate/validate.proto";
 
 // [#protodoc-title: External Authorization]
-// ExtAuthz :ref:`configuration overview <config_http_filters_ext_authz>`.
+// External Authorization :ref:`configuration overview <config_http_filters_ext_authz>`.
+
 message ExtAuthz {
   // External authorization service configuration.
   oneof services {

api/envoy/config/filter/http/grpc_http1_reverse_bridge/v2alpha1/config.proto

@@ -1,15 +1,18 @@
 syntax = "proto3";
 
-package envoy.extensions.filter.http.grpc_http1_reverse_bridge.v2alpha1;
+package envoy.config.filter.http.grpc_http1_reverse_bridge.v2alpha1;
 
 option java_outer_classname = "ConfigProto";
 option java_multiple_files = true;
-option java_package = "io.envoyproxy.envoy.extensions.filter.http.grpc_http1_reverse_bridge.v2alpha1";
+option java_package = "io.envoyproxy.envoy.config.filter.http.grpc_http1_reverse_bridge.v2alpha1";
 option go_package = "v2";
 
 import "validate/validate.proto";
 
-// [#protodoc-title: Extensions gRPC Http1 Reverse Bridge]
+// [#protodoc-title: gRPC HTTP/1.1 Reverse Bridge]
+// gRPC HTTP/1.1 Reverse Bridge :ref:`configuration overview
+// <config_http_filters_grpc_http1_reverse_bridge>`.
+
 // gRPC reverse bridge filter configuration
 message FilterConfig {
   // The content-type to pass to the upstream when the gRPC bridge filter is applied.

api/envoy/config/filter/http/jwt_authn/v2alpha/config.proto

@@ -15,6 +15,9 @@ import "google/protobuf/empty.proto";
 import "google/protobuf/wrappers.proto";
 import "validate/validate.proto";
 
+// [#protodoc-title: JWT Authentication]
+// JWT Authentication :ref:`configuration overview <config_http_filters_jwt_authn>`.
+
 // Please see following for JWT authentication flow:
 //
 // * `JSON Web Token (JWT) <https://tools.ietf.org/html/rfc7519>`_

api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto

@@ -137,14 +137,13 @@ message HttpConnectionManager {
   // header in responses. If not set, the default is *envoy*.
   string server_name = 10;
 
-  // The maximum request headers size for incoming connections. The default max
-  // is 60K, based on default settings for http codecs. For HTTP1, the current
-  // limit set by http_parser is 80K. for HTTP2, the default allowed header
-  // block in nghttp2 is 64K. The max configurable setting is 64K in order to
-  // stay under both codec limits.
-  // Requests that exceed this size will receive a 431 response.
+  // The maximum request headers size for incoming connections.
+  // If unconfigured, the default max request headers allowed is 60 KiB.
+  // Requests that exceed this limit will receive a 431 response.
+  // The max configurable limit is 96 KiB, based on current implementation
+  // constraints.
   google.protobuf.UInt32Value max_request_headers_kb = 29
-      [(validate.rules).uint32.gt = 0, (validate.rules).uint32.lte = 64];
+      [(validate.rules).uint32.gt = 0, (validate.rules).uint32.lte = 96];
 
   // The idle timeout for connections managed by the connection manager. The
   // idle timeout is defined as the period in which there are no active
@@ -400,14 +399,20 @@ message HttpFilter {
   // [#comment:TODO(mattklein123): Auto generate the following list]
   // * :ref:`envoy.buffer <config_http_filters_buffer>`
   // * :ref:`envoy.cors <config_http_filters_cors>`
+  // * :ref:`envoy.ext_authz <config_http_filters_ext_authz>`
   // * :ref:`envoy.fault <config_http_filters_fault_injection>`
+  // * :ref:`envoy.filters.http.header_to_metadata <config_http_filters_header_to_metadata>`
+  // * :ref:`envoy.filters.http.grpc_http1_reverse_bridge \
+  //   <config_http_filters_grpc_http1_reverse_bridge>`
+  // * :ref:`envoy.filters.http.jwt_authn <config_http_filters_jwt_authn>`
+  // * :ref:`envoy.filters.http.rbac <config_http_filters_rbac>`
+  // * :ref:`envoy.filters.http.tap <config_http_filters_tap>`
   // * :ref:`envoy.gzip <config_http_filters_gzip>`
   // * :ref:`envoy.http_dynamo_filter <config_http_filters_dynamo>`
   // * :ref:`envoy.grpc_http1_bridge <config_http_filters_grpc_bridge>`
   // * :ref:`envoy.grpc_json_transcoder <config_http_filters_grpc_json_transcoder>`
   // * :ref:`envoy.grpc_web <config_http_filters_grpc_web>`
   // * :ref:`envoy.health_check <config_http_filters_health_check>`
-  // * :ref:`envoy.header_to_metadata <config_http_filters_header_to_metadata>`
   // * :ref:`envoy.ip_tagging <config_http_filters_ip_tagging>`
   // * :ref:`envoy.lua <config_http_filters_lua>`
   // * :ref:`envoy.rate_limit <config_http_filters_rate_limit>`