system tests: new tests

[edsantiago]

• podman network create: new test

• podman pull by-sha + podman images -a (podman images -a breaks after pulling <image>@<digest> #7651)

• podman image mount: new test

• podman pod: --infra-image and --infra-command ('--infra-command' parameter in pod create not working as expected #7167)

For convenience and robustness, build a new testimage
containing a custom file /home/podman/testimage-id
with contents YYYYMMDD (same as image tag). The
image-mount test checks that this file exists and
has the desired content. New testimage also includes
a dummy 'pause' executable, for testing pod infra.

Updates from testimage:20200902 to :20200917

Signed-off-by: Ed Santiago [email protected]

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago

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 [edsantiago]

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

[vrothberg]

LGTM, nice work!

[edsantiago]

Error: network 10.254.134.0/24 is already being used by a cni configuration

Sigh, I was afraid of that. I'll have to get back to this on Monday. ITM, any suggestions on how to test for a safe rfc1918 subnet?

[mheon]

I believe there's a file somewhere in the repo that we use to give Cirrus VMs a list of unusable subnets for network create (nets already in use by GCP) - maybe consulting with that would help reduce the possibility of this?

[edsantiago]

Unfortunately that doesn't help when running tests in the Fedora or RHEL gating environments. I need a bulletproof way to check the local environment.

[edsantiago]

Looking at contrib/cirrus/99-do-not-use-google-subnets.conflist I found that the whole 10.128-10.255 block is reserved for the Google environment. Since this may be subject to change without notice, I altered the network test to use the class B block (172.16-172.31) instead. This is less common, but still not any sort of guarantee that the subnet is free.

I considered adding retries, detecting "being used by a cni configuration" and rerunning the random_rfc1918 loop, but that's still fragile and introduces its own risk.

I considered parsing the output of podman network ls -> podman network inspect and, um, yeah, no.

Any better ideas?

[jwhonce]

We can refine if network selection becomes an issue

/lgtm