Fix more "podman-default-kube-network" flakes #18273
Conversation
openshift-ci
bot
added
release-note-none
approved
|
Link to the CI failure |
...in "built using Dockerfile" test and "play kube fail with custom selinux label" test. The latter, since it's in a test file with lots of other kube tests, I just put into BeforeEach(). References: Issue containers#17946, PR containers#18085 Signed-off-by: Ed Santiago <[email protected]>
edsantiago
force-pushed
the
another_custom_network
branch
from
a807814 to
4486891
Compare
edsantiago
changed the title
|
Link to the second failure that made me edit and repush |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: edsantiago, 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:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
No, this is not the right way to fix it. It will cause a lot more flakes. I just looked at the first two logs and see this: https://api.cirrus-ci.com/v1/artifact/task/4592789598502912/html/int-podman-fedora-36-root-host-boltdb.log.html
Please see #17975 (comment) again. We cannot ever use a custom config when you run containers.
To be explicit:
As root you can only use a custom network dir when you never run a container with it. Having the same network dir is important to avoid conflict in subnets and interface names which will cause problems at runtime in one way or another. The only exception here is containers that use the default podman network, they can be used with a custom network dir because the default network as this is built from memory with always the same values.
|
To fix these flakes you need to find the test actually deleting the configs. #18085 tried to do it, looks like there are more. |
github-actions
bot
added
the
locked - please file new issue/PR
...in "built using Dockerfile" test.
References: Issue #17946, PR #18085
Signed-off-by: Ed Santiago [email protected]