I’m attempting to deploy the sonarqube 8.0.0+463 helm chart into an OpenShift cluster and it’s failing due to the Readiness probe. After some investigation, I’ve uncovered the following.
The ReadinessProbe executes a wget to the api system status and includes the “–proxy off” parameter. As far as I can tell, that “–proxy” parameter isn’t supported by wget and hasn’t been for a long time. That hasn’t been an issue with previous versions (< SQ 9.9) because the SonarQube container was using “Alpine Linux” as its OS and the version of wget included would ignore the “–proxy off” parameter. Now that the latest SQ 9.9 version has switched to Ubuntu, it’s using a different version of wget. When wget is now executed with the “–proxy off” parameter, wget attempts to resolve the hostname “off”, fails, and then resolves the API URL. The issue with our setup is that the DNS timeout for “off” takes over a second as it recursively checks DNS names, and by the time it retrieves the API system status result (which is UP), the ReadinessProbe timeout kicks in at 1 sec and thus exits 1.
It seems the best way to deal with this is to change the “–proxy off” parameter to the expected parameter of “–no-proxy”.
If for whatever reason that isn’t feasible, then expose the ReadinessProbe timeout value to the chart so that it can be increased to allow for a failed resolving of the hostname “off”.
Hopefully this makes sense and can be verified internally.
thanks for reporting this issue. We were actually able to replicate it and defined a bug-fix (SQHELM-118) task to tackle it
You say that you are installing our chart on Openshift: that’s great! We do actually not support Openshift yet, but we would love to gain feedback from users that are deploying SQ on it successfully with the official chart. Can you tell us which were the (extra) steps that you had to perform in order the have our chart successfully deployed? Did you need to act on some security constraints (SCC) of your cluster?
We are also using the sonarsource helm chart in our Openshift environment.
And it’s running fine.
We had some trouble with the SecurityContextConstraint which 2 initContainers needed.
( init-fs and init-sysctrl ) Our team made a ‘temporary’ SCC in our gitops-management environment.
We are stil looking for an alternative.
And with the upgrade to LTS 9.9 ( from 9.7.1 ) we had some trouble with the install-plugins init container. Something(?) went wrong when deleting the present plugins.
At the restart of the new LTS 9.9 environment, it complaned that there were two versions of the AzureAD plugin, so the sonarqube pod didn’t start.
We had to remove the physical volume to get it up and running again.
I clould see that the rights on the extension directory are different.
The rights in 9.7.1 are:
drwxr-sr-x. 2 sonarqube sonarqube 4096 Mar 7 09:09 downloads
drwxrwsr-x. 2 root sonarqube 4096 Mar 7 09:08 plugins
and in 9.9 LTS it is:
drwx------ 2 sonarqub sonarqub 4096 Feb 9 15:28 downloads
drwx------ 2 sonarqub sonarqub 4096 Feb 9 15:28 plugins
@nflohr before we mark the discussion post as solved (we are gonna tackle your suggested fix before the next release, thanks again for reporting it), do you also have time to give us feedback on the following subject?
As a side note, for using a ServiceMonitor (instead of a PodMonitor), I had to use postRenderers to add the Prometheus Exporter ports to the Service. It would be a nice enhancement to allow configuring of more ports for the Service.