Bigbang upgrade breaks Sonarqube

Feature Request

Why

What is the use case for the feature you are requesting? What are you trying to solve?

Every BigBang upgrade breaks SonarQube. On the highside we use CA Certs. After every upgrade we have to modify SonarQube values.yaml and uncomment caCerts, image, secret, enabled. In the SonarQube templates/Deployment.yaml have to add the following to the args command: chmod 0750 /tmp/certs/cacerts Then we have to tag the commit and reference that tag in our Override. Also, had to increase the initContainers memory to 300Mi because 8Mi was too small.

added teamXForce label

added kindbug label

added BB Customer Issues label

The initContainer is definitely something we can/should update memory limits on if you're seeing immediate crashes OOM.

For the args changes, that's something we can investigate and think about adding as well - but I suspect that's more tied to the chosen image and permissions in that image. It might be best for us to allow a full override of that command via values so that a customer can modify as needed based on the image they use.

I'm not sure I follow this part: we have to modify SonarQube values.yaml and uncomment caCerts, image, secret, enabled. If you have values overrides for Sonarqube you can pass them via the following, in your BB values/configmap:

addons:
  sonarqube:
    values:
      # example
     caCerts:
       image: adoptopenjdk/openjdk11:alpine
       secret: my-secret

You shouldn't have to modify the sonar chart to do that.

set weight to 2

added priority6 label

changed iteration to Big Bang Iterations Nov 30, 2021 - Dec 13, 2021

changed milestone to %1.23.0

assigned to @michaelmartin

added statusdoing label

created merge request !1129 (merged) to address this issue

mentioned in merge request !1129 (merged)

I've been able to re-produce the OOM easily when bringing in a cert, and I bumped the defaults to 300Mi.

As @micah.nagel mentioned, and the method I used for testing, using a helm overrides file allows setting the secret without needing to modify values.yaml. I'm not sure what we should/want to do here.

For the permissions error, I suspect it's due to the init container used. I'll work on allowing the command/args to be customized and testing with an init container with /tmp permissions locked down.

added statusreview label and removed statusdoing label

Package MR merged and tagged.

The changes now allow one to override the ca-certs init container command and arguments.

I suspect the root of the permissions issue was the initial file permissions in the caCerts.image image under ${JAVA_HOME}/lib/security/cacerts and also the user/permissions set to run in the image or possibly umask issues. hard to say without seeing the image, but these changes should allow full control over the cert-loading process.

Here's an example of using overrides to chmod the file after the cp.

addons:
  sonarqube:
    values:
      caCerts:
        image: adoptopenjdk/openjdk11:alpine
        secret: my-secret
        command: ["sh"]
        args: ["-c", "cp -f \"${JAVA_HOME}/lib/security/cacerts\" /tmp/certs/cacerts; chmod 755 /tmp/certs/cacerts; if [ \"$(ls /tmp/secrets/ca-certs)\" ]; then for f in /tmp/secrets/ca-certs/*; do keytool -importcert -file \"${f}\" -alias \"$(basename \"${f}\")\" -keystore /tmp/certs/cacerts -storepass changeit -trustcacerts -noprompt; done; fi"]

closed with merge request !1129 (merged)

mentioned in commit 511c122b

removed statusreview label