chore(deps): update dependency containers/automation_images to v20230405

[renovate]

This PR contains the following updates:

Package	Update	Change
containers/automation_images	major	20230307t192532z-f37f36d12 -> 20230405t152256z-f37f36d12

---

Release Notes

containers/automation_images

v20230405t152256z-f37f36d12

Compare Source

v20230330t153101z-f37f36d12

Compare Source

v20230320t154110z-f37f36d12

Compare Source

v20230314t204248z-f37f36d12

Compare Source

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Never, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[cevich]

@edsantiago FYI - this is the image-set you built that disables systemd-resolved.

[cevich]

LGTM

[edsantiago]

Leaving this here because I keep getting pulled off from tracking it down:

time="2023-04-10T18:13:18Z" level=warning msg="skipping device /dev/char/10:200 for systemd: stat /sys/dev/char/10:200: no such file or directory"'

devices.txt shows 10,200 assigned to /dev/net/tun.

[vrothberg]

/lgtm
/hold

Restarted the flaked job.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: renovate[bot], 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

[edsantiago]

I was about to scream loudly, saying something like "this is a new failure, let's try to understand it first because if it IS a flake it's going to hit us in production if we merge this". Fortunately, it's not a flake

[Luap99]

@edsantiago I guess this is a runc regression: opencontainers/runc#3620
The warning was added there it does not appear anywhere in our code base.

I guess the reason why it passes rootless is because we load /dev/net/tun there for rootless networking via slirp4netns so this file exists and no warning is printed.

[Luap99]

Looks like runc already removed net/tun device from the default list upstream: opencontainers/runc#3468
But it is not in the 1.1 branch so we get this warning now.

[edsantiago]

@cevich is it possible to side-update a renovatebot PR, or will this need to be done as a separate human-done PR? If the latter, I can try doing it.

Suggested fix:

diff --git a/contrib/cirrus/setup_environment.sh b/contrib/cirrus/setup_environment.sh
index 436024ef6..b24566e12 100755
--- a/contrib/cirrus/setup_environment.sh
+++ b/contrib/cirrus/setup_environment.sh
@@ -122,7 +122,12 @@ fi
 
 # Which distribution are we testing on.
 case "$OS_RELEASE_ID" in
-    debian) ;;
+    debian)
+        # FIXME 2023-04-11: workaround for runc regression causing failure
+        # in system tests: "skipping device /dev/char/10:200 for systemd"
+        # FIXME: please remove this once runc >= 1.2 makes it into debian.
+        modprobe tun
+        ;;
     fedora)
         if ((CONTAINER==0)); then
             # All SELinux distros need this for systemd-in-a-container

[Luap99]

@edsantiago you can just push to this branch

[edsantiago]

! [remote rejected]     pr/18124 -> refs/pull/18124/head (deny updating a hidden ref)
error: failed to push some refs to 'github.com:containers/podman.git

[Luap99]

you have to push to renovate/major-ci-vm-image as this is the branch name

[renovate]

Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠ Warning: custom changes will be lost.

[Luap99]

I restarted a bunch of tests which failed with:

Failed to start: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@5eb1ff2d[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@14d6ab93[Wrapped task = TrustedListenableFutureTask@44c61994[status=PENDING, info=[task=[running=[NOT STARTED YET], com.google.api.gax.rpc.CheckingAttemptCallable@cb7ac76]]]]] rejected from java.util.concurrent.ScheduledThreadPoolExecutor@7b54cf8d[Shutting down, pool size = 4, active threads = 0, queued tasks = 3, completed tasks = 2225]

Not sure if this is already tracked anywhere

[edsantiago]

Ha. We get that so often that I added special-case code to my flake tracker for ignoring it.

[edsantiago]

Cirrus timing:

type	distro	user	DB	local	remote	container
int	debian-12	root		26:56	36:07
int	fedora-36	root		32:09	36:41	31:17
int	fedora-37	root		31:16	34:30	28:39
int	fedora-37	root	sqlite	30:49	33:52
int	debian-12	rootless		26:04
int	fedora-36	rootless		30:08
int	fedora-37	rootless		29:25
int	fedora-37	rootless	sqlite	29:36
sys	debian-12	root		26:29	18:31
sys	fedora-36	root		30:51	21:18
sys	fedora-37	root		28:51	21:47
sys	fedora-37	root	sqlite	30:13	19:54
sys	fedora-37-aarch64	root		33:27	22:17
sys	debian-12	rootless		27:03
sys	fedora-36	rootless		28:21
sys	fedora-37	rootless		28:53	19:30
sys	fedora-37	rootless	sqlite	31:10
bud	fedora-37	root		31:07	28:44

@vrothberg as a side-channel followup to our current discussion in #15272: look at the two tests labeled "sys ... sqlite". Those are obviously not sqlite, because we do not test sqlite in system tests. So they're boltdb, so they should run in pretty much the same time as the test immediately above them ... but they're off by 90 seconds. That shows just plain normal variance between two otherwise identical test runs. It's not a precise science.

[Luap99]

/lgtm
/hold cancel