Summary
The user is facing deployment issues related to ‘AIRBYTE_URL’ in a Kubernetes Helm deployment. They are unsure about the correct value to set and its impact. They are also confused about the relationship between ‘AIRBYTE_URL’ and ‘WEBAPP_URL’.
Question
My deployment is failing with error - unknown object type "nil" in ConfigMap.data.AIRBYTE_URL . Our setup is based on a kubernetes helm deployment.
If I set any dummy value global.airbyteUrl="<http://your-airbyte-domain.com>", then everything works. However, I’m not sure what is the right value to set here, and if this value is use somewhere else that could be impacted?
Can somebody help me understand what is AIRBYTE_URL used for? Is this same as WEBAPP_URL? I do not have an ingress setup and the urls are not exposed to public.
I’ve verified that internally
• In my configmap, WEBAPP_URL=<http://data-prod-airbyte-airbyte-webapp-svc:80>
• The web-server pod can be reached at <http://data-stage-airbyte-airbyte-webapp-svc.applications.svc.cluster.local>
Should one of these values be my AIRBYTE_URL as well?
This topic has been created from a Slack thread to give it more visibility.
It will be on Read-Only mode here. Click here if you want
to access the original thread.
Join the conversation on Slack
["kubernetes-helm", "deployment-error", "AIRBYTE_URL", "WEBAPP_URL", "configmap", "ingress"]
I believe this is a small piece of a bigger push by the Airbyte team to work toward simplifying the YAML configs.
You can see <airbyte-platform/airbyte-commons-micronaut/src/main/java/io/airbyte/micronaut/config/AirbyteConfigurationBeanFactory.java at main · airbytehq/airbyte-platform · GitHub the platform source code> that the intent is do eventually deprecate the internal use of the webapp URL:
* This method provides the airbyte url by preferring the `airbyte.airbyte-url` property over the
* deprecated `airbyte-yml.webapp-url` property. For backwards compatibility, if
* `airbyte-yml.airbyte-url` is not provided, this method falls back on `airbyte-yml.webapp-url`.
*/```
So usage is similar, and if you're working internally any of the valid internal URLs should be fine for this.
There's also some broader changes, such as the deprecation of the stand-alone API server pod that is driving these changes. You also see a push toward simplification of storage, logging, and secret management in the `values.yaml` happening right now (although there are some legacy cases that currently require duplicate config, such as external databases).
So definitely work-in-progress, but I like the direction it's going :slightly_smiling_face:
it’s also worth noting that they’re working to have ALL deployment modes of Airbyte consolidated around the same Helm charts and config methods. So Self-Managed Enterprise is the same as OSS (plus they’re using the same basic Helm charts for Cloud), and in abctl they’re moving away from the old docker-compose deployments and instead using Kind to run local Kubernetes via Docker containers . . . and then everything works off the same values.yaml config and you can take one type of deployment and shift it to another method without having to re-translate everything (which wasn’t always a one-to-one mapping from the .env to values.yaml).
That makes sense. Thank you so much for your response. Appreciate it <@U035912NS77>
My code started breaking when I tried to re-deploy the helm charts and I was flying blind looking through the codebase trying to understand what this variable is.