[Storage] Increase libguestfs pod timeout

[ema-aka-young]

What this PR does / why we need it:

Increase the timeout from TIMEOUT_1MIN (60s) to TIMEOUT_10MIN (600s) to match the product's own 500-second timeout for the libguestfs pod to reach Running state. The product code at pkg/virtctl/guestfs/guestfs.go defines timeout = 500 * time.Second for this same operation.

Which issue(s) this PR fixes:

Test failures on different lanes.

Special notes for reviewer:

jira-ticket:

CNV-62312

Summary by CodeRabbit

• Tests
  • Updated test timeout configuration to enhance pod readiness wait reliability.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 7f742355-b161-4d57-a380-ee452a4d5395

📥 Commits

Reviewing files that changed from the base of the PR and between db6df4d and af75449.

📒 Files selected for processing (1)

• tests/storage/test_libguestfs.py

---

📝 Walkthrough

Walkthrough

In tests/storage/test_libguestfs.py, the TIMEOUT_10MIN constant is added to the imports and replaces TIMEOUT_1MIN as the timeout value passed to libguestfs_pod.wait_for_status() inside the virtctl_libguestfs_by_user fixture. Import block formatting is also adjusted.

Changes

Libguestfs Pod Wait Timeout

Layer / File(s)	Summary
Import and fixture wait timeout change tests/storage/test_libguestfs.py	TIMEOUT_10MIN is imported alongside TIMEOUT_1MIN and substituted into the wait_for_status call waiting for the libguestfs-tools-* pod to reach RUNNING status.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

Possibly related PRs

• RedHatQE/openshift-virtualization-tests#4556: Directly modifies the same virtctl_libguestfs_by_user fixture's pod-running wait logic in tests/storage/test_libguestfs.py.

Suggested reviewers

• kgoldbla
• kshvaika
• Ahmad-Hafe

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title '[Storage] Increase libguestfs pod timeout' is clear, specific, and directly describes the main change in the PR—increasing the timeout for the libguestfs pod.
Description check	✅ Passed	The PR description includes all required sections with substantive content: explanation of what changed and why (timeout alignment), the issue it fixes, and the Jira ticket reference.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Stp Link Required	✅ Passed	PR only modifies existing fixture (TIMEOUT_10MIN change) in existing test file; no new test files or new test functions added, so STP/RFE/Jira link requirement does not apply.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

Warning

Review ran into problems

🔥 Problems

Linked repositories: Your configuration references 1 linked repositories, but your current plan allows 0. Analyzed ``, skipped RedHatQE/openshift-virtualization-tests-design-docs.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-virtualization-qe-bot-3]

Report bugs in Issues

Welcome! 🎉

This pull request will be automatically processed with the following features:

🔄 Automatic Actions

• Reviewer Assignment: Reviewers are automatically assigned based on the OWNERS file in the repository root
• Size Labeling: PR size labels (XS, S, M, L, XL, XXL) are automatically applied based on changes
• Issue Creation: A tracking issue is created for this PR and will be closed when the PR is merged or closed
• Branch Labeling: Branch-specific labels are applied to track the target branch
• Auto-verification: Auto-verified users have their PRs automatically marked as verified
• Labels: Enabled categories: branch, can-be-merged, cherry-pick, has-conflicts, hold, needs-rebase, size, verified, wip

📋 Available Commands

PR Status Management

• /wip - Mark PR as work in progress (adds WIP: prefix to title)
• /wip cancel - Remove work in progress status
• /hold - Block PR merging (approvers only)
• /hold cancel - Unblock PR merging
• /verified - Mark PR as verified
• /verified cancel - Remove verification status
• /reprocess - Trigger complete PR workflow reprocessing (useful if webhook failed or configuration changed)
• /regenerate-welcome - Regenerate this welcome message
• /security-override - Set security check runs to pass (maintainers only)
• /security-override cancel - Re-run security checks

Review & Approval

• /lgtm - Approve changes (looks good to me)
• /approve - Approve PR (approvers only)
• /assign-reviewers - Assign reviewers based on OWNERS file
• /assign-reviewer @username - Assign specific reviewer
• /check-can-merge - Check if PR meets merge requirements

Testing & Validation

• /retest tox - Run Python test suite with tox
• /retest build-container - Rebuild and test container image
• /retest verify-bugs-are-open - verify-bugs-are-open
• /retest all - Run all available tests

Container Operations

• /build-and-push-container - Build and push container image (tagged with PR number)
  • Supports additional build arguments: /build-and-push-container --build-arg KEY=value

Cherry-pick Operations

• /cherry-pick <branch> - Schedule cherry-pick to target branch when PR is merged
  • Multiple branches: /cherry-pick branch1 branch2 branch3
• /cherry-pick-retry <branch> - Retry a failed cherry-pick (merged PRs only)

Branch Management

• /rebase - Rebase this PR branch onto its base branch

Label Management

• /<label-name> - Add a label to the PR
• /<label-name> cancel - Remove a label from the PR

✅ Merge Requirements

This PR will be automatically approved when the following conditions are met:

1. Approval: /approve from at least one approver
2. LGTM Count: Minimum 2 /lgtm from reviewers
3. Status Checks: All required status checks must pass
4. No Blockers: No wip, hold, has-conflicts labels and PR must be mergeable (no conflicts)
5. Verified: PR must be marked as verified

📊 Review Process

Approvers and Reviewers

Approvers:

• jpeimer

Reviewers:

• Acedus
• Ahmad-Hafe
• Dsanatar
• acinko-rh
• akalenyu
• awels
• dalia-frank
• ema-aka-young
• josemacassan
• jpeimer
• kgoldbla
• kshvaika

