Add hotspot_container and jdk_container test groups

[jerboaa]

Closes #4143

[jerboaa]

@ShelleyLambert @sophia-guo I'm going to need help with testing this patch. I've forgotten all about how to run those custom targets in a grinder. Note that those need to be run as a user that can do docker build and docker run. It would also be good to only run those if the test host is a physical system (not already in a container). Thanks for your help!

[smlambert]

We may want to add these new tests into <level>dev</level> and make an update to the ci-jenkins-pipeline code so that we can direct openjdk.dev test jobs to nodes that are not 'test-docker*' nodes but rather nodes that have docker installed (label = sw.tool.docker). Will chat with @sophia-guo to discuss options for ways we can ensure we do not send container tests to containers.

[jerboaa]

We may want to add these new tests into <level>dev</level> and make an update to the ci-jenkins-pipeline code

OK, I've used <level>dev</level> in the updated patch.

[smlambert]

Single test target, hotspot_container:
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6187/

All dev.openjdk targets (which currently should only be these 2, hotspot_container and jdk_container x 2 modes, nocompressedoops and compressedoops):
https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6188/

[jerboaa]

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6187/

Thank you! Looks like it failed the TestMemoryWithCgroupV1 test. That in turn seems to be missing https://bugs.openjdk.org/browse/JDK-8289146 backport?

[jerboaa]

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6187/

Thank you! Looks like it failed the TestMemoryWithCgroupV1 test. That in turn seems to be missing https://bugs.openjdk.org/browse/JDK-8289146 backport?

Can that be, though? It's supposed to be in 11.0.18+1 onwards. How would I check?

[smlambert]

You can see what OpenJDK material we pull and use in the console output of that job:

10:58:04  getOpenjdk:
10:58:04       [echo] Using a git ls-remote command to determine if the jdk source repo has an available 'u' version yet.
10:58:04       [echo] git ls-remote -h https://github.com/adoptium/jdk11u.git
10:58:04       [exec] 37542a06dc7cc1930f9d6bd54a8f04640a82d261	refs/heads/dev
10:58:04       [exec] 63e4b5c8acdb678f17541b755205e0e4feb5809c	refs/heads/jdk11.0.16.1
10:58:04       [exec] dde20e471dd77528baa922dde484e9ea92c005aa	refs/heads/master
10:58:04       [exec] 64cef94c3f9315a0997e43d60aeda53e3819099c	refs/heads/release
10:58:04       [exec] 5698142c8486928f961148c914c13255b6149b9e	refs/heads/release_jdk11.0.16.1
10:58:04       [echo] Command passed. Setting repo name to the 'u' version.
10:58:04       [exec] git clone --depth 1 -q --reference-if-able /home/jenkins/openjdk_cache -b dev https://github.com/adoptium/jdk11u.git openjdk-jdk
10:58:04       [exec] info: Could not add alternate for '/home/jenkins/openjdk_cache': reference repository '/home/jenkins/openjdk_cache' is not a local repository.
10:58:38       [exec] Check sha in openjdk-jdk and store the info in /home/jenkins/workspace/Grinder/aqa-tests/TKG/../TKG/SHA.txt
10:58:38       [exec] ================================================
10:58:38       [exec] timestamp: 20221114-155836
10:58:38       [exec] repo dir: openjdk-jdk
10:58:38       [exec] git repo: 
10:58:38       [exec]   Fetch URL: https://github.com/adoptium/jdk11u.git
10:58:38       [exec] sha:
10:58:38       [exec] 37542a06dc7cc1930f9d6bd54a8f04640a82d261
10:58:38       [exec] Check sha in openjdk-jdk and store the info in /home/jenkins/workspace/Grinder/aqa-tests/TKG/../testenv/testenv.properties
10:58:38       [exec] JDK11_REPO=https://github.com/adoptium/jdk11u.git
10:58:38       [exec] JDK11_BRANCH=37542a06dc7cc1930f9d6bd54a8f04640a82d261

or in the attached TAP file.

# timestamp: 20221114-155836
# repo dir: openjdk-jdk
# git repo: 
#   Fetch URL: https://github.com/adoptium/jdk11u.git
# sha:
# 37542a06dc7cc1930f9d6bd54a8f04640a82d261
# 

in which case we should be able to go to that repository and the particular immutable commit SHA used by this test run and check whether the backport is present.

[jerboaa]

https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6187/

Thank you! Looks like it failed the TestMemoryWithCgroupV1 test. That in turn seems to be missing https://bugs.openjdk.org/browse/JDK-8289146 backport?

Can that be, though? It's supposed to be in 11.0.18+1 onwards. How would I check?

Nah, it's there. As it suggests to run this on a system with 'cgroup_enable=memory swapaccount=1' on the kernel command line.

See https://github.com/adoptium/jdk11u/blob/37542a06dc7cc1930f9d6bd54a8f04640a82d261/test/hotspot/jtreg/containers/docker/TestMemoryWithCgroupV1.java#L94

This will require some more infra setup.

[jerboaa]

Single test target, hotspot_container: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6187/

All dev.openjdk targets (which currently should only be these 2, hotspot_container and jdk_container x 2 modes, nocompressedoops and compressedoops): https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6188/

For these tests it probably would make more sense to have two different modes. cgroup v1 and cgroup v2 :)

[jerboaa]

Latest grinder: https://ci.adoptopenjdk.net/view/Test_grinder/job/Grinder/6192/

[jerboaa]

I think this is good to go, once the infra ticket has been handled. TestMemoryWithCgroupV1.testMemoryLimitWithSwappiness is expected to fail on hosts disabling memory swap accounting.

[smlambert]

We could also limit this target to only run on x64 linux via the playlist (either with <platformRequirements> or <disables> for other platforms), but we can also restrict where this gets launched in the build pipeline itself.

related: adoptium/ci-jenkins-pipelines#501

[jerboaa]

Note that there shouldn't be any limitation on supported architectures on Linux if podman is being used as container engine. At least container-tools module providing podman is available for RHEL 8 hosts. So this would largely be an infra related limitation.

[jerboaa]

See also https://bugs.openjdk.org/browse/JDK-8297274 for the TestMemoryWithCgroupV1 test issue.

[jerboaa]

We could also limit this target to only run on x64 linux via the playlist (either with <platformRequirements>

I've added <platformRequirements>os.linux</platformRequirements> to the latest push as that seemed most appropriate.

[smlambert]

If you want to exclude TestMemoryWithCgroupV1 as per #4147 (comment) then we could additionally add an entry for TestMemoryWithCgroupV1 to the ProblemLists for it (likely depends on how long you thing
https://bugs.openjdk.org/browse/JDK-8297274 will take to fix upstream). I am happy to merge this now and assess the build pipeline runs afterwards.

[jerboaa]

I'll follow-up with exclude list updates once this is merged. We need to remove them from JDK 8 and the said cgroup v1 test without swap accounting enabled on the kernel level. Thanks!