JDK-8221711 : [TESTBUG] create more tests for JFR in container environment
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 13
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-03-29
  • Updated: 2019-09-10
  • Resolved: 2019-04-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 13
11.0.6Fixed 13 b17Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
Specifically, planning to test these areas:
  - JFR info about environment variables within the container (host-based environment variables should not be visible)
  - basic networking (host/port namespaces, establishing connection, transmitting data)
Comments
adding request on behalf of Ekaterina Vergizova (katya@azul.com) Fix request for 11u: JFR issue, the patch applies cleanly, relevant JFR jtreg's tests passed.
05-09-2019

I have opened a new bug: "JDK-8222769: [TESTBUG] TestJFRNetworkEvents should not rely on hostname command"
19-04-2019

Sounds good. Thanks for fixing this!
19-04-2019

Severin, thank you for proposed solution (option 4) and for the LocalIpTest.java. I am for the option 4 as well. I will work on this next week, and add you as "Contributed-by" to the change set.
19-04-2019

TestJFREvents.java: testcase testEnvironmentVariables() Approach described to fix this seems the right thing to do. The assumption of JAVA_MAIN_CLASS_* always being there clearly doesn't hold. You don't need the testcase disabled. I can wait for the fix. TestJFRNetworkEvents.java: Option 1 won't work very reliably. Depending on the base image 'hostname' binary will be there or not. Special casing Fedora doesn't help. As it might break on some other images. Option 3 is similar. It could potentially break on other distro images. ArchLinux, Ubuntu, some other distro. Option 2 could work. I'm for Option 4, though, use LocalIpTest.java (see attachment). In my docker run this prints: $ sudo docker run -ti --rm fedora-host:v1 expected name = f1de71678acc expected ip = 172.17.0.2
19-04-2019

TestJFREvents.java: testcase testEnvironmentVariables() I can see, depending on how the test is launched, the JAVA_MAIN_CLASS_* is not always there. I will have to rewrite that test case to not rely on this variable, but rather have a sub-process that is started with some uniquely named variable defined by the test. I will open a bug for this. Let me know if you wish this test case excluded for time being, until the fix is implemented.
19-04-2019

[~sgehwolf] Hi Severin, Thank you for letting us know about these failures. TestJFRNetworkEvents.java: I can see couple of options here: 1. at the beginning of the main code can check if it runs on Fedora, and if it does throw jtreg.Skipped exception (which will mark the test as passed/skipped). 2. Or, this check can be done inside the container, such as JfrNetwork.java:main(), print special keyword (e.g. TEST_SKIPPED), then return. The TestJFRNetworkEvents.java can be adjusted accordingly to check for TEST_SKIPPED in the output, and not fail. 3. In JfrNetwork.java private static void verifyIpAddress(String eventIp) throws Exception { ProcessBuilder pb = new ProcessBuilder("hostname", "--ip-address"); the construction of pb could be made conditional on the system its running, and use command that works in Fedora.
18-04-2019

These tests fail for me on Fedora 29. TestJFREvents.java: ----------System.err:(15/974)---------- java.lang.RuntimeException: JAVA_MAIN_CLASS_* is not defined at TestJFREvents.getTestEnvironmentVariable(TestJFREvents.java:130) at TestJFREvents.testEnvironmentVariables(TestJFREvents.java:142) at TestJFREvents.main(TestJFREvents.java:73) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:835) There is no JAVA_MAIN_CLASS_* when I run this with: JT_JAVA=./build/linux-x86_64-server-release/images/jdk /disk/openjdk/upstream-sources/jtreg/bin/jtreg -verbose:summary -Djdk.test.docker.image.name=fedora -Djdk.test.docker.image.version=29 test/hotspot/jtreg/containers/docker test/jdk/jdk/internal/platform/docker TestJFRNetworkEvents.java: jfr_reported_container_hostname=container-unique-8221711 Exception in thread "main" java.io.IOException: Cannot run program "hostname": error=2, No such file or directory at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1128) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1071) at JfrNetwork.verifyIpAddress(JfrNetwork.java:89) at JfrNetwork.testNetworkInfo(JfrNetwork.java:84) at JfrNetwork.main(JfrNetwork.java:47) Caused by: java.io.IOException: error=2, No such file or directory at java.base/java.lang.ProcessImpl.forkAndExec(Native Method) at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:319) at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:250) at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1107) ... 4 more So it appears the expectation is that program `hostname` is part of the image, which isn't the case for "fedora:29"
18-04-2019

Addressed review feedback: http://cr.openjdk.java.net/~mseledtsov/8221711.02/
12-04-2019

In review
11-04-2019

The remaining events report correct data when run in container: environment variable info, and network host/ip. The jcmd/attach is outside of scope of events, and deserves its own test and RFE (JDK-8222043).
09-04-2019

http://cr.openjdk.java.net/~mseledtsov/8221711.01/
09-04-2019