Openjdk-tests: Map host user to docker user while mounting volumes in external tests

[Mesbah-Alam]

This issue is to track the work done to map the host user 'jenkins' to docker container user 'root' while mounting volumes to extract junit xml reports produced by external tests.

Background
There is an issue in mapping output reports directory of the docker image onto the host machine, in that, the files that get copied over down to the host machines are owned by root, whereas the user that tries to wipe clean Jenkins workspace directories in the host machines uses jenkins user. This causes workspaces to not get cleaned up properly.

[Mesbah-Alam]

One solution to mapping user id is described here: https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/ - This however involves updating /etc/subgid and /etc/subuid files on the host machine. @sxa555 - is it feasible?

[sxa]

Yeah that sort of thing should be feasible - we could just map root in the container to always to be the jenkins ID on the host system

[Mesbah-Alam]

@sxa555 - before we can try out this solution, we need the changes added for jenkins user, as described in that article, in /etc/subgid and /etc/subuid files in the docker enabled machine(s). Those files are read-only to me (logged in as 'jenkins'). Could you please make those changes? We can start off with just one machine to first prove it works.

[sxa]

Any preference for which machine, and I haven't gone through the article in detail but if I add those will docker pick them up automatically? I'm away from civilisation tomorrow until Monday evening but can try and add anything needed in tonight

[Mesbah-Alam]

Only the docker enabled machines need this change: https://ci.adoptopenjdk.net/label/sw.tool.docker/

No, apparently docker won't pick them up directly, we need to start docker with --userns-remap USER - as stated in the document (I haven't had a chance to try it out and prove it yet obviously).

[sxa]

OK I've added jenkins:1000:1 to the /etc/subuid on test-packet-ubuntu1604-x86-1 and addd -userns-remap jenkins to the options. Hopefully that's enough to do something. Give it a shot and we'll see!

[Mesbah-Alam]

I ran a test https://ci.adoptopenjdk.net/view/work%20in%20progress/job/TestBuild_Sandbox2/289/ (ran on ubuntu1604-x64-1: {ip: 169.55.150.155}).

However, the mapped files are still owned by 'root' and can't be deleted by jenkins (as seen in /workspace/TestBuild_Sandbox2/openjdk-tests/TestConfig/test_output_15314965878739/lucene_solr_nightly_smoketest_0/external_test_reports).

I am wondering if the configuration on the docker side has taken effect properly.

@sxa555 - It looks like we needed a restart of the docker daemon after adding userns-remap jenkins to the options (as stated in https://www.jujens.eu/posts/en/2017/Jul/02/docker-userns-remap/). Was the restart done?

(Another relevant link: https://stackoverflow.com/questions/35291520/docker-and-userns-remap-how-to-manage-volume-permissions-to-share-data-betwee)

[sxa]

Yes I did a restart of docker

[sxa]

Can you clarify what the underlying command is that's being used for that job so I can reproduce it? The job won't run standalone and what it's doing seems to be hidden underneath a bunch if jenkins scripts

[Mesbah-Alam]

The underlying commands can be found in scripts here: https://github.com/Mesbah-Alam/openjdk-tests/tree/openjdk-tests-issue-475/thirdparty_containers/lucene-solr

The dockerfile it is using is : https://github.com/Mesbah-Alam/openjdk-tests/blob/openjdk-tests-issue-475/thirdparty_containers/lucene-solr/dockerfile/Dockerfile

The docker run command is in https://github.com/Mesbah-Alam/openjdk-tests/blob/openjdk-tests-issue-475/thirdparty_containers/lucene-solr/playlist.xml: docker run --rm -v $(JDK_HOME):/java -v $(REPORTDIR)/external_test_reports:/lucene-solr/lucene/build/core/test adoptopenjdk-lucene-solr-test:latest

Is this the information you were looking for?

[Mesbah-Alam]

We no longer need this work item as we are using docker cp option to copy report xmls. Details in https://github.com/AdoptOpenJDK/openjdk-tests/issues/514