After upgrading from 0.12.2
to 0.13.5
a connectivity issue came up with the graphql component. Prefect server is running in a different server but the graphql url remains http://localhost:4200/graphql
. server.ui.graphql_url
was working great with version 0.12.2
but now I can't find any way to configure the graphql url properly.
Below you will find the config.toml
:
$ cat ~/.prefect/config.toml
[logging]
level = "INFO"
[api]
url = "http://192.168.40.180:4200"
[server.database]
host_port = "6543"
[context.secrets]
SLACK_WEBHOOK_URL = 'https://hooks.slack.com/services/xx/XX/Xx'
[server.ui]
graphql_url = "http://192.168.40.180:4200/graphql"
In the image you can see a POC of the case.
I'm a lit bit confused about the old and the new way to configure the prefect server. Have you any idea about this issue?
EDIT: The ticket I mentioned below has been closed; when 0.13.9 is released, it'll contain a new runtime config apollo_url
(which is more accurate since that's the container we're looking for anyway), which is inserted into a static settings file in the UI build, which is fetched when the application starts. This should hit all the points mentioned below.
This is a change from Prefect Server ^0.13.0, which removed the graphql_url
variable as a configurable environment variable.
The previous version of Server used a find-replace on the UI code, which is compiled and minified at image build time. The reason for this is that it moves the burden of installing the required Node modules and building the application away from client-side installations and onto Prefect at release-time instead, since these can take a long time (10+ minutes each) in containerized environments. However, the downside is that modifying environment variables, which are injected at build time, requires a less than desirable lookup of the previously-injected variables, which means modifying these requires pulling a new image.
We chose to ship the new version with an in-app input, which allows changing the Server endpoint at browser run-time instead. This gives the flexibility of a single UI instance to connect to any accessible Server installation, leveraging local storage to persist this setting between browser sessions.
That said, we have a ticket open to re-expose the default configuration in a better way than in the previous version. You can follow that ticket here.