Envoy sidecar filter config incorrectly generated

[mr-miles]

Overview of the Issue

I have a service within the mesh running with a transparent proxy, and a database outside the service mesh, and I want to connect them through the terminating-gateway. However the envoy sidecar configuration is being generated as if it were an http service, whereas I have set the service up to use tcp by default.

---

Reproduction Steps

1. Set up consul service mesh in transparent proxy mode with a terminating gateway
2. Register a dummy service named "my-service" with the consul catalog
3. Register these configuration objects:

proxy-defaults:
 - protocol: http

service-defaults:
 - name: database
 - protocol: tcp

terminating-gateway:
 - name: tgw
 - services:
   - name: database

service-intention:
 - destination: my-service
 - sources:
   - name: database

4. Start the sidecar for my-service so it retrieves configuration from consul
5. Observe that the configuration contains an http-connection-manager that attempts to route traffic based on the request path and name like so:

6. Observe from the http api that the discovery-chain for database claims that traffic is tcp and not http

I found that the problem could be fixed by overriding the upstream protocol for my-service:

service-defaults:
 - name: my-service
 - protocol: http
 - upstreamConfig:
   overrides:
     - name: database
       protocol: tcp

Yielding:

I believe that the upstream config is incorrectly coming from the proxy-defaults and not the defaults for the target service.

I also tried with and without specifying a Destination entry on the service-defaults for database, but that did not affect the presence of the http-connection-manager

-->

Consul info for both Client and Server

Helm chart: 1.1.1, overridden to use the server 1.15.2 image
Environment: AWS EKS

[mr-miles]

fixed in #17894 - can't wait for the patch release

[david-yu]

Hi @mr-miles did you verify that the PR fixed the issue mentioned here? The PR btw was backported to 1.16.x, 1.15.x and 1.14.x and will be released approximately 5 weeks from now.

[mr-miles]

Actually no (blush) i haven't verified it - if i can find an image of the nightly 1.16.x build then i can give it a go.

But I had read through the code and worked out that this was the root cause a day or two before that PR landed - in fact I had started a near-identical PR of my own - so I feel pretty solid on it