opal_path_nfs test is undeterministic and may fail in chroot environments (such as mock)

[dvandok]

Rebuilding from the source RPM (http://koji.fedoraproject.org/koji/buildinfo?buildID=636070) failed in our private mock environment at the moment the opal_path_nfs test was run.

The reason is that mock runs in a chroot environment, which doesn't expose the mount points from outside on the inside. But mock will mount the /proc directory before doing the chroot, so in /proc all the mounts from outside are visible. We happen to have some NFS mounts on the build machines. The test will assert that these are recognised by opal_path_nfs as being NFS mounts, but inside the chroot they really are not. The output of the mount command can not really be relied upon.

https://github.com/open-mpi/ompi/blob/master/test/util/opal_path_nfs.c#L137

Overall, the test depends too much on circumstance, as it may run a test if an NFS mount point is found and will just pass otherwise. For a deterministic, repeatable build process I would recommend to skip this test by default.

[jsquyres]

Admittedly, that test is fragile. However, we need it because we've inadvertantly broken the mount-listing functionality a few times -- this test keeps us honest.

How about a compromise: if the test detects that it is running in a mock environment, it just calls exit(77).

Elsewhere in the code, we check for $FAKEROOTKEY, $FAKED_MODE, and $SANDBOX_ON. Are any of these environment variables set by mock? If not, is there some kind of marker that this test can search for to know that it's running under mock?

[dvandok]

Sorry to get back so late about this. I missed the notifications while I wasn't using github for a while.

The compromise sounds fine. I'm not sure how reliable it is, but mock seems to set HOSTNAME=mock and change PROMPT_COMMAND as well to include mock-chroot:
PROMPT_COMMAND='printf "\x1b]0;<mock-chroot>\x07<mock-chroot>"'

HTH,

Dennis