Installing database step takes longer when chart is used as a dependency

[fabiocarneiro]

EDIT: read comments first

Which chart: mysql

Describe the bug When using the chart as a dependency of another chart, even after deleting the PVC (and PV), somehow the release data still seems to be persisted. When MySQL container starts it executes this part of the initialization script

To Reproduce

works as expected:

1. helm install my-release-12345 bitnami/mysql
2. helm delete my-release-12345
3. kubectl delete pvc data-my-release-12345-mysql-0
4. helm install my-release-12345 bitnami/mysql

does not work as expected:

1. helm install release-name ./helm/local-chart-example
2. helm delete release-name
3. kubectl delete pvc data-release-name-mysql-0
4. helm install release-name ./local-chart-example

Expected behavior

When deleting my release, deleting the PVC for MySQL on my release, and installing it again, it should run the authentication setup step again and not detect existing data. This also happens even when it is the first install of that release name (and with --generate-name, but I also tried to delete the release, remove the PVC/PV to illustrate the issue. I repeated this more than 10 times.

Version of Helm and Kubernetes:

• Output of minikube version:

minikube version: v1.13.1
commit: 1fd1f67f338cbab4b3e5a6e4c71c551f522ca138-dirty

• Output of helm version:

version.BuildInfo{Version:"v3.1.2", GitCommit:"d878d4d45863e42fd5cff6743294a11d28a9abce", GitTreeState:"clean", GoVersion:"go1.13.8"}

• Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.0", GitCommit:"e19964183377d0ec2052d1f1fa930c4d7575bd50", GitTreeState:"clean", BuildDate:"2020-08-26T14:30:33Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.2", GitCommit:"f5743093fd1c663cb0cbc89748f730662345d44d", GitTreeState:"clean", BuildDate:"2020-09-16T13:32:58Z", GoVersion:"go1.15", Compiler:"gc", Platform:"linux/amd64"}

Output of MySQL container logs

mysql 19:51:24.93 
mysql 19:51:25.12 Welcome to the Bitnami mysql container
mysql 19:51:25.43 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mysql
mysql 19:51:25.93 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mysql/issues
mysql 19:51:26.74 
mysql 19:51:26.91 INFO  ==> ** Starting MySQL setup **
mysql 19:51:30.02 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mysql 19:51:30.23 INFO  ==> Initializing mysql database
mysql 19:51:31.92 WARN  ==> The mysql configuration file '/opt/bitnami/mysql/conf/my.cnf' is not writable. Configurations based on environment variables will not be applied for this file.
mysql 19:51:31.94 INFO  ==> Using persisted data
mysql 19:51:34.02 INFO  ==> Running mysql_upgrade
mysql 19:51:35.12 INFO  ==> Starting mysql in background

[fabiocarneiro]

Ok, I noticed that in the case of using this chart as a dependency (no idea why it doesn't behave the same when installed directly), the container was always restarting, and when checking the logs, I was already receiving the output of the second time. By accident, I was able to catch it the first time and noticed that the container is getting killed during the Installing database step.

mysql 20:00:47.31 
mysql 20:00:47.32 Welcome to the Bitnami mysql container
mysql 20:00:47.34 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mysql
mysql 20:00:47.42 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mysql/issues
mysql 20:00:47.44 
mysql 20:00:47.62 INFO  ==> ** Starting MySQL setup **
mysql 20:00:47.94 INFO  ==> Validating settings in MYSQL_*/MARIADB_* env vars
mysql 20:00:48.04 INFO  ==> Initializing mysql database
mysql 20:00:48.82 WARN  ==> The mysql configuration file '/opt/bitnami/mysql/conf/my.cnf' is not writable. Configurations based on environment variables will not be applied for this file.
mysql 20:00:48.84 INFO  ==> Installing database

[fabiocarneiro]

I temporarily solved the issue by increasing the primary.livenessProbe.initialDelaySeconds from 120 to 600. This is anyway too much because I could see the initialization completed in ~5 minutes.

I think maybe relying purely on time is not enough because this can vary from system to system. Maybe something that only writes to disk if the process was completed at least once (or re-runs the steps anyway in case of failure)?

[dani8art]

Hi @fabiocarneiro,

Are you sure that ~5 minutes are used to installing the database, that is too much, I think it could be related to resources, are you setting them up? has your cluster them set by default to some values? I mean the rest of the applications in the chart or the cluster could be getting too many resources if they are not limited, so the mariadb pods have few resources and because of that, they are taking a lot of time to finish the setup.

You can handle resources in the mariadb chart like: primary.resources and secondary.resources

## MariaDB primary container's resource requests and limits
  ## ref: http://kubernetes.io/docs/user-guide/compute-resources/
  ##
  resources:
    # We usually recommend not to specify default resources and to leave this as a conscious
    # choice for the user. This also increases chances charts run on environments with little
    # resources, such as Minikube. If you do want to specify resources, uncomment the following
    # lines, adjust them as necessary, and remove the curly braces after 'resources:'.
    limits: {}
    #   memory: 256Mi
    #   cpu: 100m
    requests: {}
    #   memory: 256Mi
    #   cpu: 100m

Also, you can use http://kubernetes.io/docs/user-guide/compute-resources/ to set your deployments resources.

[stale[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[fabiocarneiro]

@dani8art I'm sure it takes 5x to 10x longer than when using the chart directly with helm install. I don't remember the exact time but I think I saw 5+ minutes when inspecting with kubectl.

I did not modify any of the settings in either the dependency approach or the direct approach.

I don't think it's related to resources. If that was the case the behavior would be the same for both. Unless there is a difference related to resources when Chart is used as a dependency. The machine I'm using is powerful, I can install either my app or the chart in whatever order and the slower one is always when installed as a dependency. When installed directly I did it 5 times sequentially and all of them worked as expected. I also repeated more than 20 times as a dependency and all of them show the same slow behavior.

I also don't think this should be closed without investigation. It is very frustrating when you just add the dependency and it doesn't work, you start to think the chart is bad.

To reproduce it should not be so hard. Need to create a chart and add it as a dependency.

[dani8art]

Sorry for this issue being closing automatically but we were waiting for additional information and tests about resources.

Could you provide more relevant details about your environment?

Thanks!

[fabiocarneiro]

@dani8art What else do you want to know? I already provided the versions of everything above.

[dani8art]

Hi I've tried to reproduce it but unfortunately, I couldn't reproduce it, this is what I did:

$ k get pods -w
NAME                 READY   STATUS    RESTARTS   AGE
mysql-standalone-0   0/1     Pending   0          3s
mysql-standalone-0   0/1     Pending   0          4s
mysql-standalone-0   0/1     ContainerCreating   0          4s
mysql-standalone-0   0/1     Running             0          30s
mysql-standalone-0   1/1     Running             0          60s

So it seems a standalone chart took like 60s to be ready, then I created a test-chart that uses MySQL as subchart.

$ k get pods -w
NAME                                         READY   STATUS              RESTARTS   AGE
mysql-standalone-0                           1/1     Running             0          3m29s
mysql-subchart-0                             0/1     Pending             0          3s
mysql-subchart-test-chart-75cc6c98b7-cr4c5   0/1     ContainerCreating   0          3s
mysql-subchart-test-chart-75cc6c98b7-cr4c5   0/1     Running             0          4s
mysql-subchart-0                             0/1     Pending             0          4s
mysql-subchart-0                             0/1     ContainerCreating   0          4s
mysql-subchart-test-chart-75cc6c98b7-cr4c5   1/1     Running             0          11s
mysql-subchart-0                             0/1     Running             0          29s
mysql-subchart-0                             1/1     Running             0          62s

And MySQL took 62s to get ready.

Are you setting something specific in the values? I requested more info because this is what I can reproduce with the data that you are providing.

[kheraud]

I face the exact same issue using mysql chart as dependency:

globaldb:
  fullnameOverride: global-db
  architecture: standalone
  primary:
    persistence:
      enabled: false
  auth:
    username: overrideme
    password: overrideme
    database: overrideme
    rootPassword: overrideme
  # Load config map with database and user creations
  initdbScriptsConfigMap: db-init-script
  commonAnnotations:
    argocd.argoproj.io/sync-wave: "-10"

The target init script is small. Just a database and user creation

λ  infra-k8s feature/client-platform ✗ kdp -n test-client-platform global-db-0
Name:         global-db-0
Namespace:    test-client-platform
Priority:     0
Node:         aks-default-92330148-vmss000001/10.11.0.255
Start Time:   Mon, 08 Feb 2021 16:37:00 +0100
Labels:       app.kubernetes.io/component=primary
              app.kubernetes.io/instance=test-client-platform
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=globaldb
              controller-revision-hash=global-db-74976c888d
              helm.sh/chart=globaldb-8.2.7
              statefulset.kubernetes.io/pod-name=global-db-0
Annotations:  checksum/configuration: f40a8e05fd02d88b91686b2b298d95fca5871bd3d02d0967a0df21830ecb44fc
Status:       Running
IP:           10.11.1.94
IPs:
  IP:           10.11.1.94
Controlled By:  StatefulSet/global-db
Containers:
  mysql:
    Container ID:   docker://139c16d3b47e7a91d050d855147986c4e8c6ccdcf2440c8bc5bf8e6064bb5946
    Image:          docker.io/bitnami/mysql:8.0.23-debian-10-r0
    Image ID:       docker-pullable://bitnami/mysql@sha256:726854187b8f5d232ebd400e6fe8a259afa42b81793efc7aadd6843b2a853897
    Port:           3306/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Mon, 08 Feb 2021 16:49:11 +0100
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Mon, 08 Feb 2021 16:46:11 +0100
      Finished:     Mon, 08 Feb 2021 16:49:06 +0100
    Ready:          True
    Restart Count:  4
    Liveness:       exec [/bin/bash -ec password_aux="${MYSQL_ROOT_PASSWORD:-}"
if [[ -f "${MYSQL_ROOT_PASSWORD_FILE:-}" ]]; then
    password_aux=$(cat "$MYSQL_ROOT_PASSWORD_FILE")
fi
mysqladmin status -uroot -p"${password_aux}"
] delay=120s timeout=1s period=10s #success=1 #failure=3
    Readiness:  exec [/bin/bash -ec password_aux="${MYSQL_ROOT_PASSWORD:-}"
if [[ -f "${MYSQL_ROOT_PASSWORD_FILE:-}" ]]; then
    password_aux=$(cat "$MYSQL_ROOT_PASSWORD_FILE")
fi
mysqladmin status -uroot -p"${password_aux}"
] delay=30s timeout=1s period=10s #success=1 #failure=3
    Environment:
      BITNAMI_DEBUG:        false
      MYSQL_ROOT_PASSWORD:  <set to the key 'mysql-root-password' in secret 'global-db'>  Optional: false
      MYSQL_USER:           notused
      MYSQL_PASSWORD:       <set to the key 'mysql-password' in secret 'global-db'>  Optional: false
      MYSQL_DATABASE:       notused
    Mounts:
      /bitnami/mysql from data (rw)
      /docker-entrypoint-initdb.d from custom-init-scripts (rw)
      /opt/bitnami/mysql/conf/my.cnf from config (rw,path="my.cnf")
      /var/run/secrets/kubernetes.io/serviceaccount from global-db-token-fnmwz (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      global-db
    Optional:  false
  custom-init-scripts:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      db-init-script
    Optional:  false
  data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  global-db-token-fnmwz:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  global-db-token-fnmwz
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age                From                                      Message
  ----     ------     ----               ----                                      -------
  Normal   Scheduled  18m                default-scheduler                         Successfully assigned test-client-platform/global-db-0 to aks-default-92330148-vmss000001
  Warning  Unhealthy  16m (x3 over 16m)  kubelet, aks-default-92330148-vmss000001  Liveness probe failed: mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/opt/bitnami/mysql/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/opt/bitnami/mysql/tmp/mysql.sock' exists!
  Normal   Killing    16m                   kubelet, aks-default-92330148-vmss000001  Container mysql failed liveness probe, will be restarted
  Warning  Unhealthy  15m                   kubelet, aks-default-92330148-vmss000001  Readiness probe failed: OCI runtime exec failed: exec failed: container_linux.go:370: starting container process caused: process_linux.go:103: executing setns process caused: exit status 1: unknown
  Normal   Created    15m (x2 over 18m)     kubelet, aks-default-92330148-vmss000001  Created container mysql
  Normal   Pulled     15m (x2 over 18m)     kubelet, aks-default-92330148-vmss000001  Container image "docker.io/bitnami/mysql:8.0.23-debian-10-r0" already present on machine
  Normal   Started    15m (x2 over 18m)     kubelet, aks-default-92330148-vmss000001  Started container mysql
  Warning  Unhealthy  8m33s (x45 over 17m)  kubelet, aks-default-92330148-vmss000001  Readiness probe failed: mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/opt/bitnami/mysql/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/opt/bitnami/mysql/tmp/mysql.sock' exists!

It requires 18 min to start the mysql single pod container.

I will play with requests / limits to change QoS class

[juan131]

Hi @fabiocarneiro

I guess that globaldb.* parameters are the one passed to MySQL, right?

The target init script is small. Just a database and user creation

Could you share that script? It looks like it's affecting MySQL and it's stopped after running it.

Also, please note that, to create a custom user/database you don't need to load a custom script. Using the auth.username, auth.password, and auth.database parameters should be enough.

[kheraud]

Thanks for your quick reply.

I use a script to create many users and databases :

# Source: client-platform/templates/db-init-script.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: db-init-script
  namespace: "default"
  annotations:
    # This annotation permits to have this migration script created before db
    argocd.argoproj.io/sync-wave: "-20"
data:
  01-create-agw-db.sql: |
    CREATE DATABASE IF NOT EXISTS `gateway`;
  02-create-agw-user.sql: |
    CREATE USER IF NOT EXISTS "gateway"@"%" IDENTIFIED BY "gateway";
    GRANT SELECT, INSERT, UPDATE, DELETE ON `gateway`.* TO "gateway"@"%";
  03-create-whk-db.sql: |
    CREATE DATABASE IF NOT EXISTS `webhook`;
  04-create-whk-user.sql: |
    CREATE USER IF NOT EXISTS "webhook"@"%" IDENTIFIED BY "webhook";
    GRANT SELECT, INSERT, UPDATE, DELETE ON `webhook`.* TO "webhook"@"%";

Playing with requests / limits do not solve the problem. Even with a Guaranteed QoS class I still need many minutes...

During the boot process, the engine turns up (readiness probe confirms it) then the engine restarts and liveness probe fails. This on / off booting process leads to flapping readiness.

Even with a straight direct helm install, I can confirm this flapping :

λ  infra-k8s feature/client-platform ✗ kgp -n helm-install -w
NAME          READY   STATUS    RESTARTS   AGE
global-db-0   0/1     Running   0          116s
global-db-0   1/1     Running   0          3m7s
global-db-0   0/1     Running   1          3m17s
global-db-0   1/1     Running   1          4m58s
λ  infra-k8s feature/client-platform ✗ kdp -n helm-install global-db-0
Name:         global-db-0
Namespace:    helm-install
Priority:     0
Node:         aks-default-92330148-vmss000000/10.11.0.4
Start Time:   Tue, 09 Feb 2021 09:57:47 +0100
Labels:       app.kubernetes.io/component=primary
              app.kubernetes.io/instance=helm-install-mysql
              app.kubernetes.io/managed-by=Helm
              app.kubernetes.io/name=mysql
              controller-revision-hash=global-db-5c8cbdf76b
              helm.sh/chart=mysql-8.2.7
              statefulset.kubernetes.io/pod-name=global-db-0
Annotations:  checksum/configuration: 32e1be1e4b5a47d1d7750e90f81818769dca79fc52b3d0ea40e711f4287c2ca7
Status:       Running
IP:           10.11.0.54
IPs:
  IP:           10.11.0.54
Controlled By:  StatefulSet/global-db
Containers:
  mysql:
    Container ID:   docker://54d2ecb286542751d848c6d1c0911266985de45749d49cb15e7ef2bb7ecb4b77
    Image:          docker.io/bitnami/mysql:8.0.23-debian-10-r0
    Image ID:       docker-pullable://bitnami/mysql@sha256:726854187b8f5d232ebd400e6fe8a259afa42b81793efc7aadd6843b2a853897
    Port:           3306/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Tue, 09 Feb 2021 10:01:01 +0100
    Last State:     Terminated
      Reason:       Error
      Exit Code:    137
      Started:      Tue, 09 Feb 2021 09:57:57 +0100
      Finished:     Tue, 09 Feb 2021 10:00:58 +0100
    Ready:          True
    Restart Count:  1
    Limits:
      cpu:     500m
      memory:  512Mi
    Requests:
      cpu:     250m
      memory:  256Mi
    Liveness:  exec [/bin/bash -ec password_aux="${MYSQL_ROOT_PASSWORD:-}"
if [[ -f "${MYSQL_ROOT_PASSWORD_FILE:-}" ]]; then
    password_aux=$(cat "$MYSQL_ROOT_PASSWORD_FILE")
fi
mysqladmin status -uroot -p"${password_aux}"
] delay=120s timeout=1s period=10s #success=1 #failure=3
    Readiness:  exec [/bin/bash -ec password_aux="${MYSQL_ROOT_PASSWORD:-}"
if [[ -f "${MYSQL_ROOT_PASSWORD_FILE:-}" ]]; then
    password_aux=$(cat "$MYSQL_ROOT_PASSWORD_FILE")
fi
mysqladmin status -uroot -p"${password_aux}"
] delay=30s timeout=1s period=10s #success=1 #failure=3
    Environment:
      BITNAMI_DEBUG:        true
      MYSQL_ROOT_PASSWORD:  <set to the key 'mysql-root-password' in secret 'global-db'>  Optional: false
      MYSQL_USER:           overrideme
      MYSQL_PASSWORD:       <set to the key 'mysql-password' in secret 'global-db'>  Optional: false
      MYSQL_DATABASE:       overrideme
    Mounts:
      /bitnami/mysql from data (rw)
      /docker-entrypoint-initdb.d from custom-init-scripts (rw)
      /opt/bitnami/mysql/conf/my.cnf from config (rw,path="my.cnf")
      /var/run/secrets/kubernetes.io/serviceaccount from global-db-token-6f26c (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Volumes:
  config:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      global-db
    Optional:  false
  custom-init-scripts:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      db-init-script
    Optional:  false
  data:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
    Medium:
    SizeLimit:  <unset>
  global-db-token-6f26c:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  global-db-token-6f26c
    Optional:    false
QoS Class:       Burstable
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                 node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason     Age    From                                      Message
  ----     ------     ----   ----                                      -------
  Normal   Scheduled  6m30s  default-scheduler                         Successfully assigned helm-install/global-db-0 to aks-default-92330148-vmss000000
  Warning  Unhealthy  3m53s  kubelet, aks-default-92330148-vmss000000  Readiness probe failed: mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: connect to server at 'localhost' failed
error: 'Lost connection to MySQL server at 'reading initial communication packet', system error: 104'
  Warning  Unhealthy  3m50s (x3 over 4m10s)  kubelet, aks-default-92330148-vmss000000  Liveness probe failed: mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/opt/bitnami/mysql/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/opt/bitnami/mysql/tmp/mysql.sock' exists!
  Normal   Killing    3m49s                   kubelet, aks-default-92330148-vmss000000  Container mysql failed liveness probe, will be restarted
  Warning  Unhealthy  3m34s (x13 over 5m44s)  kubelet, aks-default-92330148-vmss000000  Readiness probe failed: mysqladmin: [Warning] Using a password on the command line interface can be insecure.
mysqladmin: connect to server at 'localhost' failed
error: 'Can't connect to local MySQL server through socket '/opt/bitnami/mysql/tmp/mysql.sock' (2)'
Check that mysqld is running and that the socket: '/opt/bitnami/mysql/tmp/mysql.sock' exists!
  Normal   Created    3m17s (x2 over 6m22s)  kubelet, aks-default-92330148-vmss000000  Created container mysql
  Normal   Pulled     3m17s (x2 over 6m24s)  kubelet, aks-default-92330148-vmss000000  Container image "docker.io/bitnami/mysql:8.0.23-debian-10-r0" already present on machine
  Normal   Started    3m15s (x2 over 6m20s)  kubelet, aks-default-92330148-vmss000000  Started container mysql
  Warning  Unhealthy  3m15s                  kubelet, aks-default-92330148-vmss000000  Readiness probe errored: rpc error: code = Unknown desc = container not running (552d225d914f96ff363c0b3685e8793d445bf947279d14a6d72503a9ab900a02)
λ  infra-k8s feature/client-platform ✗

[fabiocarneiro]

Hi @fabiocarneiro

I guess that globaldb.* parameters are the one passed to MySQL, right?

The target init script is small. Just a database and user creation

Could you share that script? It looks like it's affecting MySQL and it's stopped after running it.

Also, please note that, to create a custom user/database you don't need to load a custom script. Using the auth.username, auth.password, and auth.database parameters should be enough.

On my side, the values.yaml looks like this:

mysql:
  auth:
    rootPassword: redacted
    database: redacted
    password: redacted
  primary:
    livenessProbe:
      initialDelaySeconds: 600

The dependencies on chart.yaml

dependencies:
  - name: mysql
    version: 8.2.1
    repository: https://charts.bitnami.com/bitnami

The livenessProbe change was added as a hack to allow the process to complete before being interrupted by k8s

[juan131]

Hi @kheraud

Can I suggest using a single .sql with all the instructions to create the database/users? I'm not sure that we're guaranteeing execution order based on the file prefix (01-, 02-, etc.), see:

https://github.com/bitnami/bitnami-docker-mysql/blob/master/8.0/debian-10/rootfs/opt/bitnami/scripts/libmysql.sh#L334

It could be possible that you're trying to grant permissions to certain user on a database before this database exists.

[kheraud]

You are totally right @juan131 , I missed this obvious mistake

I kept tracking this performance issue. When I have 70% CPU available (kubectl top nodes) I can see a real improvement in chart deployment delay. I fine tuned my autoscaling settings to keep this CPU margin. I would try in the coming weeks to dive more deeply in the chart to point the exact issue.

[juan131]

Great @kheraud !! I'm glad you were able to solve it by using a single .sql file! Please do not hesitate to share with us your insights about the database performance. That said, I'd appreciate if you open a different issue to discuss this so we avoid confusion (we should try to stick to the topic of each issue so other users looking for answers can easily identify them).

[kheraud]

IMHO we can close this issue. The performance issue I had were totally related to node specifications and available CPU

[juan131]

Let's close the issue. Please feel free to reopen it if you require further help with this.