[bitnami/seaweedfs] externalDatabase.initDatabaseJob does not work anymore

Name and Version

bitnami/seaweedfs 3.0.3

What architecture are you using?

amd64

What steps will reproduce the bug?

Enable external PostgreSQL database (database has been created, but is empty):
Install the chart (I'm using terraform, but hopefully this is not relevant)
The installation fails with the filer not being able to start properly

Are you using any custom parameters or values?

mariadb:
  enabled: false
externalDatabase:
  enabled: true
  store: postgresql
  initDatabaseJob:
    enabled: true
filer:
  resourcesPreset: medium
s3:
  enabled: true
  auth:
    enabled: true

What is the expected behavior?

The filer should start properly and the database should be setup correctly. Here is a correct filer start from an earlier version (bitnami/seaweedfs 2.0.0):

I1022 08:57:09.815799 config.go:53 Reading : Config File "security" Not Found in "[/etc/seaweedfs /opt/bitnami/seaweedfs /opt/bitnami/seaweedfs/.seaweedfs /usr/local/etc/seaweedfs]"
I1022 08:57:44.858394 masterclient.go:133 .filer masterClient bootstraps with masters {[seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333] <nil>}
I1022 08:57:44.858426 masterclient.go:191 .filer masterClient Connecting to master seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333
I1022 08:57:44.858465 config.go:66 Reading filer.toml from /etc/seaweedfs/filer.toml
W1022 08:57:44.858500 filer_server.go:173 skipping default store dir in ./filerldb2
I1022 08:57:44.859105 config.go:53 Reading : Config File "notification" Not Found in "[/etc/seaweedfs /opt/bitnami/seaweedfs /opt/bitnami/seaweedfs/.seaweedfs /usr/local/etc/seaweedfs]"
I1022 08:57:44.860445 masterclient.go:216 .filer masterClient Connected to seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333
I1022 08:57:44.861336 masterclient.go:316 updateVidMap(DefaultDataCenter) .filer: seaweedfs-volume-0.seaweedfs-volume-headless.kelp.svc.cluster.local:8080 volume add: 0, del: 0, add ec: 0 del ec: 0
I1022 08:57:44.892646 filer.go:153 create filer.store.id to -1615871784
[...]

What do you see instead?

Here is the file logs:

I1021 15:43:07.989015 config.go:53 Reading : Config File "security" Not Found in "[/etc/seaweedfs /opt/bitnami/seaweedfs /opt/bitnami/seaweedfs/.seaweedfs /usr/local/etc/seaweedfs]"
I1021 15:43:08.062341 masterclient.go:133 .filer masterClient bootstraps with masters {[seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333] <nil>}
I1021 15:43:08.062374 masterclient.go:191 .filer masterClient Connecting to master seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333
I1021 15:43:08.062444 config.go:66 Reading filer.toml from /etc/seaweedfs/filer.toml
W1021 15:43:08.062477 filer_server.go:173 skipping default store dir in ./filerldb2
I1021 15:43:08.063017 config.go:53 Reading : Config File "notification" Not Found in "[/etc/seaweedfs /opt/bitnami/seaweedfs /opt/bitnami/seaweedfs/.seaweedfs /usr/local/etc/seaweedfs]"
I1021 15:43:08.064543 masterclient.go:216 .filer masterClient Connected to seaweedfs-master-0.seaweedfs-master-headless.kelp.svc.cluster.local:9333
I1021 15:43:08.065378 masterclient.go:316 updateVidMap(DefaultDataCenter) .filer: seaweedfs-volume-0.seaweedfs-volume-headless.kelp.svc.cluster.local:8080 volume add: 0, del: 0, add ec: 0 del ec: 0
F1021 15:43:08.479050 filer.go:159 read filer.store.id= : kv get: pq: relation "filemeta" does not exist

Additional information

My current analysis is the following: upstream seaweedfs now performs database queries on the filemeta table during filer startup. This means that the init database job being a post-install hook now comes too late in the install process. I've tried to annotate it as pre-install but this fails because it tries to use a service account that (obviously) does not exists yet.

Quickly looking at the chart templates I would suggest to remove the init-db Job and place the init database code (create table ...) directly in the wait-for-db init container of the filer pod. This container already shares most of its configuration (image, env variables,...) and script code (waiting for database to be ready). Injecting the db init here, if enabled, seems to make sense and there would be no dependency issue between the filer starting and the db setup (after all that's exactly the purpose of an init container).

bitnami / charts