@kapa.ai I’m trying to set up the Airbyte kubernetes deployment with external database and we have the databases ready for airbyte, temporal and temporal_visibility. Also I have used temporal-sql-tool to create the necessary tables. But the server pods and worker pods are failing throwing an error - “waiting for namespace default to be initialized in temporal”. Can someone please explain why this error is popping out. Note: I have tried the same in development and it worked. I have followed the same steps for prod and its failing

The error "waiting for namespace default to be initialized in temporal" typically occurs when the Temporal service, which Airbyte uses for orchestration, is unable to initialize the default namespace. This could be due to a variety of reasons such as connectivity issues with the database, insufficient permissions, or issues with the database schema. From the knowledge sources, it seems that others have encountered similar issues when deploying Airbyte with an external database on Kubernetes. Here are a few things you could check: 1. Database Connectivity: Ensure that the Temporal service can connect to your external database. You can verify this by checking the logs of the Temporal pod. 2. Database Permissions: The user specified in your configuration should have the necessary permissions on the

temporal

and

temporal_visibility

databases. In one of the [forum posts](https://discuss.airbyte.io/t/2179), the user confirmed that the

airbyte

user had the required grants over these databases. 3. Database Schema: Even though you've mentioned that you've used

temporal-sql-tool

to create the necessary tables, it might be worth double-checking that the schema has been set up correctly. In one of the [Github issues](https://github.com/airbytehq/airbyte/issues/32267), the user encountered an error because the Temporal service was unable to list search attributes, which suggests a potential issue with the database schema. 4. Namespace Initialization: In another [Github issue](https://github.com/airbytehq/airbyte/issues/19212), the user was able to resolve a similar error by deleting

volume

and

volumeMounts

in the airbyte-cron deployment. This was done to address an issue where a PVC was already being used by another pod. If you've checked all of the above and are still encountering the error, it might be helpful to provide more detailed logs from the Temporal pod for further investigation.