Generic services are deprecated since protoc version 2.4.0 (2010). Protoc plugins that generates code may require that generic services are disabled, so that they can generate their own classes of the same name.
Risk Level: Low
Fixes#25172
Signed-off-by: Sébastien CROCQUESEL <88554524+scrocquesel@users.noreply.github.com>
Mirrored from https://github.com/envoyproxy/envoy @ baec129464bba6e3651147a0d846e8c1f4610199
Sometimes when an application doesn't bind to localhost and the machine uses iptables for traffic redirection, HDS might need to override the source address for iptables to redirect traffic to the application instead of getting into the loop.
Risk Level: Low
Testing: small unit test configuration, upstream cluster tests binding functionality, manual testing
Docs Changes: API docs
Release Notes:
Platform Specific Features: no
Signed-off-by: Łukasz Dziedziak <lukidzi@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ 74bef6aac36a45a2b8f1812dcd3e31c7eb46db3e
This should reduce the binary size, which is particularly important for Envoy Mobile. Looking at a
local opt build with debug symbols, I'm seeing a drop from ~400MB to ~380MB, so maybe 5% saving. @Reflejo indicates that optimized Envoy Mobile without symbols is observing ~20% improvement.
Related to #10943
Risk level: Low
Testing: bazel query deps to confirm no more v2 API deps.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 53fca618e47702f6c8dbc323db9bd39d15725457
This fixes the refs in protos and removes the sed operations for build
The benefits are:
- less indirection in proto refs
- (small) speedup of build
- simplify docs build
- simplify reuse of proto comments (eg generating jsonschemas)
Signed-off-by: Ryan Northey <ryan@synca.io>
Mirrored from https://github.com/envoyproxy/envoy @ 45ec050f91407147ed53a999434b09ef77590177
Adding a deprecated API version annotation to deprecated fields and enum values in proto files.
This is part of the work on adding minor/patch versioning work.
Risk Level: Low (adding annotation to existing protos).
Testing: Added and modified tests for the tooling (in tools/testdata).
Signed-off-by: Adi Suissa-Peleg <adip@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5a8bfa20dc3c85ecb61826d122696ecaa75dffa0
Fixing "warning: Import ... but not used" warnings from protoc
Risk Level: Low
Testing: manually built protos
Signed-off-by: Chris Heisterkamp <cheister@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ 209b8f96498162834856a4330f27deafdf7e0518
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
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
data-plane-api(Azure Pipelines)