We have a workspace running as an ECS service and have an ALB (with TLS) to communicate with the service. Outside of dagster we can connect to the service

grpcurl -import-path . -proto health.proto xxx:4000 grpc.health.v1.Health/Check

{
 "status": "SERVING"
}

However dagster cannot seem to connect to it

dagster api grpc-health-check -h xxx -p 4000

<_InactiveRpcError of RPC that terminated with:
	status = StatusCode.UNAVAILABLE
	details = "failed to connect to all addresses"
	debug_error_string = "{"created":"@1614180244.762685000","description":"Failed to pick subchannel","file":"src/core/ext/filters/client_channel/client_channel.cc","file_line":5391,"referenced_errors":[{"created":"@1614180244.762680000","description":"failed to connect to all addresses","file":"src/core/ext/filters/client_channel/lb_policy/pick_first/pick_first.cc","file_line":398,"grpc_status":14}]}"
>

Wasn’t running into any of these problems locally with our docker compose setup which also was using grpc for the workspaces and the images are the same. I am kind of stumped

Actually also when running the dagster compose locally and changing the workspace yaml to reference the

xxx:4000

getting the same error

Doing a little more digging with DevOps. Since we are using TLS. There may need to be an additional flag on the grpc_settings for ssl/tls for the secure channel grpc call

So if the

DagsterGrpcClient

supported an optional parameter for ssl and then could use

grpc.secure_channel

instead of

insecure_channel

. Should this be an issue?