RFR(XS): 8189213: [TESTBUG] Running jtreg tests on machine without docker shows extra message

[mikhailo]

On 11/07/2017 06:01 PM, David Holmes wrote:
> Hi Misha,
> On 8/11/2017 7:36 AM, mikhailo wrote:
>>>> Does it work for you Bob? David, are you OK with this approach?
>>> I think this is an improvement and I’m ok with this approach but I 
>>> don’t see that it will save that much time.
>>> Starting docker takes  a while (worse the first time).  I’ve seen 
>>> 1sec startup times.  Let see what David thinks
>>> of the /tmp caching idea.  You’d have to put the user that found and 
>>> successfully ran docker and have to deal
>>> with multi-process write access to the file.
>> OK. There is another option that will work well, but requires one 
>> extra input from user. We could designate a property that would state 
>> whether a host is docker capable. When user wishes to execute docker 
>> tests locally she/he will set the property to true. When executed via 
>> Oracle automated test system, the system will set this property to 
>> true on docker capable test nodes. All that VMProps will do is check 
>> the property, so no docker ps any more, not even searching for docker 
>> on a known locations.
>>
>> As for naming, I can propose this: jdk.test.lib.docker.capable.node. 
>> Alternative suggestions of names welcome.
>>
>> This makes the check clear, simple and reliable. What do you think?
>
> This doesn't work if the intent is that we happen to add a 
> docker-enabled machine to a test pool. You can't selectively set the 
> property only when run on the right host (if you could then we'd only 
> run the tests on that host in the first place).
>
> But you seemed to have moved from fixing this bug - 8189213 - to 
> trying to address the new RFE 8190730.
You are right. I got carried away with this discussion.

I should fix the "JDK-8189213 - [TESTBUG] Running jtreg tests on machine 
without docker shows extra message" first, and then work on

"JDK-8190730 - [TESTBUG] Calling 'docker ps' from VMProps.java to 
determine presence of docker engine is deemed too heavy".


So, the fix for this issue is simple, as we agreed before - remove the 
message. Here is a webrev:
http://cr.openjdk.java.net/~mseledtsov/8189213.02/

May I count you as a Reviewer for JDK-8189213?


Thank you,
Misha


P.S. As for JDK-8190730, I will try to summarize the discussion in the 
comments of the JBS issue.

>
> Thanks,
> David
>
>>
>> Thank you,
>> Misha
>>
>>
>>>
>>> Bob.
>>>
>>>
>>>>> This is probably breaking new ground, but can we cache the result 
>>>>> of “docker ps” in /tmp in order to eliminate the performance
>>>>> overhead for all but the first time a new user runs these tests?
>>>> I try to keep this solution simple. If you and David approve the 
>>>> solution above, I will implement and test it. If we find any 
>>>> problems, either during my testing or during test production, we 
>>>> could look into caching mechanisms.
>>>>
>>>>
>>>> Thank you,
>>>> Misha
>>>>> Bob.
>>>>>>
>>>>>> Thank you,
>>>>>> Misha
>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> Let me know what you think. I can revert this part of the 
>>>>>>>> change or reduce the timeout value a bit more.
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Misha
>>>>>>>>>> For this change under review, if I do not hear opinions from 
>>>>>>>>>> other reviewers, I can simply delete the print statement.
>>>>>>>>> Sounds good to me.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> David
>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> Misha
>>>>>>>>>>> Thanks,
>>>>>>>>>>> David
>>>>>>>>>>>
>>>>>>>>>>> On 3/11/2017 7:03 AM, mikhailo wrote:
>>>>>>>>>>>> Please review this simple change that makes the error 
>>>>>>>>>>>> message in jtreg-ext/requires/VMProps.java conditional
>>>>>>>>>>>> on java property "vmprops.trace.verbose". W/o this 
>>>>>>>>>>>> condition an error message is printed each time any jtreg
>>>>>>>>>>>> test is ran, including non-docker tests.
>>>>>>>>>>>>
>>>>>>>>>>>>       JBS: https://bugs.openjdk.java.net/browse/JDK-8189213
>>>>>>>>>>>>       Webrev: 
>>>>>>>>>>>> http://cr.openjdk.java.net/~mseledtsov/8189213.00/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ======= Background and details:
>>>>>>>>>>>> VMProps.java is called for each test run of jtreg (be it a 
>>>>>>>>>>>> run containing a singe test or multiple tests).
>>>>>>>>>>>> VMProps evaluates the @requires properties. Therefore, in 
>>>>>>>>>>>> case of this bug, any time a user runs any jtreg VM test
>>>>>>>>>>>> on a machine w/o an operational docker engine, this error 
>>>>>>>>>>>> will pop up.
>>>>>>>>>>>> The fix makes printing of this error message conditional, 
>>>>>>>>>>>> off by default. The message can be turend on
>>>>>>>>>>>> via a property vmprops.trace.verbose when detailed 
>>>>>>>>>>>> diagnostic info is desired.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ======== Testing:
>>>>>>>>>>>> Local testing:
>>>>>>>>>>>>     W/o docker present:
>>>>>>>>>>>>       jtreg <arbitrary-jtreg-test>
>>>>>>>>>>>>         No error message
>>>>>>>>>>>>       jtreg -Dvmprops.trace.verbose=true 
>>>>>>>>>>>> <arbitrary-jtreg-test>
>>>>>>>>>>>>         Detailed error message
>>>>>>>>>>>>       jtreg DockerBasicTest.java
>>>>>>>>>>>>         Test skipped
>>>>>>>>>>>>
>>>>>>>>>>>>     With docker installed but no permissions:
>>>>>>>>>>>>       jtreg <arbitrary-jtreg-test>
>>>>>>>>>>>>         No error message
>>>>>>>>>>>>       jtreg -Dvmprops.trace.verbose=true 
>>>>>>>>>>>> <arbitrary-jtreg-test>
>>>>>>>>>>>>         Detailed error message
>>>>>>>>>>>>       jtreg DockerBasicTest.java
>>>>>>>>>>>>         Test skipped
>>>>>>>>>>>>
>>>>>>>>>>>>     With docker installed and operational:
>>>>>>>>>>>>       jtreg <arbitrary-jtreg-test>
>>>>>>>>>>>>         No error message
>>>>>>>>>>>>       jtreg -Dvmprops.trace.verbose=true 
>>>>>>>>>>>> <arbitrary-jtreg-test>
>>>>>>>>>>>>         No error message
>>>>>>>>>>>>       jtreg DockerBasicTest.java
>>>>>>>>>>>>         Test passed
>>>>>>>>>>>>
>>>>>>>>>>>> Testing via automated distributed test system:
>>>>>>>>>>>>     - tier1
>>>>>>>>>>>>     - docker tests
>>>>>>>>>>>>     In progress
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you,
>>>>>>>>>>>> Misha
>>>>>>>>>>>>
>>