Update the Helm Chart to set an AIRBYTE_API_HOST in OSS and Enterprise #310
Conversation
…ken for OSS, so this needs some review and suggestions.
|
|
| @@ -46,7 +46,7 @@ data: | |||
| KEYCLOAK_INTERNAL_HOST: localhost # just a placeholder so that nginx template is valid - shouldn't be used when edition isn't "pro" | |||
| {{- end }} | |||
| CONNECTOR_BUILDER_API_HOST: {{ .Release.Name }}-airbyte-connector-builder-server-svc:{{ index .Values "connector-builder-server" "service" "port" }} | |||
| AIRBYTE_API_HOST: {{ .Release.Name }}-airbyte-api-server-svc:{{ index .Values "airbyte-api-server" "service" "port" }} | |||
| AIRBYTE_API_HOST: {{ printf "%s/api/public/v1" (index $airbyteYmlDict "webapp-url") | quote }} | |||
There was a problem hiding this comment.
I have no idea what happens here is the airbyteYmlDict is not set. This will happen in OSS. Not sure what we should set for this value in OSS.
There was a problem hiding this comment.
Ok after looking at this more here's the rundown.
When we try to build say a pagination next URL, we take the AIRBYTE_API_HOST and grab i.e. the connections path (a constant with value /api/public/v1/connections), remove the /api/public prefix, and then smash them together to get the URL that appears in the next param of the response.
I think if we set the AIRBYTE_API_HOST to http://airbyte-server-svc.cluster.local/api/public or whatever the equivalent is, we'll still remove the /api/public off the path, but the API Host will still contain it and we'll be able to correctly direct folks. Should definitely test before we merge, but I think that will work for us.
There was a problem hiding this comment.
I don't think we need to include the v1 at the end of the path
There was a problem hiding this comment.
For Enterprise, the majority of the traffic will be coming in through an ingress, so we will want the external host name. I am good with defaulting this to the {{ Release.name }}-airbyte-server/api/public though.
There was a problem hiding this comment.
That makes sense to me. To summarize:
- In Cloud/Enterprise we'll expect an ingress to be present where we'll rewrite the path from something like
api.cloud-customer.com->airbyte-server/api/publicand have anAIRBYTE_API_HOSTvalue ofapi.cloud-customer.com - In OSS (and some Enterprise cases) we'll expect no ingress to be present which will mean all calls will be made directly to
airbyte-server/api/publicand theAIRBYTE_API_HOSTvalue will beairbyte-server/api/public.
Does that seem accurate?
There was a problem hiding this comment.
Good enough for now?
Airbyte Code Coverage
|
bgroff
changed the title
|
closed in favor of https://github.com/airbytehq/airbyte-platform-internal/pull/11729 |
|
Your branch is not currently up-to-date with |
Use the webapp-url when deploying as Enterprise and the internal service name in OSS.
Can this PR be safely reverted / rolled back?