"streaming output" logs test: fix flake

[edsantiago]

Test has been flaking excessively. A quick look shows that
the test itself is broken, making a bad assumption.

'podman logs -f' is guaranteed to exit when a container
terminates. This does not (and should not) mean that the
container has been cleaned up. It is undefined and unsafe
to run 'podman run -n same-name-as-terminated-container'
immediately after 'podman logs' exits.

Solution: instead of 'podman run', do 'podman inspect'.
This, too, is unsafe, but we can expect to see one of
two possible conditions:

1. command succeeds, in which case we require that
   container State.Status be "exited"; or
2. command fails, in which case we expect "no such
   container" in error output

For full coverage we should add a small delay-check test
to (1) to ensure that the container is cleaned up after
a short amount of time. Leaving that as a TODO because
it's more than my Go skills can handle, and I want to
get this checked in ASAP to get rid of the flake hassle.

Signed-off-by: Ed Santiago santiago@redhat.com

[vrothberg]

LGTM, let's get this in 👍

Thanks, Ed!

[mheon]

/lgtm
/hold

[mheon]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: edsantiago, mheon

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [mheon]

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

[rhatdan]

LGTM

[TomSweeneyRedHat]

LGTM

[jgallucci32]

@edsantiago Will this test break if we revert the logs -f logic back to its previous state where it would hang indefinitely? PR #6644 reverts back to the original state where logs would hang when following a stopped container. It should still pass a test where the container is removed because that should stop following the logs.

[edsantiago]

@jgallucci32 the podman logs part of this test is untouched since June 2019, so I expect that nothing should change.

[edsantiago]

/hold cancel
Whew! Flakes were mostly the "logs -f" race condition, but also one weird "rmi" one.

test fedora-32 fedora-32

2020-06-17T07:50:36 integration_test

• Podman rmi [It] podman rmi image that is a parent of another image
• [same]
• [same]

test ubuntu-20 ubuntu-20

2020-06-17T07:45:51 system_test

• 47 podman kill - test signal handling in containers

2020-06-17T08:23:23 system_test

• 47 podman kill - test signal handling in containers

[vrothberg]

Great work, Ed!

I can take a look at the rmi ones (bookmarked) tomorrow. It is popping up frequently but I couldn't yet reproduce.

[jgallucci32]

@edsantiago I just rebased #6644 to make sure this doesn't break backing out of the follow logs code added this week.