SonarQube Datacenter EKS deployment fails because of values missing in template

Must-share information (formatted with Markdown):

  • SonarQube DCE 10.3
  • sonarqube-dce helm chart version 10.3.0+2009
  • trying to deploy the application to an AWS EKS cluster using the provided helm chart
  • Unfortunately, the deployment fails, because the search nodes do not have the proper permissions to create files in /opt/sonarqube/temp

I debugged the helm chart and it turns out the values.yaml setting(s)

  • searchNodes.securityContext.fsGroup
  • ApplicationNodes.securityContext.fsGroup
  • ingress.ingressClassName

which are mentioned in the readme are not even referenced in the relevant chart templates, and therefore the corresponding settings on the pods / statefulsets / ingresses are missing.

Would you be able to fix that in an upcoming release of the chart? I only need it for 10.3+ versions.

Hi @azpatrick. Welcome to our community.

Could you provide the error message that you are getting? We recently improved the security in our Helm Charts, which may have something to do with it.

You are correct that these values are not being used. Can you verify if you get the same errors by setting the values on searchNodes.persistence.uid and searchNodes.persistence.guid?

As for the ingress.ingressClassName: that is indeed a bug, and we created a ticket (SONAR-21138) to track it. In the meantime, as a workaround, you can still use the kubernetes.io/ingress.class: nginx annotation.

Hi @davi.vidal : the default values.yaml (latest version) of the sonarqube-dce chart has the securityContext.fsGroup setting - it’s just not applied in the sonarqube-search.yaml template: https://github.com/SonarSource/helm-chart-sonarqube/blob/e7176ff10bd4cb753020ef93d19cfbd3e0c93a99/charts/sonarqube-dce/values.yaml#L66

The latest version of the values.yaml and also the sonarqube-search.yaml do not utilize the searchNodes.persistence.uid and searchNodes.persistence.guid settings. I don’t think it makes a difference if I provide them - what should be the proper values?

I fixed the chart locally by adding the pod-level securityContext sections here:

{{- if .Values.searchNodes.securityContext }}
securityContext:
{{ toYaml .Values.searchNodes.securityContext | indent 8 }}
{{- end }}

1 Like

Hi @azpatrick.

searchNodes.persistence.{uid,guid} are used in the init-fs ConfigMap. That ConfigMap is used by the init-fs container in the sonarqube-search pod.

The values should be the same as your fsGroup.

Hi @azpatrick.

That’s amazing! Thanks for the feedback.
Could you provide the error you were having before and your values.yaml so I can try to reproduce it and create a ticket for this problem? :slight_smile:

This is the error:

2023.11.29 16:27:34 INFO  sonarqube-sonarqube-dce-search-0 app[][o.s.a.AppFileSystem] Cleaning or creating temp directory /opt/sonarqube/temp
2023.11.29 16:27:34 ERROR sonarqube-sonarqube-dce-search-0 app[][o.s.application.App] Startup failure
java.lang.IllegalArgumentException: Unable to create shared memory :
        at org.sonar.process.sharedmemoryfile.AllProcessesCommands.<init>(AllProcessesCommands.java:103)
        at org.sonar.application.AppFileSystem.reset(AppFileSystem.java:63)
        at org.sonar.application.App.start(App.java:53)
        at org.sonar.application.App.main(App.java:81)
Caused by: java.io.FileNotFoundException: /opt/sonarqube/temp/sharedmemory (Permission denied)
        at java.base/java.io.RandomAccessFile.open0(Native Method)
        at java.base/java.io.RandomAccessFile.open(Unknown Source)
        at java.base/java.io.RandomAccessFile.<init>(Unknown Source)
        at java.base/java.io.RandomAccessFile.<init>(Unknown Source)
        at org.sonar.process.sharedmemoryfile.AllProcessesCommands.<init>(AllProcessesCommands.java:100)
        ... 3 common frames omitted

I tried it out and the error only appears on a “fresh” install, i.e., when you install the chart on a new namespace, where the PVCs do not exist yet (and the subdirectories were not yet created there).

1 Like

But they are only applied / used when initFs.enabled is true? Otherwise the init-fs container wont run.

From the documentation:

“Based on that, one can run the SQ helm chart in a full restricted namespace, by deactivating the initSysctl.enabled and initFs.enabled parameters, which require root access.”

I cannot run any privileged containers in my environment.

1 Like

So your values.yaml has these set to false?

Can you share your values.yaml over DM with me? :slight_smile:
Your use case is really interesting to me.

Sure - how can I DM you?

I sent you a DM. You should’ve received a notification about it.

Hi @azpatrick, how are you?

I’m sorry for the delay on this topic. We made a lot of improvements in recent months, so your problem might have become obsolete.

Could you double-check if your problem persists after following our production use-case guidelines?