Add opt-in server discovery for API Gateway Controller #1732
Conversation
| @@ -119,6 +119,10 @@ spec: | |||
| value: {{ .Values.global.adminPartitions.name }} | |||
| {{- end }} | |||
| {{- end }} | |||
| {{- if not .Values.client.enabled }} | |||
There was a problem hiding this comment.
If clients are enabled we still leverage $(HOST_IP) -- so in any other case (i.e. cluster-based or external servers) we know we should use the server gRPC discovery components. This is also passed explicitly as an env variable to support older versions of api-gateway rather than having the entrypoints fail with an unknown flag.
There was a problem hiding this comment.
To be clear this isn't really "opt-in" from the end-user UX (only the consul-api-gateway binary), as it just passes an env var to the binary based on other existing settings in the chart (which will default to clients disabled in the upcoming v1.0 release), and therefore enable the gRPC server discovery functionality on supporting versions of Consul API Gateway (v0.5 and newer).
Should add a changelog entry though.
Changes proposed in this PR:
For backwards compatibility with old helm charts where we only ever talk to the agent nodes which don't have gRPC APIs for Consul dataplane, we need to use our old login/logout flow and the static agent node address rather than leveraging the consul server connection manager. This PR coincides with the changes introduced in hashicorp/consul-api-gateway#454.
How I've tested this PR:
Manually verified in explicitly agent-based and agentless installation modes and added unit tests.
Checklist: