Upgrade from using Oteemo helm chart/version to Sonarsource chart/version

Hi SQ’ers

Versions in use:
Oteemo Chart: 9.10.1
Sonarqube: 8.9.7-community
Plugin: Sonar Auth AAD 1.2.0
Postgres: 8.6.4 (bundled version)

Versions to upgrade to:
SonarSource: 6.2.0
Sonarqube: 9.7.1-community
Plugin: Sonar Auth AAD 1.3.2
Postgres: 11.14.0-debian-10-r22 (bundled version)

I am wanting to update a deployment using a version of Oteemo helm chart to use the latest SonarSource helm chart and was looking for some advice on the best path to update using the community image.

I have not attempted an upgrade as although I see some upgrade path suggestions, I didn’t see any path referring to the community edition.

Any thoughts welcomed, thanks!


Welcome to the community!

As long as you point to the same database, upgrade should be pretty seamless. Did you have specific questions?


1 Like

To add to @ganncamp answer:
If your database is running in k8s as well you need to ensure that you don’t delete the database that got created with the oteemo deployment.
Database updates in containers are tricky, so you might want to keep the old database, disable the deployment of the postgresql database from the official Helm chart and treat the old database like an external one


G Ann & NotTobi sounds like I should just tread carefully with the DB aspect. I’ll report back once I’ve updated.

Thank you :pray:

Hi NotTobi - so looking at the later chart values and your comment, that suggests that I would set my postgresql.enabled to false and use that jdbcOverwrite.enable/jdbcUrl etc. to connect to the exisiting DB. Is that correct?

A quick q: Can I assume that setting ‘postgresql.enabled’ to false will not remove the statefulset/service etc. and then the jdbc config will merely point and use the existing DB created with the Oteemo chart?


So trying the suggestion of keeping the existing postgresql DB and using the jdbcOverwrite stanza in my helm chart, using helm chart version 1.1.1+98 I get a message in the logs to upgrade the database by hitting the https://myURL/setup. This URL shows:

I have taken a backup of the database with pg_dump in both tar and sql formats. These reside on the persistent volume in use by the DB container.

Prior to upgrading I wanted to try and test this process in a staging environment. In tests I have deployed a fresh instance of postgresql DB & sonarqube using the helm chart as above and tried upgrading the DB using this method, but the upgrade fails. It looks like this method fails owing to the Sonarqube pod that is running fails its startup probe and also fails its liveness probe every 2 minutes and restarts.

Does anyone know if it is expected that the DB upgrade should be triggered by the UI or are there other methods?



I have successfully deployed my staging environment. I deployed a postgresql v8.6.4 helm chart (the same as the current version), restored a backup of the active deployed postgresql DB and then used that to point an instance of Oteemo Sonarqube helm chart 9.10.1 and this works just fine. All projects etc. are showing.

That is my staging environment ready for upgrading, albeit not tested.

Then I successfully deployed a Sonarsource SQ chart v1.1.1+98. On launching the web UI, I get the option to upgrade the database as in the above screen shot. I select to upgrade and this takes a few seconds. Sonarqube then restarts. Once restarted, it did not install a plugin required, so restarting again sorted that. I have logged in successfully.

After that, I have shutdown SQ and run ‘VACUUM FULL’ as per upgrade advice. Restarting SQ I have logged back in successfully.

Checking the DB version, this is still showing as 11.7 (the version bundled with 8.6.4 helm chart).

I am curious what the database upgrade option was all about - it does not seem to have obviously upgraded…


What happens in that step varies by version and sometimes the changes are as subtle as index updates.


1 Like

Hi again

Final update as I have now upgraded to the latest supported version.

I was facing an issue documented here which puzzled me for some while prior to seeing this article. Ultimately this was only for my staging environment, but nevertheless, I feel is worth mentioning.

Once I had tested upgrading from the Oteeemo to the Sonarsource chart things became easier. The inital migration from Oteemo to Sonarsource meant I had to delete the postgresql stateful set and deploy the updated version (using helm upgrade). Note here, my PVC is set to ‘retain’, so I knew I was always going to reuse that.

I could also see that, as Ann mentioned above, the DB updates are subtle - the pod logs evidence this.

A frustrating week in terms of creating the staging environment for testing, but feel rewarded after geting into the nuts and bolts of the process. The actual live upgrade was loads easier having gone through the testing.

Thanks, John

1 Like

For awareness, this was my upgrade path…

After each upgrade and prior to the next I ran the ‘vacuum full;’ and took a backup as per the upgrading advice.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.