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

[Ao Qi]

On Wed, Jan 23, 2019 at 10:55 AM David Holmes <david.holmes at oracle.com> wrote:
>
> 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 will do more research. Checking docker version may be one option,
and checking whether one option is support by docker may be also one
option. I will try them later, while waiting if there are some other
opinions :)

> >>> 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.
>

I was a little afraid that filing issues that are not bugs or nobody
cares would increase the workload of others and frustrate myself, so I
was not sure what kind of issue should be filed. Now I basically
clear, thanks David.

> 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
> >>>