Hello, We did a clean istall of SOnarQube8.4 developer, using the SonarQube Docker Image, on an Azure Kubernetes cluster.
The system is up and running and I can log in as administrator.
However, ZERO languages are installed.
On the quality profiles tab it says: “There are no languages available. You cannot create a new profile.”
Where are the languages?
NOTE: this was NOT an upgrade, but a clean install.
version: sonarqube:8.4.0-developer
clean install
Tried sonarqube:8.6-developer, but that failed by "Fail to unzip plugin [cssfamily] /opt/sonarqube/lib/extensions/sonar-css-plugin-1.3.1.1642.jar to /opt/sonarqube/data/web/deploy/plugins/cssfamily
.
.
Caused by: java.io.IOException: Failed setLastModified on /opt/sonarqube/lib/extensions/sonar-css-plugin-1.3.1.1642.jar"
there were some other users hitting this on AKS ( thread ) with 8.6. this is probably related to a limitation of the Azure File Storage (feature request). there is a workaround in the thread that i linked you.
As for the issues you are facing with 8.4. we changed the way we are shipping our language analyzers with 8.5 so with 8.4 you have probably overwritten the /opt/sonarqube/extensions directory inside the container with an empty volume. you need to download the analyzer plugins you need into this empty directory manually or copy them from another container that is instantiated with the 8.4 docker image into the volume.
Thank you @Tobias_Trabelsi ,
As you can see in my replies in that thread, I already struggled with this same problem a couple of weeks ago.
The instructions for installing a docker image explicitly state that you should create an external storage for the extensions.
I presume that this external store is filled from the data in the docker image (from: /opt/sonarqube/lib/extensions/)
The issue with 8.6 seems to be that it can’t set Last Modified in that path.
Do I understand correctly that 8.4 does NOT copy the plugins, but uses the plugins from the Image directly?
In that case A mapping of the ‘/opt/sonarqube/extensions/’ seems to be the cause.
We created a new, empty store for this install… It was not an upgrade.
We used the Docker Image ‘as is’ and did not overwrite anything in that image.
when you create a new volume and map it to something inside a container, the content inside the container in this specific path is not present in this context anymore (bind volume). depending on what kind of volume you create the content from inside the container is written to the volume (named volume). if you can not see any languages to configure, you probably created a bind mount (i think the named volume mount is not specified in k8s but i am not sure about that).
to work around that limitation you can populate the volume after its creation manually (as in copy the content from the image to the volume).
the part about creating a volume for /opt/sonarqube/lib/extensions is only necessary if you plan on using 3rd party plugins (download something from the marketplace) and want this to persist. if you don’t plan on doing this you can just not create a volume and be good to go as well.
as noted this is probably related to the Azure File Storage and there is very little that we can do about that.
Yes. All sonarsource plugins are in /opt/sonarqube/extensions/ in 8.4 and in /opt/sonarqube/lib/extensions/ with versions 8.5 and higher.
i was not implying that you modified the image but use a bind mount that results in the observed behavior in the resulting container
Thanks again, this explains a lot.
What confuses me still is that I created a mount for ‘/opt/sonarqube/extensions’, and that this causes ‘/opt/sonarqube/lib/extensions’ to be empty.
We did not create a mount for the latter path.
in 8.4 ALL plugins are in /opt/sonarqube/extensions
in >= 8.5 3rd party plugins are in /opt/sonarqube/extensions and sonarsource plugins that are embedded with the sonarqube version are in /opt/sonarqube/lib/extensions/
actually no. we do not document deploying in k8s as we currently do not support it and if you follow the docs for version 8.4 there is a warning about the usage of bind mounts.
for the latest and greatest this is not necessary anymore. this was mentioned in the release upgrade notes, but yeah we don’t provide detailed information what to do in every situation and if i recall correctly your original problem (with 8.6) is more related to your infrastructure (or better the azure storage not being able to handle file properties).
if you could give me an example what you think is missing (outside of the k8s context) i am happy to look into improving this
Ok, I understand that it K8s is not supported, but adding an explanation about the change in how extensions are handled or a link to where this is described can’t hurt.
Like "NOTE: between version 8.4 and 8.5 the way extensions are persisted has changed. Before 8.5 ALL plugins are in /opt/sonarqube/extensions, starting from 8.5, 3rd party plugins are in /opt/sonarqube/extensions and sonarsource plugins that are embedded with the sonarqube version are in /opt/sonarqube/lib/extensions/"
Knowing WHY you need to map one filestore and not the other really helps, imho.
And: I opted for 8.4 because I got the (wrong) impression from the replies that a clean install of that version would work. I would prefer to use 8.6 or better…
Now that I understand the root cause of the problem, I also understand how to approach a solution.
This understanding was not clear from the earlier replies.
