Failing tests in container

[aravindavk]

• Test basic/gfapi/glfsxmp.t is failing because it expects api directory relative to the test file.

• Loop file based tests are failing since /dev/loop* is shared accross containers.(Example: basic/afr/arbiter-statfs.t)

• AFR test failing https://github.com/gluster/glusterfs/blob/master/tests/basic/afr/afr-read-hash-mode.t#L49

• Python tests utils failure due to Python 3(Fixed)

• Geo-rep tests are disabled due to ssh setup unknown in container

• nfs related tests are failing(RCA pending)

• timeout command failed with below error after running for long time due to failures.(Search showed that failure is due to hitting ulimit -i)

    timeout: warning: timer_create: Resource temporarily unavailable
  

Major blocker is loop file based tests. If one Privileged container mounts a loop device and other privileged container runs losetup -d <dev> or losetup -D then tests in first container will fail.

(I used this script to parse tests output and print only failed tests.)

[aravindavk]

@amarts ^^

[amarts]

Thanks for this @aravindavk.

I am inclined for searching tests which are dependent on loop devices, and geo-rep tests and make a separate list, which can be run in local machine. Want to see one successful run of say 100s of tests in containers in parallel, and see if it works fine. (And also measure the gain in time).

[amarts]

Test basic/gfapi/glfsxmp.t is failing because it expects api directory relative to the test file.

Will send a fix to move glfsxmp.c to tests directory itself. It should help in other tests too. It is used heavily in many tests now to increase the code-coverage.

[amarts]

https://review.gluster.org/22845 for glfsxmp issue.

How about having a 'hacked' way of preparing the list of tests which can be picked up by a container? That way, we can schedule all the tests which require loop devices (and snapshot tests) to happen in one container only.

Also, geo-rep and some other tests (like nfs) to be schedule on local machine itself (or move them to one container).

[aravindavk]

How about having a 'hacked' way of preparing the list of tests which can be picked up by a container? That way, we can schedule all the tests which require loop devices (and snapshot tests) to happen in one container only.

Good idea. Let me try to group it.

For Geo-rep I think I can use this(https://docs.docker.com/engine/examples/running_ssh_service/) to run sshd