In order to support TLS in a health check connection, a TransportSocket proto must be matched to build the proper TLS connection factory. These are matched by the repeated field transport_socket_matches in the cluster proto, which HDS is currently leaving blank when building this proto. As a result, there is not way to specify a TLS transport socket or any transport socket listed in the docs.
This change adds the transport_socket_matches field to the HDS health check specifier, and adds it to the Cluster config generated by HDS, to support transport socket matches per-health check.
Risk Level: Low
Testing: HDS Unit tests and integration tests pass. Added unit test to test that the transport socket matcher receives the correct fields. Added two integration tests with a TLS configuration, one over HTTP and one over HTTP/2.
Docs Changes: Added comments about the new transport_socket_maches field in the HDS specifier proto.
Release Notes: Included
Signed-off-by: Drew S. Ortega <drewortega@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ bf6b9ba65495175e164b4ef0051b94cd66e7dbf5
Currently, the health discovery service takes a specifier with information about which endpoints to perform health checks on, which already supports information about cluster structure and locality information. However, when when forming a response holding endpoint health information, all notion of cluster or locality is dropped and endpoint information is stored in a flat list. This is problematic when there are several endpoints with the same address or port but with a different locality, cluster, or path.
This PR uses the previous proto change in Issue #12153 which added support for grouping endpoint health information by their respective cluster and locality.
Risk Level: Low
Testing: Added a unit test in test/common/upstream/hds_test, which sends a specifier to HdsDelegate with several clusters, localties, and endpoints. It then verifies that the response holds the same structure. Existing integration tests were also changed to check for the new proto structure, specifically ones that already group several endpoints by differing clusters or localities.
Signed-off-by: Drew S. Ortega <drewortega@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ d16164be1bd0ec7eba2b0b0f78ae8b0f455acd50
Currently, the HDS specifier proto gives endpoint information organized by their locality and grouped by cluster. This information is retained when doing health checks, however when responding with health statuses from each endpoint locality and cluster information is dropped. This puts all endpoint information into a flat list when returning, making it the responsibility of the receiver to re-structure data by cluster and locality.
This change follows a similar format to the specifier coming into HDS, organizing it in the same way. The proposed changed adds consistency to how messages are flowing in and out of HDS.
Note that his PR only contains the protos changes, and does not include implementation. This is done to get approval from api-shepherds for the changes before continuing.
Risk Level: Low
Testing: No new tests. New tests will be added upon implementation, but for now the fields remain empty.
Docs Changes:
Inline comments in hds.proto.
Release Notes:
N/A - will append to release notes upon implementation completion.
Deprecated:
The endpoints_health field in EndpointHealthResponse should be deprecated in favor of the new cluster_endpoints_health field.
Signed-off-by: Drew S. Ortega <drewortega@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4f1ee95e36ad233aac0d37a8b1d7c4536d4972c7
Deprecates GoogleRE2.max_program_size field so that client does not need to check this.
Risk Level: Low
Testing: N/A
Docs Changes: Included in PR
Release Notes: Included in PR
Signed-off-by: Mark D. Roth <roth@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 10125161be0d0a759c3ffb02ddcdf8abc0bc6060
This patch performs a major version freeze and bump by modifying
package_version_status, using the tooling developed in #10636.
Specifically:
v2 APIs are frozen (except for where they are the latest in their
package history and still active)
v3 APIs are transitioned to be active
Candidate v4alpha APIs are generated (not used by Envoy yet)
Fixes#10355
Risk level: medium (entire API's files are modified, visually verified
to ensure things look sane, all tests pass)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 549164c42cae84b59154ca4c36009e408aa10b52
Part of https://github.com/envoyproxy/envoy/issues/10355, this patch introduces additional
annotations to the API to support automatic inference (and developer documentation) of where the
active developer editable version of a file is, and which files are frozen or machine generated.
Risk level: Low (API annotations only)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4c5f4310bb8a19a38e5377d7a2d2dc6aa4560f47
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf
This allows for a clean separation of config/service in v3. This is a
continuation of #9548.
Risk level: Low
Testing: bazel test //test/...
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ c3bddaee1912fcd1fedc4786aee830b2e4a7c599
Description:
Move packages around for #8120 and #8121
Risk Level: Med around messing up build.
Testing: CI
Docs Changes: in API/STYLE.md
Release Notes: N/A (v3alpha is not in use yet)
Fixes#8120
Signed-off-by: Lizan Zhou <lizan@tetrate.io>
Mirrored from https://github.com/envoyproxy/envoy @ 1371f2ef46582a72b5b3971147bd87c534011731