docker-compose.yml is not consistent with aerie-gateway

[parkerabercrombie]

Checked for duplicates

No - I haven't checked

Is this a regression?

No - This is a new bug

Version

3.0.1

Describe the bug

I received an error when attempting to import a plan into Aerie. On further investigation, the docker-compose file sets env var GQL_API_URL (https://github.com/NASA-AMMOS/aerie/blob/develop/deployment/docker-compose.yml#L8) but aerie-gateway expects env var HASURA_API_URL https://github.com/NASA-AMMOS/aerie-gateway/blob/5c616b4eb7e6fec9c42a5e22cfd4a12b4cbc2dd3/src/packages/plan/plan.ts#L37. This results in Aerie incorrectly using a default URL.

Reproduction

N/A

Logs

No response

System Info

Chrome

Severity

Major

[parkerabercrombie]

aerie-gateway also expects the hasura URL var to be only the host, not the /v1/graphql path, which is inconsistent with other services.

[Mythicaeda]

As indicated in the Enviornment Documentation for the Gateway, GQL_API_URL and HASURA_API_URL are two separate envvars.

• GQL_API_URL is the URL given to the API Playground Client for it to make external GQL requests.
• HASURA_API_URL, meanwhile, is the URL the Gateway uses internally to make non-GQL requests to the Hasura container (which is why it does not want /v1/graphql). This doesn't match up with any envvars in our other containers, as no other container needs to send non-GQL requests to Hasura.

You can think of them as roughly equivalent to PUBLIC_HASURA_CLIENT_URL and PUBLIC_HASURA_SERVER_URL in the UI.

More information about HASURA_API_URL can be found in the Upgrade Guide for its release version (v2.16.0)

[parkerabercrombie]

Should the docker-compose also include HASURA_API_URL for the gateway service, just as a hint to projects adapting this file for their own deployments?

[Mythicaeda]

Sure, it can be added.

[parkerabercrombie]

Great, thanks. With that addition I'm fine with closing this ticket.