Skip checkpoint/restore tests on Fedora for now

[adrianreber]

There is currently still one SELinux related checkpoint/restore problem:
#2334

To avoid unnecessary CI failures the checkpoint/restore tests are
temporarily disabled on Fedora.

It is not necessary to disable the tests on Ubuntu as it is running
without SELinux and it is also not necessary to disable the RHEL 7 tests
as RHEL's CRIU is too old to run the checkpoint/restore tests at all.

Signed-off-by: Adrian Reber [email protected]

[adrianreber]

This tries to help with #2435

CC: @cevich

[vrothberg]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: adrianreber, vrothberg

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [vrothberg]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

LGTM

[giuseppe]

I've been playing with the tests suite and the checkpoint/restore tests. It would be nice to keep a whitelist of OCI runtimes that support the feature. It is not part of the OCI specs, although runc supports it.

[mheon]

@giuseppe Maybe this is something we can add to libpod.conf - whether a given runtime includes support for non-standard features like checkpoint/restore?

[adrianreber]

@giuseppe good point. Not sure how it could look like. Something like if basename(r.path) == "runc" does not sound like the best idea. Especially as a checkpoint is done by directly calling runc and a restore is done through conmon. So maybe something globally which tells Podman that special features (like checkpoint/restore) are not part of the current OCI runtime.

[cevich]

(this should also help with #1936 )

[cevich]

That's an odd test to fail on only Ubuntu podman run n user created network namespace with resolv.conf

Output shows:

Loaded image(s): docker.io/library/busybox:latest
Running: /var/tmp/go/src/github.com/containers/libpod/bin/podman --root /tmp/podman_test455853544/crio --runroot /tmp/podman_test455853544/crio-run --runtime /usr/bin/runc --conmon /usr/libexec/podman/conmon --cni-config-dir /etc/cni/net.d --cgroup-manager cgroupfs --storage-driver vfs run --net ns:/run/netns/xxx docker.io/library/alpine:latest cat /etc/resolv.conf
bash: /etc/netns/xxx/resolv.conf: No such file or directory
search c.SECRET.internal google.internal
nameserver 127.0.0.53
options edns0

Looking at test code...

[cevich]

(code test/e2e/run_networking_test.go:193)

I really can't understand how that could fail, the test before it passed fine. Unless (somehow) one of those SystemExec broke but didn't report. Re-running the test on ubuntu, hoping it's a flake.

[giuseppe]

@giuseppe Maybe this is something we can add to libpod.conf - whether a given runtime includes support for non-standard features like checkpoint/restore?

I think for the tests we could simply do something like:

$OCI_RUNTIME checkpoint --help > /dev/null 2>&1

if it fails then the OCI runtime doesn't support checkpoint/restore

[mheon]

Also works fine - I'd be fine doing that probe to check runtime capabilities

[cevich]

@adrianreber okay, looks like the test-failure is a race condition. I learned that others are seeing it as well. Pretty sure #2481 (or similar) should address it. Until that merges, we can just smash the re-test button until it passes 😕

[cevich]

There...tests all green now.

[mheon]

Code LGTM

[rhatdan]

/lgtm