Hello,
We’re using Sonar chart.
We upgraded the chart a few days ago + enabled persistence following your tips (Plugins automatically deleting - #7 by leo.geoffroy) and then, this morning, it seems that all the data simply disappeared (password was the default one and connexion with github was no more here so no more SSO or projects or even groups).
Is it a know problem with persistence ? Or is it coming from the chart upgrade ? Is there a solution ?
We’re using Sonarqube version 9.6.1 and the chart version 5.0.6
Thanks for your help !
Hi @Yanis_Corselle,
enabling persistence (via persistence.enabled) does not impact the actual data of sonarqube, which is stored in the database. It impacts the local files of the sonarqube container, such as plugins, elastic search index, etc.
When you upgraded the helm chart and enabled persistence, was the application behaving as expected after the operation?
My guess here is there have been some external changes to your database, or its configuration.
it looks like the database was empty when sonarqube restarted and it proceeded to load the initial configuration
Can you check the state of your database?
And from “Administration > System> Download system info”, check that the credentials for your database are correct? (keys are sonar.jdbc.url and sonar.jdbc.username)
Thanks for your answer.
yes, everything looked normal after we upgraded and the only modifications we made to the database was to regrant our admin user admin right (because i accidentally deleted admin group) : Deleted sonar-admins group by mistake
The values are “sonar.jdbc.url”:“jdbc:postgresql://sonarqube-postgresql:5432/sonarDB”
and “sonar.jdbc.username”:“sonarUser”
Do you think it should be fine ? We haven’t touched anything for it.
But, when I go to the postgresql-sonarqube pod and try to log on psql with this user and the password registered on the secret, it doesn’t works. Is it possible there is a bug in the chart with this version with postgresql ?
But in that case, is it normal sonar can still start ? Without connection to the database, shouldn’t it block at startup ?
I just saw on gcp that my persistent volume has been created this morning, is it possible the previous one have been deleted because of persistence or the chart upgrade ? Or do you know any other reason which could explain that ?
SonarQube will not start if the database is unreachable.
If no database information is provided, it starts on a H2 in memory database, but you should see a banner on the main page if it was the case.
The only change between helm chart 5.0.0 to 5.0.6 is the version increase of SonarQube (9.6.0 to 9.6.1)
Also, we highly recommend to use an external database instead of the embedded PostgreSQL database in the helm chart for other use than evaluation
Make sure that the password you are using is decoded, since secrets are stored in base64 (base64 -d)
I think the problem is not coming from the connexion with databse finally but mostly with the fact the pvc have been recreated this morning. Do you think it can be because of persistence ?
And there is no banner so it can connect to the database.
Using an external database would be a definitive solution to this so ?
Do you think it’ll be a solution for our problem of plugins disappearing too ?
The embedded postgresql database is entirely managed by the bitnami/postgresql chart as described here
If the PVC has been recreated, this is most likely due to an event that occurred in your kubernetes cluster that led to its deletion. You could check the kubernetes events or review the bitnami/postgresql resources : StatefulSet, Pods, etc… to see what happened
I imagine that changing values of postgresql.persistence in the values.yaml of the helm chart could also lead to the recreation of PVC, please refer to the official documentation for more info
Yes, the database should be set ideally outside of the k8s cluster, setup with data replication, regular backups, etc…
As I said, file persistence (persistence.enabled) should not be confused with database persistence (postgresql.enabled or jdbcOverwrite). In the case of your issue with plugins, I tend to think it comes to the file persistence, so changing the database would have probably no impact
Thanks !
We haven’t touched postgresql.persistence and haven’t seen a change on other resources but we’ll verify the bitnami/postgresql to be sure thanks.
No one reported you this problem earlier ? We are the first peoples it happens to ?
We didn’t have any report of data disappearing after the helm upgrade or file persistence activation.
Since it also occurs days after the upgrade and the PVC has been recreated, we tend to think that it is more related to an internal event that happened in your Kubernetes cluster.