[TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus

David Holmes david.holmes at oracle.com
Wed Jan 23 02:55:21 UTC 2019


On 23/01/2019 11:58 am, Ao Qi wrote:
> Hi David,
> 
> On Wed, Jan 23, 2019 at 5:24 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>> cc'ing Bob as our containers expert ...
>>
>> On 23/01/2019 1:10 am, Ao Qi wrote:
>>> Hi,
>>>
>>> --cpus is available in Docker 1.13 and higher [1], so
>>> runtime/containers/docker/TestCPUAwareness.java failed in docker which
>>> does not support --cpus.
>>>
>>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/
>>>
>>> This patch skips the test if --cpus is not supported. I tested
>>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker
>>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and
>>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting
>>> --cpus)
>>
>> The patch causes the test to pass if launching Docker fails for any
>> reason so that is not good.
>>
> 
> I tested two versions of docker which does not support --cpus. Their
> exit values when using --cpus are 2 and 125, and outputs are:
> 
> flag provided but not defined: --cpus
> See 'docker run --help'.
> 
> and
> 
> unknown flag: --cpus
> See 'docker run --help'.
> 
> My initial thought was that the else condition of
> "output.getExitValue() == 0" should match the condition of "--cpus not
> supported". Firstly I used output.shouldMatch("docker run --help"),
> but I am not sure if all the docker version behaves this way when
> --cpus is not supported and "docker run --help" does not certainly
> indicate "--cpus not supported", so I removed the else condition.

I think we need to try and find a way to clearly identifyt eh failing 
condition. Is there are "docker --version" we coudl check?

>>> I am not sure if this is a testbug, so I did not file it on JBS. In
>>> fact, I am not quite sure what kind of issue can be filed on JBS. Is
>>> there any guidance document?
>>
>> Any/all issues can be filed on JBS. You don't need to pre-classify as a
>> testbug, simple create an issue that a test is failing under specific
>> conditions. Whomever works on the bug will then determine whether it is
>> a testbug or product issue or something else. (We don't seem to have any
>> docs on using JBS ...)
>>
> 
> What if the issue is not a bug or no body cares the issue? The issue
> will be open on JBS forever?

Possibly :) But each component team performs regular triage of the bugs 
that get filed and eventually things will be examined enough to see if 
they are indeed a bug, and if not they will be closed as not an issue. 
If a bug but low priority it may eventually get closed as "will not fix" 
just to keep the open bug count down.

Cheers,
David

> Thanks for your explanation, and I filed this issue on JBS:
> https://bugs.openjdk.java.net/browse/JDK-8217597
> 
>> In this case I'm not sure whether we require a docker version that
>> supports --cpus, and the test should be skipped otherwise. Though
>> ideally this would involve an explicit version check so we don't just
>> pass if the docker process fails.
>>
>> Thanks,
>> David
>>
>>
>>>
>>> Cheers,
>>> Ao Qi
>>>
>>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu
>>>


More information about the hotspot-runtime-dev mailing list