You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Zabbix Server init container is unable to connect to the database if the target schema isn't the public one.
Previously, the chart was able to connect to the same database using a dedicated schema.
Version of Helm and Kubernetes:
Kubernetes 1.30.3 (Azure AKS)
What happened:
Deploying the helm chart 6.0.0 with roughly the same value file than with the 5.0.2 results in the initContainer of the zabbix-server bein stuck.
initContainer trace :
** waiting for Zabbix DB to be operational to start Zabbix server container
** Using POSTGRES_USER variable from ENV
** Using POSTGRES_PASSWORD variable from ENV
********************
* DB_SERVER_HOST: REDACTED.postgres.database.azure.com
* DB_SERVER_PORT: 5432
* DB_SERVER_DBNAME: ppd_zabbix
* DB_SERVER_SCHEMA: public
********************
** DB Version not found yet, assuming DB schema is not yet created
*** Waiting 5 seconds...
What you expected to happen:
Similarly as the 5.0.2, I expect the pod to correctly connect to the specified database and schema
How to reproduce it (as minimally and precisely as possible):
Value file is pretty basic, but we use an external database rather than a pod on the AKS cluster. We also use a secret rather than raw env variables, but it's probably irrelevant as the schema isn't settable there.
Anything else we need to know:
fix found !
Adding an extra Env manually to the init container makes it start and find the correct schema. The initContainer should have a dedicated extraEnv available in the chart, of perhaps share the one with the zabbix-server (not sure which choice should be prioritized, since there could be some externalities with the later).
** waiting for Zabbix DB to be operational to start Zabbix server container
** Using POSTGRES_USER variable from ENV
** Using POSTGRES_PASSWORD variable from ENV
********************
* DB_SERVER_HOST: _REDACTED_.postgres.database.azure.com
* DB_SERVER_PORT: 5432
* DB_SERVER_DBNAME: ppd_zabbix
* DB_SERVER_SCHEMA: ppd_zabbix
********************
** Table 'ppd_zabbix.dbversion' exists, now checking version
** db major version is 7000, zabbix version is 7000
** schema is the appropriate version, continuing checks
** amount of users in users table is 2, letting the Zabbix Server container start
Alternatively, perhaps the schema could be added as the expected specification of the database secret, alongside usr, pwd and so on ? Defaulting to public if not set ?
The text was updated successfully, but these errors were encountered:
Describe the bug
Zabbix Server init container is unable to connect to the database if the target schema isn't the public one.
Previously, the chart was able to connect to the same database using a dedicated schema.
Version of Helm and Kubernetes:
Kubernetes 1.30.3 (Azure AKS)
What happened:
Deploying the helm chart 6.0.0 with roughly the same value file than with the 5.0.2 results in the initContainer of the zabbix-server bein stuck.
initContainer trace :
What you expected to happen:
Similarly as the 5.0.2, I expect the pod to correctly connect to the specified database and schema
How to reproduce it (as minimally and precisely as possible):
Value file is pretty basic, but we use an external database rather than a pod on the AKS cluster. We also use a secret rather than raw env variables, but it's probably irrelevant as the schema isn't settable there.
Anything else we need to know:
fix found !
Adding an extra Env manually to the init container makes it start and find the correct schema. The initContainer should have a dedicated extraEnv available in the chart, of perhaps share the one with the zabbix-server (not sure which choice should be prioritized, since there could be some externalities with the later).
yaml :
trace :
Alternatively, perhaps the schema could be added as the expected specification of the database secret, alongside usr, pwd and so on ? Defaulting to public if not set ?
The text was updated successfully, but these errors were encountered: