Ensure correct IPC mode handling in system tests

[bitoku]

In environment where the default ipc mode is host, it fails the test.
This PR ensures the ipc mode.

Does this PR introduce a user-facing change?

None

[giuseppe]

Wondering if it would be better to use CONTAINERS_CONF_OVERRIDE= and an empty config file to test if the default shareable is used, but either way, the proposed fix is an improvement, so:

LGTM

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bitoku, giuseppe

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

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

[Luap99]

IMO this is the wrong thing to do, the tests are not designed to run with arbitrary containers.conf settings and I am sure many more will fail.
We assume certain defaults and it is a good thing to actual test/use the defaults so we notice what breaks if someone changes the default.

In particular this change turn this test into podman --ipc=shareable which does the same thing already so we now test the same thing twice which is not good.

So I would strongly prefer to not merge this, or similar patches.

[bitoku]

Thanks for the comment!

the tests are not designed to run with arbitrary containers.conf settings and I am sure many more will fail.

Then why we have skip_if_* tests?

We assume certain defaults and it is a good thing to actual test/use the defaults so we notice what breaks if someone changes the default.

If we want to care about that, why don't we have the test to ensure that? Currently the test aims to check two things (the config default and ipc flag), which is worse I think.

In particular this change turn this test into podman --ipc=shareable which does the same thing already so we now test the same thing twice which is not good.

This is a kind of setup for the next --ipc=container test, so it's somewhat overlapped but required.

[bitoku]

If so, don't you have any test sets that ensures that the system has a capability of running podman?

[Luap99]

Then why we have skip_if_* tests?

Because we target a certain amount of envs that we test, local vs remote, fedora vs debian, selinux, etc...
Some might depend on a specific when things need to be skipped, but to me this is entirely different from I am using a non default containers.conf and expect all tests to pass. There are hundreds of options in containers.conf, expecting all tests to work with all possible option is simply unsustainable.

We assume certain defaults and it is a good thing to actual test/use the defaults so we notice what breaks if someone changes the default.

If we want to care about that, why don't we have the test to ensure that? Currently the test aims to check two things (the config default and ipc flag), which is worse I think.

The test is called --ipc=container, the assumption is that this works because the default ipc mode is shareable. And that is how most users would actually use it so I don't see what is wrong with it.

If so, don't you have any test sets that ensures that the system has a capability of running podman?

I don't understand what that means, what capabilities? Podman is very complex and what will or will not work totally depends on the underlying environment. I have no idea what you want to test for, podman run $IMAGE should tell you if you can run a container or not.

Our tests are designed for podman upstream testing and distro gating testing (primarily fedora and RHEL). I am not interested in targeting more envs simply due the high maintenance required.

[bitoku]

ok.
I wanted to test what podman can/can't do in nested container (in podman and in cri-o).
I still think this helps understand what's required to pass the test, and if we want to check unexpected change in default config, we can implement a new test to check it.
However, if podman maintainers are on the same page, feel free to close it.