Plugins automatically deleting

Hi Yanis,

thanks for checking! After quite some posts and several trials, it’s better to quickly align on the architecture you are adopting :slight_smile:

  • As far as I understood, you use the latest version of the sonarqube helm chart: 6.0.1+425. Can you confirm that?
  • Can you please provide us with the values.yaml and any additional (relevant) helm parameters you were using in your last test?
  • Which cloud provider did you use in the last test?
  • You mention that your pods get restarted every day. If you can disclose, what’s the reason for that?
  • Can you please provide the exact command you use for installing the chart against the cluster?

In addition to that, in your existing cluster, can you please check if the volume attached to SonarQube contains the plugin (that are missing) in $SONARQUBE_HOME/extensions/plugins?

Please check carefully every question, and thanks for keep testing!

Hello,
Sorry for the late answer.
Yes, we’re using the latest version.
values.yaml :

ingress:
  hosts:
    - name: sonar.{{ .Values.domainName }}
      path: "/"
  tls:
    - hosts:
        - sonar.{{ .Values.domainName }}
      secretName: {{ .Values.domainName }}

plugins:
  install:
    - https://github.com/elegoff/sonar-rust/releases/download/v0.1.1/community-rust-plugin-0.1.1.jar
    - https://github.com/mc1arke/sonarqube-community-branch-plugin/releases/download/1.11.0/sonarqube-community-branch-plugin-1.11.0.jar
jvmOpts: "-javaagent:/opt/sonarqube/lib/common/sonarqube-community-branch-plugin-1.11.0.jar=web"
jvmCeOpts: "-javaagent:/opt/sonarqube/lib/common/sonarqube-community-branch-plugin-1.11.0.jar=ce"

sonarProperties:
  sonar.core.serverBaseURL: "https://sonar.{{ .Values.domainName }}"

We’re using Goocle Cloud as cloud provider.
The pods are restarting everyday because we’re using a certain category of pod which cost less but is restarted everyday.
We’re using helmfile to install the chart (helmfile -l name=sonarqube -i apply)
We decided to stop adding the plugins with the chart (because we’re trying since a few months and it still doesn’t works). We finally did our own sonarqube docker image with the plugins inside it and it seems to work so the problem should be solved in our side (but it still exists and i can’t more test it sorry)

Hi,

We’ve recently switch to SonarQube 9.7.1-enterprise o Kubernetes, using version 5.0.6+370 of the sonarqube chart and we’ve exactly the same issue. We use one and only one plugin (OpenID Connect) and this becomes uninstalled after a few hours of runtime.

Our Helm chart values are:

image:
          tag: "9.7.1-enterprise"
        # Resources for SonarQube
        resources:
          limits:
            cpu: 1600m
            memory: 4096M
          requests:
            cpu: 800m
            memory: 3Gi
        # Plugins as code
        plugins:
          install:
            - "https://github.com/vaulttec/sonar-auth-oidc/releases/download/v2.1.1/sonar-auth-oidc-plugin-2.1.1.jar"
        # OIDC configuration
        sonarProperties:
          # General
          sonar.core.serverBaseURL: "https://xxxx"
          # Security
          sonar.forceAuthentication: true
          sonar.auth.oidc.enabled: true
          sonar.auth.oidc.groupsSync: true
          sonar.auth.oidc.loginButtonText: Okta
          sonar.auth.oidc.loginStrategy: "Same as OpenID Connect login"
        sonarSecretProperties: "sonarqube-secret-properties"
        # Environment variables
        env:
          - name: SONAR_LOG_JSONOUTPUT
            value: "true"
          - name: SONAR_JDBC_HOST
            valueFrom:
              secretKeyRef:
                name: "sonarqube-database-credentials"
                key: "privateIP"
          - name: SONARQUBE_JDBC_URL
            value: "jdbc:postgresql://$(SONAR_JDBC_HOST):5432/sonarqube"
        # External database
        jdbcOverwrite:
          enable: true
          jdbcUsername: "postgres"
          jdbcSecretName: "sonarqube-database-credentials"
          jdbcSecretPasswordKey: "password"
        postgresql:
          enabled: false

Note that we intend to upgrade to 6.x version of the Chart as soon as possible and we’re also enabling persistence:

persistence:
  enabled: true
  size: 20Gi

The log of the install-plugins container is empty.

Thanks for any help,
Damien

@dcoraboeuf hi, you should try installing the plugin directly inside you own docker image (via a dockerfile)

We’ll try first to keep using the latest Helm release and enabling the storage. As much as possible, we’d like to keep using the Vanilla versions.

On my company, we already tried it and it doesn’t fix it so good luck :slight_smile:

Oh, bad news :frowning: I’ll keep you updated in this thread after our own experiments.

1 Like

Thanks, hope it’ll work for you

1 Like

Hi,

We just had the opportunity to:

  • upgrade to the latest Helm chart (6.0.1)
  • use some persistence

The plugin is correctly stored in the external disk (PVC):

image

Now, we’re just waiting to see if the problem persists.

Note that it’s likely the problem happened after the pod was relocated to another node in the cluster. In this case, using the persistence volume to fix the issue would make sense.

I’ll keep you updated,
Damien

1 Like

Hope it’ll work on your case but in ours, enabling persistance didn’t work.
the plugin was well installed but sometimes after a restart, it disappeared (and we never found why)

We have the same problem. Our infrastructure department has recommended to change from StatefulSets to Deployments. We didn’t try it

Hi,

We have:

  • enabled persistence
persistence:
          enabled: true
          size: 20Gi
  • upgraded to the latest Helm chart (6.0.1)

After one week like this, the problem has disappeared.

Best regards,
Damieb

1 Like

Hey @dcoraboeuf,

thanks for your contribution. May I ask if the problem happened again after ~3 weeks by now?

Indeed, from the chart point of you, we cannot really explain why a problem like this would occur when having the persistence value enabled. If plugins disappear, some (unintentional) deletion is performed on the PVC side which is not caused by our chart/application…