Merge remote-tracking branch 'upstream/master' into feature/use-trace…

…r-per-http-connection-manager

Signed-off-by: Yaroslav Skopets <yaroslav@tetrate.io>

.gitattributes

@@ -1,4 +1,4 @@
-/docs/root/intro/version_history.rst merge=union
+/docs/root/version_history/current.rst merge=union
 *.generated.pb_text linguist-generated=true
 *.generated.pb_text -diff -merge
 /generated_api_shadow/envoy/** linguist-generated=true

CONTRIBUTING.md

@@ -88,7 +88,7 @@ versioning guidelines:
   build. If your PR cannot have 100% coverage for some reason please clearly explain why when you
   open it.
 * Any PR that changes user-facing behavior **must** have associated documentation in [docs](docs) as
-  well as [release notes](docs/root/intro/version_history.rst). API changes should be documented
+  well as [release notes](docs/root/version_history/current.rst). API changes should be documented
   inline with protos as per the [API contribution guidelines](api/CONTRIBUTING.md).
 * All code comments and documentation are expected to have proper English grammar and punctuation.
   If you are not a fluent English speaker (or a bad writer ;-)) please let us know and we will try

GOVERNANCE.md

@@ -79,12 +79,12 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 * Begin marshalling the ongoing PR flow in this repo. Ask maintainers to hold off merging any
   particularly risky PRs until after the release is tagged. This is because we aim for master to be
   at release candidate quality at all times.
-* Do a final check of the [release notes](docs/root/intro/version_history.rst):
+* Do a final check of the [release notes](docs/root/version_history/current.rst):
   * Make any needed corrections (grammar, punctuation, formatting, etc.).
   * Check to see if any security/stable version release notes are duplicated in
     the major version release notes. These should not be duplicated.
-  * Remove the "Pending" tags and add dates to the top of the [release notes](docs/root/intro/version_history.rst)
-    and [deprecated log](docs/root/intro/deprecated.rst).
+  * If the "Deprecated" section is empty, delete it.
+  * Remove the "Pending" tags and add dates to the top of the [release notes for this version](docs/root/version_history/current.rst).
   * Switch the [VERSION](VERSION) from a "dev" variant to a final variant. E.g., "1.6.0-dev" to
     "1.6.0".
   * Get a review and merge.
@@ -100,10 +100,24 @@ or you can subscribe to the iCal feed [here](https://app.opsgenie.com/webcal/get
 * Craft a witty/uplifting email and send it to all the email aliases including envoy-announce@.
 * If possible post on Twitter (either have Matt do it or contact caniszczyk@ on Slack and have the
   Envoy account post).
-* Do a new PR to update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". At
-  the same time, also add a new empty "pending" section to the [release
-  notes](docs/root/intro/version_history.rst) and to [deprecated log](docs/root/intro/deprecated.rst) for the
-  following version. E.g., "1.7.0 (pending)".
+* Do a new PR to setup the next version
+  * Update [VERSION](VERSION) to the next development release. E.g., "1.7.0-dev". 
+  * `git mv docs/root/version_history/current.rst docs/root/version_history/v1.6.0.rst`, filling in the previous
+    release version number in the filename, and add an entry for the new file in the `toctree` in 
+    [version_history.rst](docs/root/version_history/version_history.rst).
+  * Create a new "current" version history file at the [release
+  notes](docs/root/version_history/current.rst) for the following version. E.g., "1.7.0 (pending)". Use
+  this text as the template for the new file:
+```
+1.7.0 (Pending)
+===============
+
+Changes
+-------
+
+Deprecated
+----------
+```
 * Run the deprecate_versions.py script (e.g. `sh tools/deprecate_version/deprecate_version.sh`)
   to file tracking issues for code which can be removed.
 * Run the deprecate_features.py script (e.g. `sh tools/deprecate_features/deprecate_features.sh`)

PULL_REQUESTS.md

@@ -54,10 +54,10 @@ N/A if there were no documentation changes.
 ### <a name="relnotes"></a>Release notes
 
 If this change is user impacting OR extension developer impacting (filter API, etc.) you **must**
-add a release note to [version_history.rst](docs/root/intro/version_history.rst). Please include
-any relevant links. Each release note should be prefixed with the relevant subsystem in
-**alphabetical order** (see existing examples as a guide) and include links to relevant parts of the
-documentation. Thank you! Please write in N/A if there are no release notes.
+add a release note to the [version history](docs/root/version_history/current.rst) for the 
+current version. Please include any relevant links. Each release note should be prefixed with the
+relevant subsystem in **alphabetical order** (see existing examples as a guide) and include links
+to relevant parts of the documentation. Thank you! Please write in N/A if there are no release notes.
 
 ### <a name="issues"></a>Issues
 

api/envoy/api/v2/endpoint/endpoint_components.proto

@@ -97,7 +97,8 @@ message LbEndpoint {
   // percentage of traffic for the endpoint. This percentage is then further
   // weighted by the endpoint's locality's load balancing weight from
   // LocalityLbEndpoints. If unspecified, each host is presumed to have equal
-  // weight in a locality.
+  // weight in a locality. The sum of the weights of all endpoints in the
+  // endpoint's locality must not exceed uint32_t maximal value (4294967295).
   google.protobuf.UInt32Value load_balancing_weight = 4 [(validate.rules).uint32 = {gte: 1}];
 }
 
@@ -116,7 +117,8 @@ message LocalityLbEndpoints {
   // Optional: Per priority/region/zone/sub_zone weight; at least 1. The load
   // balancing weight for a locality is divided by the sum of the weights of all
   // localities  at the same priority level to produce the effective percentage
-  // of traffic for the locality.
+  // of traffic for the locality. The sum of the weights of all localities at
+  // the same priority level must not exceed uint32_t maximal value (4294967295).
   //
   // Locality weights are only considered when :ref:`locality weighted load
   // balancing <arch_overview_load_balancing_locality_weighted_lb>` is

api/envoy/config/endpoint/v3/endpoint_components.proto

@@ -103,7 +103,8 @@ message LbEndpoint {
   // percentage of traffic for the endpoint. This percentage is then further
   // weighted by the endpoint's locality's load balancing weight from
   // LocalityLbEndpoints. If unspecified, each host is presumed to have equal
-  // weight in a locality.
+  // weight in a locality. The sum of the weights of all endpoints in the
+  // endpoint's locality must not exceed uint32_t maximal value (4294967295).
   google.protobuf.UInt32Value load_balancing_weight = 4 [(validate.rules).uint32 = {gte: 1}];
 }
 
@@ -125,7 +126,8 @@ message LocalityLbEndpoints {
   // Optional: Per priority/region/zone/sub_zone weight; at least 1. The load
   // balancing weight for a locality is divided by the sum of the weights of all
   // localities  at the same priority level to produce the effective percentage
-  // of traffic for the locality.
+  // of traffic for the locality. The sum of the weights of all localities at
+  // the same priority level must not exceed uint32_t maximal value (4294967295).
   //
   // Locality weights are only considered when :ref:`locality weighted load
   // balancing <arch_overview_load_balancing_locality_weighted_lb>` is

ci/run_clang_tidy.sh

@@ -55,6 +55,9 @@ function filter_excludes() {
   exclude_testdata | exclude_chromium_url | exclude_win32_impl
 }
 
+if [[ -z "${DIFF_REF}" && "${BUILD_REASON}" != "PullRequest" ]]; then
+  DIFF_REF=HEAD^
+fi
 
 if [[ "${RUN_FULL_CLANG_TIDY}" == 1 ]]; then
   echo "Running full clang-tidy..."
@@ -64,9 +67,9 @@ if [[ "${RUN_FULL_CLANG_TIDY}" == 1 ]]; then
     -export-fixes=${FIX_YAML} \
     -j ${NUM_CPUS:-0} -p 1 -quiet \
     ${APPLY_CLANG_TIDY_FIXES:+-fix}
-elif [[ "${BUILD_REASON}" != "PullRequest" ]]; then
-  echo "Running clang-tidy-diff against previous commit..."
-  git diff HEAD^ | filter_excludes | \
+elif [[ -n "${DIFF_REF}" ]]; then
+  echo "Running clang-tidy-diff against ref ${DIFF_REF}"
+  git diff ${DIFF_REF} | filter_excludes | \
     python3 "${LLVM_PREFIX}/share/clang/clang-tidy-diff.py" \
       -clang-tidy-binary=${CLANG_TIDY} \
       -export-fixes=${FIX_YAML} \

docs/build.sh

@@ -16,10 +16,10 @@ then
     exit 1
   fi
   # Check the version_history.rst contains current release version.
-  grep --fixed-strings "$VERSION_NUMBER" docs/root/intro/version_history.rst \
-    || (echo "Git tag not found in version_history.rst" && exit 1)
+  grep --fixed-strings "$VERSION_NUMBER" docs/root/version_history/current.rst \
+    || (echo "Git tag not found in version_history/current.rst" && exit 1)
 
-  # Now that we now there is a match, we can use the tag.
+  # Now that we know there is a match, we can use the tag.
   export ENVOY_DOCS_VERSION_STRING="tag-$CIRCLE_TAG"
   export ENVOY_DOCS_RELEASE_LEVEL=tagged
   export ENVOY_BLOB_SHA="$CIRCLE_TAG"

docs/root/configuration/http/http_filters/aws_lambda_filter.rst

@@ -182,3 +182,18 @@ An example with the Lambda metadata applied to a weighted-cluster:
         "@type": type.googleapis.com/envoy.api.v2.auth.UpstreamTlsContext
         sni: "*.amazonaws.com"
 
+
+Statistics
+----------
+
+The AWS Lambda filter outputs statistics in the *http.<stat_prefix>.aws_lambda.* namespace. The
+:ref:`stat prefix <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpConnectionManager.stat_prefix>`
+comes from the owning HTTP connection manager.
+
+.. csv-table::
+  :header: Name, Type, Description
+  :widths: 1, 1, 2
+
+  server_error, Counter, Total requests that returned invalid JSON response (see :ref:`payload_passthrough <envoy_api_msg_config.filter.http.aws_lambda.v2alpha.config>`)
+  upstream_rq_payload_size, Histogram, Size in bytes of the request after JSON-tranformation (if any).
+

docs/root/configuration/http/http_filters/grpc_web_filter.rst

@@ -4,7 +4,7 @@ gRPC-Web
 ========
 
 * gRPC :ref:`architecture overview <arch_overview_grpc>`
-* :ref:`v2 API reference <envoy_api_field_config.filter.network.http_connection_manager.v2.HttpFilter.name>`
+* :ref:`v2 API reference <envoy_api_msg_config.filter.http.grpc_web.v2.GrpcWeb>`
 * This filter should be configured with the name *envoy.filters.http.grpc_web*.
 
 This is a filter which enables the bridging of a gRPC-Web client to a compliant gRPC server by

docs/root/index.rst

@@ -15,6 +15,7 @@ Envoy documentation
   intro/intro
   start/start
   install/install
+  version_history/version_history
   configuration/configuration
   operations/operations
   extending/extending