status-im
/
consul
mirror of https://github.com/status-im/consul.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity
consul/agent/xds/testdata/clusters/expose-paths-grpc-new-clust...

66 lines
1.7 KiB
Plaintext
Raw Normal View History

proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
{
xds: update golden tests to be deterministic (#18707)
2023-09-11 16:40:19 +00:00
"nonce": "00000001",
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
"resources": [
{
xds: default to speaking xDS v3, but allow for v2 to be spoken upon request (#9658) - Also add support for envoy 1.17.0
2021-02-26 22:23:15 +00:00
"@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
"connectTimeout": "5s",
"loadAssignment": {
"clusterName": "exposed_cluster_8090",
"endpoints": [
{
"lbEndpoints": [
{
"endpoint": {
"address": {
"socketAddress": {
"address": "127.0.0.1",
"portValue": 8090
}
}
}
}
]
}
]
xds: update golden tests to be deterministic (#18707)
2023-09-11 16:40:19 +00:00
},
"name": "exposed_cluster_8090",
"type": "STATIC"
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
},
{
xds: default to speaking xDS v3, but allow for v2 to be spoken upon request (#9658) - Also add support for envoy 1.17.0
2021-02-26 22:23:15 +00:00
"@type": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
"connectTimeout": "5s",
"loadAssignment": {
"clusterName": "local_app",
"endpoints": [
{
"lbEndpoints": [
{
"endpoint": {
"address": {
"socketAddress": {
"address": "127.0.0.1",
"portValue": 8080
}
}
}
}
]
}
]
},
xds: update golden tests to be deterministic (#18707)
2023-09-11 16:40:19 +00:00
"name": "local_app",
"type": "STATIC",
Bump go-control-plane * `go get cloud.google.com/go@v0.59.0` * `go get github.com/envoyproxy/go-control-plane@v0.9.9` * `make envoy-library` * Bumpprotoc to 3.15.8
2022-03-30 16:51:56 +00:00
"typedExtensionProtocolOptions": {
"envoy.extensions.upstreams.http.v3.HttpProtocolOptions": {
"@type": "type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions",
xds: Use downstream protocol when connecting to local app (#18573) Configure Envoy to use the same HTTP protocol version used by the downstream caller when forwarding requests to a local application that is configured with the protocol set to either `http2` or `grpc`. This allows upstream applications that support both HTTP/1.1 and HTTP/2 on a single port to receive requests using either protocol. This is beneficial when the application primarily communicates using HTTP/2, but also needs to support HTTP/1.1, such as to respond to Kubernetes HTTP readiness/liveness probes. Co-authored-by: Derek Menteer <derek.menteer@hashicorp.com>
2023-09-19 21:32:28 +00:00
"useDownstreamProtocolConfig": {
"http2ProtocolOptions": {},
"httpProtocolOptions": {}
Bump go-control-plane * `go get cloud.google.com/go@v0.59.0` * `go get github.com/envoyproxy/go-control-plane@v0.9.9` * `make envoy-library` * Bumpprotoc to 3.15.8
2022-03-30 16:51:56 +00:00
}
}
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
}
}
],
xds: default to speaking xDS v3, but allow for v2 to be spoken upon request (#9658) - Also add support for envoy 1.17.0
2021-02-26 22:23:15 +00:00
"typeUrl": "type.googleapis.com/envoy.config.cluster.v3.Cluster",
xds: update golden tests to be deterministic (#18707)
2023-09-11 16:40:19 +00:00
"versionInfo": "00000001"
proxycfg: support path exposed with non-HTTP2 protocol (#7510) If a proxied service is a gRPC or HTTP2 service, but a path is exposed using the HTTP1 or TCP protocol, Envoy should not be configured with `http2ProtocolOptions` for the cluster backing the path. A situation where this comes up is a gRPC service whose healthcheck or metrics route (e.g. for Prometheus) is an HTTP1 service running on a different port. Previously, if these were exposed either using `Expose: { Checks: true }` or `Expose: { Paths: ... }`, Envoy would still be configured to communicate with the path over HTTP2, which would not work properly.
2020-04-02 07:35:04 +00:00
}