Thanks for your answer.
We’re using the default values for these settings but our pods automatically restarts every day and then, sometimes the problem happen.
Maybe you could try to activate the persistence(persistence.enabled). This will persist the application folders, and this may fix your problem since in that case, the plugin is already installed at startup.
Hello, I have some new infos.
And, this morning, the plugins were installed on our instance but this afternoon, they aren’t more here … The pod didn’t restart during this time so finally it seems that it’s not during the restart that they aren’t added but seems that they are deleted after …
Anything could explain this ?
thanks for your investigation. I was trying to reproduce the missing-plugin error both in the standard and dce charts. Specifically, I installed the charts with the following parameters (see below) and then restarted all pods (including stateful sets and deployments) multiple times. The plugins are always there (installed) after every restart. So it seems that the problem does not exist in the latest versions of those two charts.
As a side note, you do not need to set the plugins.lib parameter to install plugins, we are gonna fix this in a related task.
About the othemo chart, we adopt a similar logic but not in all cases. We might run into issues if plugins are installed manually from the marketplace (UI). They will be likely gone in many cases after a pod restart. I’ve created a new task about this, but it should not impact this particular case.
Can you please try to set the previous parameters, use the latest version of standard or dce charts, and tell us if you run into issues again when scaling up and down resources?
Hello, Thanks you both (sorry @leo.geoffroy for the late answer, i haven’t seen your message).
I’m going to test this, i’ll tell you the results;
We’re using standard chart so what i’ll tell you would be about this one.
Hello,
We launched it yes, for now the plugins are still there but each time, the stays a few days or weeks before disappearing so i don’t already know if they’ll stay …
Sorry for the late answer, that was sent to my professional mail and i’m in internship so while i was at school, i haven’t seen your message
thanks for checking! After quite some posts and several trials, it’s better to quickly align on the architecture you are adopting
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!
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)
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.