Available Labels

• hold
• verified
• wip
• lgtm
• approve

AI Features

• Cherry-Pick Conflict Resolution: Enabled (claude/claude-opus-4-6[1m])

Security Checks

• Suspicious Path Detection: Monitors paths: .claude/, .vscode/, .cursor/, .devcontainer/, .pi/, .github/workflows/, .github/actions/
• Committer Identity Check: Verifies last committer matches PR author
• Mandatory: Security checks block merge (use /security-override to bypass — maintainers only)

💡 Tips

• WIP Status: Use /wip when your PR is not ready for review
• Verification: The verified label is removed on new commits unless the push is detected as a clean rebase
• Cherry-picking: Cherry-pick labels are processed when the PR is merged
• Container Builds: Container images are automatically tagged with the PR number
• Permission Levels: Some commands require approver permissions
• Auto-verified Users: Certain users have automatic verification and merge privileges

For more information, please refer to the project documentation or contact the maintainers.

[jpeimer]

/approve
/lgtm

[akalenyu]

So IIUC just pulling the image could take up to 10 minutes? That sounds a bit off, how big is the image? You could try crictl on the ocp node and we could compare it to upstream. Just want to make sure we don't have a huge issue somewhere.

[ema-aka-young]

@akalenyu

So IIUC just pulling the image could take up to 10 minutes? That sounds a bit off, how big is the image? You could try crictl on the ocp node and we could compare it to upstream. Just want to make sure we don't have a huge issue somewhere.

[cloud-user@worker1 ~]$ oc debug node/cnvqe-057.lab.eng.tlv2.redhat.com -- chroot /host crictl images | grep libguestfs
Starting pod/cnvqe-057labengtlv2redhatcom-debug-splbz ...
To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.

Removing debug pod ...
registry.redhat.io/container-native-virtualization/libguestfs-tools-rhel9                  <none>                                         0bc2221f5c35a       660MB

I could not pull the image for upstream but checking https://quay.io/repository/kubevirt/libguestfs-tools?tab=tags&tag=latest it looks to be 570MB.

Anyway, I think the timeout set to 10Min is conservative as it covering not only the pull of the image but also other operations that needs to be successful to have a Running Container. Replicating this manually, it never took more than 2/3 minutes but I wanted to align the test timeout with the production code.

[openshift-virtualization-qe-bot]

/build-and-push-container

[openshift-virtualization-qe-bot-4]

New container for quay.io/openshift-cnv/openshift-virtualization-tests:pr-5308 published

[openshift-virtualization-qe-bot]

Verification failed for PR #5308.
Result: FAILURE
Job: openshift-virtualization-tests-runner #5743

Execution details

pytest -s -o log_cli=true -m tier2 --jira --skip-deprecated-api-test --cluster-sanity-skip-check -k test_virtctl_libguestfs_with_specific_user --storage-class-matrix=ocs-storagecluster-ceph-rbd-virtualization
(1 parameters hidden from public report)
Image: openshift-virtualization-tests:pr-5308

[openshift-virtualization-qe-bot]

/build-and-push-container

[openshift-virtualization-qe-bot-6]

New container for quay.io/openshift-cnv/openshift-virtualization-tests:pr-5308 published

[openshift-virtualization-qe-bot]

Verification failed for PR #5308.
Result: FAILURE
Job: openshift-virtualization-tests-runner #5744

Execution details

pytest -s -o log_cli=true -m tier2 --jira --skip-deprecated-api-test --cluster-sanity-skip-check -k test_virtctl_libguestfs_with_specific_user --storage-class-matrix=ocs-storagecluster-ceph-rbd-virtualization
(1 parameters hidden from public report)
Image: openshift-virtualization-tests:pr-5308

[openshift-virtualization-qe-bot]

/build-and-push-container

[openshift-virtualization-qe-bot]

New container for quay.io/openshift-cnv/openshift-virtualization-tests:pr-5308 published

[openshift-virtualization-qe-bot]

Verification failed for PR #5308.
The pipeline did not reach the test execution stage.

Execution details

pytest -s -o log_cli=true -m tier2 --jira --skip-deprecated-api-test --cluster-sanity-skip-check -k test_virtctl_libguestfs_with_specific_user --storage-class-matrix=ocs-storagecluster-ceph-rbd-virtualization
(1 parameters hidden from public report)
Image: openshift-virtualization-tests:pr-5308

[josemacassan]

/lgtm

[akalenyu]

@akalenyu

So IIUC just pulling the image could take up to 10 minutes? That sounds a bit off, how big is the image? You could try crictl on the ocp node and we could compare it to upstream. Just want to make sure we don't have a huge issue somewhere.

[cloud-user@worker1 ~]$ oc debug node/cnvqe-057.lab.eng.tlv2.redhat.com -- chroot /host crictl images | grep libguestfs
Starting pod/cnvqe-057labengtlv2redhatcom-debug-splbz ...
To use host binaries, run `chroot /host`. Instead, if you need to access host namespaces, run `nsenter -a -t 1`.

Removing debug pod ...
registry.redhat.io/container-native-virtualization/libguestfs-tools-rhel9                  <none>                                         0bc2221f5c35a       660MB

I could not pull the image for upstream but checking https://quay.io/repository/kubevirt/libguestfs-tools?tab=tags&tag=latest it looks to be 570MB.

Anyway, I think the timeout set to 10Min is conservative as it covering not only the pull of the image but also other operations that needs to be successful to have a Running Container. Replicating this manually, it never took more than 2/3 minutes but I wanted to align the test timeout with the production code.

There is not much happening other than the pull tbh, the entrypoint is bash