Skip to content

test(xfs): add migration tests for VMs with XFS v4 filesystem#503

Open
Chenli-Hu wants to merge 1 commit into
RedHatQE:mainfrom
Chenli-Hu:xfs
Open

test(xfs): add migration tests for VMs with XFS v4 filesystem#503
Chenli-Hu wants to merge 1 commit into
RedHatQE:mainfrom
Chenli-Hu:xfs

Conversation

@Chenli-Hu

@Chenli-Hu Chenli-Hu commented May 19, 2026

Copy link
Copy Markdown
Contributor

Summary by CodeRabbit

  • New Features
    • Added an optional XFS v4 compatibility flag to migration planning.
    • Warm and cold migration runs can now verify XFS v4 by executing a configurable command on migrated VMs and validating expected output.
  • Tests
    • Added new warm and cold end-to-end XFS verification test suites (vSphere to OpenShift).
  • Documentation
    • Updated test documentation with the XFS verification pattern and configuration details; refreshed test-marker guidance.
  • Refactor
    • Standardized VM command execution for post-migration checks and shared-disk verification.

@coderabbitai

coderabbitai Bot commented May 19, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@Chenli-Hu, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 27 minutes and 58 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: a16f7b54-6b29-414a-be23-ed69a3e895c5

📥 Commits

Reviewing files that changed from the base of the PR and between 842b6a7 and 2dece99.

📒 Files selected for processing (9)
  • AGENTS.md
  • README.md
  • tests/cold/test_cold_migration_xfs.py
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_xfs.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/shared_disk.py
  • utilities/ssh_utils.py

Walkthrough

Adds XFS compatibility wiring for plan creation, SSH command helpers, XFS test configuration, and warm/cold migration test flows with XFS verification.

Changes

XFS Migration Support

Layer / File(s) Summary
Plan flag wiring
AGENTS.md, utilities/mtv_migration.py
Adds xfs_compatibility to create_plan_resource, documents the optional flag, and conditionally includes it in the Plan spec.
SSH command execution helpers
utilities/ssh_utils.py, utilities/post_migration.py, utilities/shared_disk.py
Adds run_cmd_in_vm, adds check_vm_command_output, and switches shared-disk command execution to the shared SSH helper.
Test guidance and parameters
AGENTS.md, README.md, tests/tests_config/config.py
Updates XFS migration guidance, adds the vsphere marker entry, and registers warm and cold XFS test parameters with xfs_compatibility and xfs_check settings.
Warm XFS migration test
tests/warm/test_warm_migration_xfs.py
Defines the warm XFS migration test class, creates MTV resources, executes migration, verifies XFS output, and checks migrated VMs.
Cold XFS migration test
tests/cold/test_cold_migration_xfs.py
Defines the cold XFS migration test class, creates MTV resources, executes migration, verifies XFS output, and checks migrated VMs.

Sequence Diagram(s)

sequenceDiagram
  participant Test as XFS migration test
  participant MTV as create_plan_resource
  participant Mig as execute_migration
  participant Verify as check_vm_command_output
  participant Validate as check_vms
  Test->>MTV: create StorageMap, NetworkMap, Plan
  Test->>Mig: execute migration with xfs_compatibility enabled
  Test->>Verify: run xfs_info and check output
  Test->>Validate: validate migrated VMs
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Suggested reviewers

  • krcmarik
  • solenoci
  • myakove

Possibly related PRs

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title accurately summarizes the main change: adding migration tests for VMs with XFS v4 filesystem compatibility.
Docstring Coverage ✅ Passed Docstring coverage is 92.59% which is sufficient. The required threshold is 80.00%.
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.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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

Comment @coderabbitai help to get the list of available commands.

@redhat-qe-bot

Copy link
Copy Markdown

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: Disabled for this repository
  • 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: All label categories are enabled (default configuration)

📋 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

Review & Approval

  • /lgtm - Approve changes (looks good to me)
  • /approve - Approve PR (approvers only)
  • /automerge - Enable automatic merging when all requirements are met (maintainers and 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 conventional-title - Validate commit message format
  • /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

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. Status Checks: All required status checks must pass
  3. No Blockers: No wip, hold, has-conflicts labels and PR must be mergeable (no conflicts)
  4. Verified: PR must be marked as verified

📊 Review Process

Approvers and Reviewers

Approvers:

  • myakove
  • solenoci

Reviewers:

  • krcmarik
  • myakove
  • solenoci
Available Labels
  • hold
  • verified
  • wip
  • lgtm
  • approve
  • automerge
AI Features
  • Conventional Title: Mode: fix (claude/claude-opus-4-6[1m])
  • Cherry-Pick Conflict Resolution: Enabled (claude/claude-opus-4-6[1m])
  • Test Oracle: Triggers: approved (cursor/gpt-5.4-xhigh-fast); /test-oracle can be used anytime

💡 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.

@redhat-qe-bot redhat-qe-bot requested a review from solenoci May 19, 2026 00:44
@redhat-qe-bot redhat-qe-bot requested a review from myakove May 19, 2026 00:44
@redhat-qe-bot redhat-qe-bot requested a review from krcmarik May 19, 2026 00:44
@redhat-qe-bot redhat-qe-bot changed the title Warm migrate VM with XFS v4 from vSphere feat(MTV-595): add warm migration test for VMs with XFS v4 filesystem May 19, 2026

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@utilities/utils.py`:
- Around line 305-315: The code currently mutates the input list via
networks.remove(...) and networks.insert(...), which can leak order across
callers; instead construct and return a new list so the original networks
argument is not modified: after finding pod_net (the result of next(...)), build
a new list with pod_net first followed by all other entries filtered out (use
networks and custom_pod_network to filter), and return that new list; keep the
existing ValueError behavior when pod_net is None and reference the same symbols
(pod_net, networks, custom_pod_network) so the change is localized.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 02b43eca-2a31-467e-b8e6-358366e4a560

📥 Commits

Reviewing files that changed from the base of the PR and between f82917b and 8ed18dc.

📒 Files selected for processing (4)
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_comprehensive.py
  • utilities/mtv_migration.py
  • utilities/utils.py

Comment thread utilities/utils.py Outdated
@Chenli-Hu

Chenli-Hu commented May 19, 2026

Copy link
Copy Markdown
Contributor Author

Hi @krcmarik , please help to review, thank you!
I tested in local, both 1) and 2) are passed on MTV 2.11.6.
There is a bug: MTV-5419 on 2.12.0, without that fix the warm migration will failed on MTV 2.12.0. => Tested on latest 2.12.0, the bug is fixed, both 1) and 2) passed on 2.12.0-40.

1)Migrate cloned xfs VM only
#uv run pytest -vv -m "tier0" -k "comprehensive-warm-xfs" --tc=source_provider:"vcenter" --tc=storage_class:"nfs-csi" ....

2)Migrate both cloned mtv-win2022-ip-3disks and cloned mtv-feature-rhel7-xfs
#uv run pytest -vv -m "tier0" -k "comprehensive-warm" --tc=source_provider:"vcenter" --tc=storage_class:"nfs-csi"....


tests/warm/test_warm_migration_comprehensive.py::TestWarmMigrationComprehensive::test_create_storagemap[comprehensive-warm-xfs] PASSED
_ 1 of 5 completed, 1 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/warm/test_warm_migration_comprehensive.py::TestWarmMigrationComprehensive::test_create_networkmap[comprehensive-warm-xfs] PASSED
_ 2 of 5 completed, 2 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/warm/test_warm_migration_comprehensive.py::TestWarmMigrationComprehensive::test_create_plan[comprehensive-warm-xfs] PASSED
_ 3 of 5 completed, 3 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/warm/test_warm_migration_comprehensive.py::TestWarmMigrationComprehensive::test_migrate_vms[comprehensive-warm-xfs] PASSED
_ 4 of 5 completed, 4 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/warm/test_warm_migration_comprehensive.py::TestWarmMigrationComprehensive::test_check_vms[comprehensive-warm-xfs] PASSED
_ 5 of 5 completed, 5 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _
======== 5 passed, 211 deselected, 3021 warnings in 1589.90s (0:26:29) =========

@Chenli-Hu

Chenli-Hu commented May 19, 2026

Copy link
Copy Markdown
Contributor Author

/verified

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/warm/test_warm_migration_comprehensive.py`:
- Line 193: The test currently enables preserve_static_ips by default via
prepared_plan.get("preserve_static_ips", True), which implicitly turns the
feature on for plans that never declared it; change this to read the flag
without a default so missing keys are treated as absent (e.g., use
prepared_plan["preserve_static_ips"] or otherwise pass the explicit value from
the test fixture) to avoid silently enabling static-IP validation paths—update
the call site that sets preserve_static_ips to stop using .get(..., True) and
instead require an explicit value from prepared_plan.

In `@utilities/mtv_migration.py`:
- Around line 146-147: You've added a new positional parameter xfs_compatibility
before target_power_state which breaks existing positional callers; change the
function signature to keep existing positional binding by either moving
xfs_compatibility after target_power_state or make it keyword-only (e.g., put
"*, xfs_compatibility: bool = False" after target_power_state) so old callers
still bind target_power_state correctly, and then update any call sites/tests
that intentionally pass xfs_compatibility positionally to use the keyword form.

In `@utilities/post_migration.py`:
- Around line 1257-1276: The code resolves destination_vm_name but still uses
vm_name when creating the SSH connection and logging; update usages to target
the migrated VM by replacing vm_name with destination_vm_name in
vm_ssh_connections.create and in the LOGGER.info message (leave
get_ssh_credentials_from_provider_config(source_provider_data, source_vm_data)
and the win_os check as-is so credentials and OS checks still come from
source_vm_data). Ensure vm_ssh_connections.create(...) is called with
vm_name=destination_vm_name and corresponding log text reflects the destination
VM.

In `@utilities/utils.py`:
- Around line 258-259: The current call to _reorder_networks_by_pod_network can
raise a ValueError when custom_pod_network is missing even though pod_only=True
makes reordering unnecessary; update the condition around the call so it only
runs when custom_pod_network is truthy AND pod_only is False (i.e., guard the
call with "if custom_pod_network and not pod_only") to skip reordering in
pod_only mode; reference symbols: custom_pod_network, pod_only,
_reorder_networks_by_pod_network, networks.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 4da22c4c-e415-4cb9-abe3-75542d1da274

📥 Commits

Reviewing files that changed from the base of the PR and between 8ed18dc and 4a38083.

📒 Files selected for processing (5)
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_comprehensive.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/utils.py

Comment thread tests/warm/test_warm_migration_comprehensive.py Outdated
Comment thread utilities/mtv_migration.py Outdated
Comment thread utilities/post_migration.py
Comment thread utilities/utils.py Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@utilities/post_migration.py`:
- Around line 1475-1488: The XFS check calls check_vm_command_output whenever
plan.get("xfs_compatibility") is true, causing failures if the destination VM is
powered off; update the condition to also verify the destination VM is powered
on (e.g., vm.get("power_state") == "on" or an existing vm_powered_on flag) and
only run check_vm_command_output when vm_ssh_connections and
plan.get("xfs_compatibility") are true AND the VM is powered on, keeping the
existing try/except and res[vm_name].append(...) behavior for error reporting.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9e1102a9-cf8a-4744-9f84-80712626103e

📥 Commits

Reviewing files that changed from the base of the PR and between 4a38083 and 9c5c0b4.

📒 Files selected for processing (6)
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_comprehensive.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/utils.py
  • utilities/vmware_guest_operations.py

Comment thread utilities/post_migration.py Outdated
@qodo-code-review

qodo-code-review Bot commented May 27, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (4)

Grey Divider


Action required

1. source_vms_data defaulted to {} 📘 Rule violation ☼ Reliability
Description
check_vm_command_output() silently defaults missing plan["source_vms_data"][vm_name] to {},
even though it uses that data to infer Windows-vs-Linux and select SSH credentials, which can
mis-detect guest OS (e.g., treat Windows as Linux) and fail later for misleading reasons. This
violates the intended fail-fast behavior and can cause confusing downstream post-migration
validation failures.
Code

utilities/post_migration.py[R1320-1333]

Evidence
PR Compliance ID 9 requires rejecting invalid or missing required data early with a clear exception,
but the implementation uses plan.get("source_vms_data", {}).get(vm_name, {}), allowing absent
source_vms_data or missing VM entries to propagate into OS detection and credential selection
without an explicit failure. Because credential selection is driven by the win_os flag taken from
this optional/feature-specific structure (treated elsewhere as required only for specific features
like static-IP preservation), missing data can cause Windows guests to be treated as Linux and lead
to check failures for the wrong reason rather than a clear, immediate error at the point of use.

CLAUDE.md: Fail Fast: Do Not Allow Invalid None Values to Propagate
utilities/post_migration.py[1320-1333]
utilities/post_migration.py[39-81]
utilities/post_migration.py[1294-1336]
utilities/post_migration.py[1444-1454]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`check_vm_command_output()` currently uses `plan.get("source_vms_data", {}).get(vm_name, {})` to determine whether the guest is Windows and to choose Linux vs Windows SSH credentials, which masks missing `source_vms_data`/missing VM entries and can cause incorrect OS detection and misleading downstream failures during post-migration validation. Update the logic to fail fast with a clear exception when required VM metadata is missing, and/or stop using `source_vms_data` as the general source of OS/credential metadata.

## Issue Context
- This code path is used for post-migration validation and should comply with the fail-fast requirement (reject missing/invalid required data early with a clear, specific exception).
- `get_ssh_credentials_from_provider_config()` expects a reliable `source_vm_info["win_os"]` flag.
- `source_vms_data` is not guaranteed to exist for all scenarios/providers and is treated as required only for specific features (e.g., static-IP preservation), so it is not a reliable general source of OS metadata.
- `check_vms()` already has authoritative `source_vm` data available from `source_provider.vm_dict(...)`; prefer passing that into `check_vm_command_output()` (e.g., accept `source_vm_info: dict[str, Any]`) and use it for the Windows guard and credential selection. Optionally keep `source_vms_data` only for data that truly lives there, but do not use it for OS detection.

## Fix Focus Areas
- utilities/post_migration.py[1294-1361]
- utilities/post_migration.py[1320-1333]
- utilities/post_migration.py[1475-1494]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. No retries for SSH cmd 🐞 Bug ☼ Reliability
Description
check_vm_command_output() runs the SSH command exactly once with no retry/backoff, unlike existing
SSH checks in this file, so transient guest readiness/SSH instability post-migration can cause
intermittent false test failures.
Code

utilities/post_migration.py[R1337-1347]

Evidence
The codebase already implements retry/backoff for SSH readiness using TimeoutSampler, but the
newly added helper does not, increasing the chance of timing-based flake failures right after
migration.

utilities/post_migration.py[84-140]
utilities/post_migration.py[1294-1358]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`check_vm_command_output()` executes `executor.run_cmd(command)` once and fails immediately on non-zero rc or missing expected output. Post-migration guests commonly have short windows of instability (services still starting, udev settling, etc.), and this file already uses `TimeoutSampler` retry patterns for SSH connectivity.

### Issue Context
- `check_ssh_connectivity()` uses `TimeoutSampler` to avoid flakiness.
- `check_vm_command_output()` creates a new SSH connection and immediately executes the command without any retry loop.

### Fix Focus Areas
- utilities/post_migration.py[84-140]
- utilities/post_migration.py[1294-1361]

### Suggested fix
- Wrap the command execution + expected-output assertion in a `TimeoutSampler` retry loop (similar to `check_ssh_connectivity()`), e.g.:
 - retry for `wait_timeout=120` with `sleep=10`
 - retry on SSH exceptions and on `rc != 0`
 - (optionally) retry if `expected_output` not found, since filesystems/services may not be ready immediately
- Keep the final error message from the last attempt for debuggability.
- Alternatively, reuse an already-validated SSH session/connection if available to reduce repeated port-forward setup.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Defaults used in prepared_plan.get() 📘 Rule violation ≡ Correctness
Description
The test now reads project-controlled tests_params values via .get() with implicit
defaults/None, which can silently mask missing or misspelled required configuration keys and change
migration behavior without failing fast.
Code

tests/warm/test_warm_migration_comprehensive.py[R189-200]

Evidence
Rule 28 forbids using defaults for project-controlled config keys. The updated test_create_plan
passes multiple values from prepared_plan using .get() (including a default for
preserve_static_ips) which can silently substitute missing keys instead of failing fast.

CLAUDE.md: Configuration We Control Must Not Use Defaults: Access Required Keys Directly; Only Optional Feature Flags May Default
tests/warm/test_warm_migration_comprehensive.py[189-200]
tests/tests_config/config.py[524-575]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prepared_plan` originates from `py_config["tests_params"][...]` (configuration we control). The test uses `.get()` (and `.get(..., default)`) for keys that should be explicitly present, which can hide misconfiguration and let invalid config propagate as `None`/defaults.

## Issue Context
Rule requires required project-controlled config keys to be accessed directly (e.g., `prepared_plan["target_power_state"]`) and forbids silently defaulting missing keys (except for optional feature flags).

## Fix Focus Areas
- tests/warm/test_warm_migration_comprehensive.py[189-200]
- tests/tests_config/config.py[524-575]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

4. Class parametrization shares class state 📘 Rule violation ☼ Reliability ⭐ New
Description
The class-level parametrization adds a second scenario (test_warm_migration_xfs) while the test
class stores migration resources on mutable class attributes, which can leak/overwrite state across
test cases and create order-dependent behavior. This violates the requirement to avoid shared
mutable state between tests.
Code

tests/warm/test_warm_migration_comprehensive.py[R40-43]

Evidence
A second class-level parameter set was added, causing the same test class to run for multiple
configurations. The class still uses mutable class attributes to store resources, which can be
overwritten between parametrized runs and introduces shared mutable state across test cases.

CLAUDE.md: Do Not Share Mutable State Between Tests
tests/warm/test_warm_migration_comprehensive.py[33-46]
tests/warm/test_warm_migration_comprehensive.py[92-201]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`TestWarmMigrationComprehensive` is now parametrized with two plan configurations, but it relies on mutable class attributes (`self.__class__.storage_map`, `network_map`, `plan_resource`) to pass state between tests. This creates cross-test coupling and can cause state from one parametrized run to overwrite/affect another.

## Issue Context
The compliance rule forbids sharing mutable state between tests; resources should be produced/consumed via fixtures (ideally class-scoped) or each test should be fully self-contained.

## Fix Focus Areas
- tests/warm/test_warm_migration_comprehensive.py[33-200]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


5. Wrong exception type used 🐞 Bug ⚙ Maintainability ⭐ New
Description
check_vm_command_output() raises GuestCommandError for SSH command failures, but GuestCommandError
is defined as VMware Guest Operations-specific, making failures misleading and potentially
mis-handled by callers that key off exception type.
Code

utilities/post_migration.py[R1351-1354]

Evidence
The exception class is explicitly documented as VMware Guest Operations-specific, but the new SSH
helper raises it for SSH command failures, creating a semantic mismatch.

exceptions/exceptions.py[122-127]
utilities/post_migration.py[1294-1354]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`utilities/post_migration.py:check_vm_command_output()` raises `GuestCommandError` when an SSH-executed command returns non-zero. However, `GuestCommandError` is defined/documented as applying to VMware Guest Operations failures, so using it for SSH conflates two different execution paths and makes troubleshooting/exception handling confusing.

### Issue Context
- `GuestCommandError` is documented as *VMware Guest Operations* related.
- `check_vm_command_output()` executes commands via SSH (`rrmngmnt` executor), not via Guest Operations.

### Fix Focus Areas
- Define a new exception for SSH/remote command execution (e.g., `SSHCommandError` / `RemoteCommandError`) **or** reuse an existing generic command-exec exception used elsewhere in the repo.
- Update `check_vm_command_output()` to raise the new/generic exception type instead of `GuestCommandError`.
- Ensure any callers/catch blocks (current and future) remain correct.

#### Fix Focus Areas (files/lines)
- exceptions/exceptions.py[122-130]
- utilities/post_migration.py[1294-1366]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


6. Hard-coded XFS device path 🐞 Bug ☼ Reliability
Description
When xfs_compatibility is enabled, check_vms() runs xfs_info against the fixed device /sdb1,
but the plan/test config does not specify which disk/partition is XFS; if the VM’s XFS filesystem is
on a different device name, the post-migration validation will fail even though migration succeeded.
Code

utilities/post_migration.py[R1475-1491]

Evidence
The test config enables xfs_compatibility but does not provide a device identifier; the
post-migration check then hard-codes /sdb1 and any resulting error is turned into a test failure
via the aggregated failed_checks path.

tests/tests_config/config.py[558-575]
utilities/post_migration.py[1475-1494]
utilities/post_migration.py[1592-1595]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The XFS compatibility post-migration check always executes `xfs_info /sdb1`. The VM config/plan does not define an XFS device path, so this check is brittle and can fail for correct migrations when the XFS filesystem is on a different device (e.g., `/dev/sda1`, `/dev/vda2`, `/dev/mapper/...`).

### Issue Context
- The new XFS verification runs inside `check_vms()` only when `plan.get('xfs_compatibility')` is true.
- Any exception is collected into `res[...]` and ultimately causes `pytest.fail(...)`, so a wrong device path makes the whole test fail.

### Fix Focus Areas
- utilities/post_migration.py[1294-1361]
- utilities/post_migration.py[1475-1494]
- tests/tests_config/config.py[558-575]

### Suggested fix
Implement one of the following (prefer dynamic discovery):
1) **Dynamic discovery**: SSH-run a command to find an XFS filesystem device (e.g., `findmnt -nr -t xfs -o SOURCE | head -n1` or `lsblk -nrpo NAME,FSTYPE | awk '$2=="xfs"{print $1; exit}'`) and then run `xfs_info` on that discovered device.
2) **Config-driven**: Add a plan config field like `xfs_device` (or `xfs_mountpoint`) under `test_warm_migration_xfs` and pass it into the verifier instead of hard-coding.
3) **Fallbacks**: Try a small set of common device patterns and fail with a clear error that includes `lsblk` output.

Also update logging/error messages to include the discovered device and full command output on failure.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (2)
7. Hardcoded namespaces in XFS config 📘 Rule violation ☼ Reliability
Description
The new XFS warm-migration test config hardcodes namespace values (vm_target_namespace pattern and
multus_namespace), rather than sourcing namespaces from fixtures, which can undermine parallel
isolation and policy consistency.
Code

tests/tests_config/config.py[R569-571]

Evidence
Rule 33 requires namespace values to be provided by fixtures and not hardcoded. The added
test_warm_migration_xfs configuration includes direct namespace strings (vm_target_namespace and
multus_namespace).

CLAUDE.md: Namespaces Must Be Provided by Fixtures (Never Hardcode)
tests/tests_config/config.py[558-575]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `test_warm_migration_xfs` config sets namespace values directly in config (including a generated string and a fixed `default`). Compliance requires namespaces to be provided by fixtures rather than hardcoded in test logic/config.

## Issue Context
Namespace fixtures typically incorporate session UUID patterns to ensure uniqueness and safe parallel execution.

## Fix Focus Areas
- tests/tests_config/config.py[558-575]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


8. Pod network reorder mismatch 🐞 Bug ≡ Correctness
Description
_reorder_networks_by_pod_network() can only match networks by net['name'], but some inventories
(e.g., OpenShift) return a pod network mapping as {'type': 'pod'} without a name, making it
impossible to select/reorder the pod network via custom_pod_network and leading to
confusing/incorrect behavior when the pod network is not already first.
Code

utilities/utils.py[R305-311]

Evidence
The reorder helper searches for a match only via net.get('name'), while the OpenShift inventory
explicitly produces a pod network mapping that lacks a name key, so that entry can never be
targeted by custom_pod_network matching-by-name.

utilities/utils.py[254-312]
libs/forklift_inventory.py[479-499]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`custom_pod_network` reordering only matches networks by `name`, but OpenShift inventory can emit a pod network entry without a `name` key (`{"type": "pod"}`). This prevents selecting/reordering that pod entry and can cause incorrect mapping when the pod network is not first.

### Issue Context
- `gen_network_map_list()` optionally reorders the inventory network list before mapping index 0 to pod.
- OpenShift inventory network list may include a pod entry represented as `{"type": "pod"}`.

### Fix Focus Areas
- utilities/utils.py[226-312]
- libs/forklift_inventory.py[479-499]

### Suggested fix
- Make `_reorder_networks_by_pod_network()` able to:
 - Prefer `{"type": "pod"}` entry when `custom_pod_network` indicates pod (e.g., allow `custom_pod_network="pod"` or `"__pod__"`), **or**
 - If an entry has `type=="pod"` and no name, allow matching by a synthetic name, **or**
 - Explicitly reject `custom_pod_network` for inventories that include non-name entries with a clear error message explaining what values are valid.
- Update the ValueError message to differentiate unnamed networks (pod) from named ones so users know what they can select.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

9. Docstring exceptions incomplete 🐞 Bug ⚙ Maintainability ⭐ New
Description
check_vm_command_output() documents only ValueError/AssertionError/GuestCommandError, but it also
raises KeyError (missing source_vms_data) and ConnectionError (SSH connection not established), so
the function contract is inaccurate and callers will be misled.
Code

utilities/post_migration.py[R1312-1345]

Evidence
The docstring's Raises section does not include KeyError/ConnectionError, but the function body
raises both under common error paths.

utilities/post_migration.py[1302-1333]
utilities/post_migration.py[1342-1345]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`check_vm_command_output()` raises exceptions that are not listed in its docstring `Raises:` section (notably `KeyError` and `ConnectionError`). This makes the function contract misleading and complicates correct handling/debugging.

### Issue Context
The function explicitly raises:
- `KeyError` when `plan["source_vms_data"][vm_name]` is missing.
- `ConnectionError` when the SSH connection is not established.

### Fix Focus Areas
- Update the docstring `Raises:` section to include all exception types that can be raised.
- If you change the exception type for SSH command failures (see related finding), update the docstring accordingly.

#### Fix Focus Areas (files/lines)
- utilities/post_migration.py[1302-1365]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Previous review results

Review updated until commit 2ddfb0b

Results up to commit 63804a1


🐞 Bugs (2) 📘 Rule violations (2) 📎 Requirement gaps (0)


Action required
1. Defaults used in prepared_plan.get() 📘 Rule violation ≡ Correctness
Description
The test now reads project-controlled tests_params values via .get() with implicit
defaults/None, which can silently mask missing or misspelled required configuration keys and change
migration behavior without failing fast.
Code

tests/warm/test_warm_migration_comprehensive.py[R189-200]

Evidence
Rule 28 forbids using defaults for project-controlled config keys. The updated test_create_plan
passes multiple values from prepared_plan using .get() (including a default for
preserve_static_ips) which can silently substitute missing keys instead of failing fast.

CLAUDE.md: Configuration We Control Must Not Use Defaults: Access Required Keys Directly; Only Optional Feature Flags May Default
tests/warm/test_warm_migration_comprehensive.py[189-200]
tests/tests_config/config.py[524-575]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`prepared_plan` originates from `py_config["tests_params"][...]` (configuration we control). The test uses `.get()` (and `.get(..., default)`) for keys that should be explicitly present, which can hide misconfiguration and let invalid config propagate as `None`/defaults.

## Issue Context
Rule requires required project-controlled config keys to be accessed directly (e.g., `prepared_plan["target_power_state"]`) and forbids silently defaulting missing keys (except for optional feature flags).

## Fix Focus Areas
- tests/warm/test_warm_migration_comprehensive.py[189-200]
- tests/tests_config/config.py[524-575]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended
2. Hard-coded XFS device path 🐞 Bug ☼ Reliability
Description
When xfs_compatibility is enabled, check_vms() runs xfs_info against the fixed device /sdb1,
but the plan/test config does not specify which disk/partition is XFS; if the VM’s XFS filesystem is
on a different device name, the post-migration validation will fail even though migration succeeded.
Code

utilities/post_migration.py[R1475-1491]

Evidence
The test config enables xfs_compatibility but does not provide a device identifier; the
post-migration check then hard-codes /sdb1 and any resulting error is turned into a test failure
via the aggregated failed_checks path.

tests/tests_config/config.py[558-575]
utilities/post_migration.py[1475-1494]
utilities/post_migration.py[1592-1595]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The XFS compatibility post-migration check always executes `xfs_info /sdb1`. The VM config/plan does not define an XFS device path, so this check is brittle and can fail for correct migrations when the XFS filesystem is on a different device (e.g., `/dev/sda1`, `/dev/vda2`, `/dev/mapper/...`).

### Issue Context
- The new XFS verification runs inside `check_vms()` only when `plan.get('xfs_compatibility')` is true.
- Any exception is collected into `res[...]` and ultimately causes `pytest.fail(...)`, so a wrong device path makes the whole test fail.

### Fix Focus Areas
- utilities/post_migration.py[1294-1361]
- utilities/post_migration.py[1475-1494]
- tests/tests_config/config.py[558-575]

### Suggested fix
Implement one of the following (prefer dynamic discovery):
1) **Dynamic discovery**: SSH-run a command to find an XFS filesystem device (e.g., `findmnt -nr -t xfs -o SOURCE | head -n1` or `lsblk -nrpo NAME,FSTYPE | awk '$2=="xfs"{print $1; exit}'`) and then run `xfs_info` on that discovered device.
2) **Config-driven**: Add a plan config field like `xfs_device` (or `xfs_mountpoint`) under `test_warm_migration_xfs` and pass it into the verifier instead of hard-coding.
3) **Fallbacks**: Try a small set of common device patterns and fail with a clear error that includes `lsblk` output.

Also update logging/error messages to include the discovered device and full command output on failure.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Hardcoded namespaces in XFS config 📘 Rule violation ☼ Reliability
Description
The new XFS warm-migration test config hardcodes namespace values (vm_target_namespace pattern and
multus_namespace), rather than sourcing namespaces from fixtures, which can undermine parallel
isolation and policy consistency.
Code

tests/tests_config/config.py[R569-571]

Evidence
Rule 33 requires namespace values to be provided by fixtures and not hardcoded. The added
test_warm_migration_xfs configuration includes direct namespace strings (vm_target_namespace and
multus_namespace).

CLAUDE.md: Namespaces Must Be Provided by Fixtures (Never Hardcode)
tests/tests_config/config.py[558-575]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new `test_warm_migration_xfs` config sets namespace values directly in config (including a generated string and a fixed `default`). Compliance requires namespaces to be provided by fixtures rather than hardcoded in test logic/config.

## Issue Context
Namespace fixtures typically incorporate session UUID patterns to ensure uniqueness and safe parallel execution.

## Fix Focus Areas
- tests/tests_config/config.py[558-575]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Pod network reorder mismatch 🐞 Bug ≡ Correctness
Description
_reorder_networks_by_pod_network() can only match networks by net['name'], but some inventories
(e.g., OpenShift) return a pod network mapping as {'type': 'pod'} without a name, making it
impossible to select/reorder the pod network via custom_pod_network and leading to
confusing/incorrect behavior when the pod network is not already first.
Code

utilities/utils.py[R305-311]

Evidence
The reorder helper searches for a match only via net.get('name'), while the OpenShift inventory
explicitly produces a pod network mapping that lacks a name key, so that entry can never be
targeted by custom_pod_network matching-by-name.

utilities/utils.py[254-312]
libs/forklift_inventory.py[479-499]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`custom_pod_network` reordering only matches networks by `name`, but OpenShift inventory can emit a pod network entry without a `name` key (`{"type": "pod"}`). This prevents selecting/reordering that pod entry and can cause incorrect mapping when the pod network is not first.

### Issue Context
- `gen_network_map_list()` optionally reorders the inventory network list before mapping index 0 to pod.
- OpenShift inventory network list may include a pod entry represented as `{"type": "pod"}`.

### Fix Focus Areas
- utilities/utils.py[226-312]
- libs/forklift_inventory.py[479-499]

### Suggested fix
- Make `_reorder_networks_by_pod_network()` able to:
 - Prefer `{"type": "pod"}` entry when `custom_pod_network` indicates pod (e.g., allow `custom_pod_network="pod"` or `"__pod__"`), **or**
 - If an entry has `type=="pod"` and no name, allow matching by a synthetic name, **or**
 - Explicitly reject `custom_pod_network` for inventories that include non-name entries with a clear error message explaining what values are valid.
- Update the ValueError message to differentiate unnamed networks (pod) from named ones so users know what they can select.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Results up to commit 63804a1


🐞 Bugs (1) 📘 Rule violations (1) 📎 Requirement gaps (0)


Action required
1. source_vms_data defaulted to {} 📘 Rule violation ☼ Reliability
Description
check_vm_command_output() silently defaults missing plan["source_vms_data"][vm_name] to {},
even though it uses that data to infer Windows-vs-Linux and select SSH credentials, which can
mis-detect guest OS (e.g., treat Windows as Linux) and fail later for misleading reasons. This
violates the intended fail-fast behavior and can cause confusing downstream post-migration
validation failures.
Code

utilities/post_migration.py[R1320-1333]

Evidence
PR Compliance ID 9 requires rejecting invalid or missing required data early with a clear exception,
but the implementation uses plan.get("source_vms_data", {}).get(vm_name, {}), allowing absent
source_vms_data or missing VM entries to propagate into OS detection and credential selection
without an explicit failure. Because credential selection is driven by the win_os flag taken from
this optional/feature-specific structure (treated elsewhere as required only for specific features
like static-IP preservation), missing data can cause Windows guests to be treated as Linux and lead
to check failures for the wrong reason rather than a clear, immediate error at the point of use.

CLAUDE.md: Fail Fast: Do Not Allow Invalid None Values to Propagate
utilities/post_migration.py[1320-1333]
utilities/post_migration.py[39-81]
utilities/post_migration.py[1294-1336]
utilities/post_migration.py[1444-1454]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`check_vm_command_output()` currently uses `plan.get("source_vms_data", {}).get(vm_name, {})` to determine whether the guest is Windows and to choose Linux vs Windows SSH credentials, which masks missing `source_vms_data`/missing VM entries and can cause incorrect OS detection and misleading downstream failures during post-migration validation. Update the logic to fail fast with a clear exception when required VM metadata is missing, and/or stop using `source_vms_data` as the general source of OS/credential metadata.

## Issue Context
- This code path is used for post-migration validation and should comply with the fail-fast requirement (reject missing/invalid required data early with a clear, specific exception).
- `get_ssh_credentials_from_provider_config()` expects a reliable `source_vm_info["win_os"]` flag.
- `source_vms_data` is not guaranteed to exist for all scenarios/providers and is treated as required only for specific features (e.g., static-IP preservation), so it is not a reliable general source of OS metadata.
- `check_vms()` already has authoritative `source_vm` data available from `source_provider.vm_dict(...)`; prefer passing that into `check_vm_command_output()` (e.g., accept `source_vm_info: dict[str, Any]`) and use it for the Windows guard and credential selection. Optionally keep `source_vms_data` only for data that truly lives there, but do not use it for OS detection.

## Fix Focus Areas
- utilities/post_migration.py[1294-1361]
- utilities/post_migration.py[1320-1333]
- utilities/post_migration.py[1475-1494]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. No retries for SSH cmd 🐞 Bug ☼ Reliability
Description
check_vm_command_output() runs the SSH command exactly once with no retry/backoff, unlike existing
SSH checks in this file, so transient guest readiness/SSH instability post-migration can cause
intermittent false test failures.
Code

utilities/post_migration.py[R1337-1347]

Evidence
The codebase already implements retry/backoff for SSH readiness using TimeoutSampler, but the
newly added helper does not, increasing the chance of timing-based flake failures right after
migration.

utilities/post_migration.py[84-140]
utilities/post_migration.py[1294-1358]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`check_vm_command_output()` executes `executor.run_cmd(command)` once and fails immediately on non-zero rc or missing expected output. Post-migration guests commonly have short windows of instability (services still starting, udev settling, etc.), and this file already uses `TimeoutSampler` retry patterns for SSH connectivity.

### Issue Context
- `check_ssh_connectivity()` uses `TimeoutSampler` to avoid flakiness.
- `check_vm_command_output()` creates a new SSH connection and immediately executes the command without any retry loop.

### Fix Focus Areas
- utilities/post_migration.py[84-140]
- utilities/post_migration.py[1294-1361]

### Suggested fix
- Wrap the command execution + expected-output assertion in a `TimeoutSampler` retry loop (similar to `check_ssh_connectivity()`), e.g.:
 - retry for `wait_timeout=120` with `sleep=10`
 - retry on SSH exceptions and on `rc != 0`
 - (optionally) retry if `expected_output` not found, since filesystems/services may not be ready immediately
- Keep the final error message from the last attempt for debuggability.
- Alternatively, reuse an already-validated SSH session/connection if available to reduce repeated port-forward setup.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Qodo Logo

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@utilities/post_migration.py`:
- Around line 1321-1333: The code is silently defaulting source_vm_data to {}
and assuming ssh_conn.rrmngmnt_host exists which leads to opaque failures;
update the logic around source_vm_data,
get_ssh_credentials_from_provider_config, and ssh_conn usage to fail fast:
explicitly check if plan.get("source_vms_data") is None or if source_vm_data is
missing for vm_name and raise a clear ValueError naming vm_name and plan key,
validate that get_ssh_credentials_from_provider_config returned non-None
ssh_username/ssh_password and raise a descriptive error if missing, and before
using ssh_conn.rrmngmnt_host validate ssh_conn is not None and that
ssh_conn.rrmngmnt_host is present (raise a clear exception referencing
destination_vm_name and ssh_conn) so callers get actionable setup errors instead
of opaque attribute errors.

In `@utilities/vmware_guest_operations.py`:
- Around line 222-224: The awk program is written with double braces so it’s
passed literally and returns empty values; update the shell command strings that
set dev and method (the lines constructing "dev=$(nmcli -f GENERAL.DEVICES ... |
awk -F: '{{print $2}}' ..." and "method=$(nmcli -f ipv4.method ... | awk -F:
'{{print $2}}' ...)") to use single-brace awk syntax ({print $2}) so dev and
method are extracted correctly; ensure both occurrences are fixed and keep the
surrounding nmcli/test/xargs pipeline intact.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 193fb40a-71bf-4373-b22a-67de42ab42f0

📥 Commits

Reviewing files that changed from the base of the PR and between 9c5c0b4 and 63804a1.

📒 Files selected for processing (6)
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_comprehensive.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/utils.py
  • utilities/vmware_guest_operations.py

Comment thread utilities/post_migration.py Outdated
Comment thread utilities/vmware_guest_operations.py Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 4

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/cold/test_cold_migration_xfs.py`:
- Around line 162-164: The cold migration test is directly indexing optional
plan flags, which can raise a KeyError when they are omitted. Update the
argument setup in the test that uses prepared_plan so warm_migration and
xfs_compatibility are read with prepared_plan.get(..., False), while keeping
preserve_static_ips as a required direct access. Use the existing prepared_plan
usage in the migration test to locate the change.

In `@tests/tests_config/config.py`:
- Around line 720-724: The warm XFS migration test is reading the wrong config
key, causing a KeyError before the check runs. Update the test logic in
test_warm_migration_xfs to use the existing xfs_check configuration key that
matches the dict in config.py, and make sure the xfs_info validation compares
against the configured expected_output value instead of xfs_v4.

In `@tests/warm/test_warm_migration_xfs.py`:
- Around line 165-166: The test is reading optional plan flags with direct
subscripts, which makes it fragile if those keys are missing. Update the
`create_plan_resource` call in `test_warm_migration_xfs` to fetch
`warm_migration` and `xfs_compatibility` via `prepared_plan.get(..., False)`
instead of indexing into `prepared_plan`, keeping the test aligned with the
default behavior in `create_plan_resource`.
- Around line 208-222: The XFS warm migration test is reading the wrong config
key in `test_warm_migration_xfs` when building the `check_vm_command_output`
call. Update the `xfs_check` usage in this test to match the config schema used
by the XFS test definitions, and reference the documented `expected_output`
field instead of `xfs_v4`. Keep the existing `xfs_check`,
`check_vm_command_output`, and `prepared_plan` flow intact while correcting the
key access.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: b8f30914-5a86-4fbb-826f-6482e9a46e36

📥 Commits

Reviewing files that changed from the base of the PR and between 11c2f5e and f603e81.

📒 Files selected for processing (8)
  • AGENTS.md
  • tests/cold/test_cold_migration_xfs.py
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_xfs.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/shared_disk.py
  • utilities/ssh_utils.py

Comment thread tests/cold/test_cold_migration_xfs.py Outdated
Comment thread tests/tests_config/config.py
Comment thread tests/warm/test_warm_migration_xfs.py Outdated
Comment thread tests/warm/test_warm_migration_xfs.py

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@tests/tests_config/config.py`:
- Around line 737-741: The xfs_check configuration uses an invalid mount_point
value, causing xfs_info to receive a non-existent path. Update the xfs_check
entry in config.py so mount_point points to the correct device node or mounted
directory, using the xfs_check symbol to locate the setting and replacing /sdb1
with a valid /dev/... path such as /dev/sdb1.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 80135ece-d7c4-4920-9ee4-c8af41b36e60

📥 Commits

Reviewing files that changed from the base of the PR and between f603e81 and d00263f.

📒 Files selected for processing (8)
  • AGENTS.md
  • tests/cold/test_cold_migration_xfs.py
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_xfs.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/shared_disk.py
  • utilities/ssh_utils.py

Comment thread tests/tests_config/config.py
coderabbitai[bot]
coderabbitai Bot previously approved these changes Jun 25, 2026
@Chenli-Hu

Copy link
Copy Markdown
Contributor Author

/verified

@Chenli-Hu

Copy link
Copy Markdown
Contributor Author

Tested the latest code changes with both XFS and shared disk scenarios:

uv run pytest -vv -m "tier1" -k "xfs" => PASSED

uv run pytest -vv -m "shared_disk" -k "shared-disk-rhel" => PASSED

============================= test session starts ==============================
platform linux -- Python 3.13.2, pytest-9.1.1, pluggy-1.6.0 -- /home/test/mtv-api-tests/.venv/bin/python
cachedir: .pytest_cache
rootdir: /home/test/mtv-api-tests
configfile: pytest.ini
testpaths: tests
plugins: anyio-4.14.0, harvest-1.10.5, jira-0.3.24, profiling-1.8.1, progress-1.4.0, testconfig-0.2.0, xdist-3.8.0
collecting ... collected 266 items / 260 deselected / 6 selected

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_create_storagemap[shared-disk-rhel] PASSED
_ 1 of 6 completed, 1 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_create_networkmap[shared-disk-rhel] PASSED
_ 2 of 6 completed, 2 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_create_plan[shared-disk-rhel] PASSED
_ 3 of 6 completed, 3 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_migrate_vms[shared-disk-rhel] PASSED
_ 4 of 6 completed, 4 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_verify_shared_disk_data[shared-disk-rhel] PASSED
_ 5 of 6 completed, 5 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _

tests/shared_disk/test_shared_disk_rhel_migration.py::TestSharedDiskRhelMigration::test_check_vms[shared-disk-rhel] PASSED
_ 6 of 6 completed, 6 Pass, 0 Fail, 0 Skip, 0 XPass, 0 XFail, 0 Error, 0 ReRun _
======== 6 passed, 260 deselected, 1929 warnings in 1101.03s (0:18:21) =========

@myakove myakove left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Found 3 issue(s) in this PR:

💡 Suggestions (3)

File Line Issue
tests/cold/test_cold_migration_xfs.py 163 target_power_state configured but not passed to create_plan_resource()
utilities/post_migration.py 31 Unused runtime import: GuestCommandError
utilities/ssh_utils.py 45 Docstring Raises section omits ConnectionError

Review generated by pi

Comment thread tests/cold/test_cold_migration_xfs.py
Comment thread utilities/post_migration.py Outdated
Comment thread utilities/ssh_utils.py
coderabbitai[bot]
coderabbitai Bot previously approved these changes Jun 25, 2026
@Chenli-Hu

Copy link
Copy Markdown
Contributor Author

/verified

@myakove myakove left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Found 2 issue(s) in this PR:

💡 Suggestions (2)

File Line Issue
AGENTS.md 812 Test method naming paragraph missing XFS pattern
AGENTS.md 953 README marker table missing vsphere

Review generated by pi

Comment thread AGENTS.md
Comment thread AGENTS.md

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@AGENTS.md`:
- Around line 861-868: Update the Test Verification Configuration docs so the
xfs_check section reflects that xfs_check itself is optional, but command,
mount_point, and expected_output are required whenever xfs_check is present. Use
the test_verify_xfs_version behavior and the xfs_check keys as the guide, and
rewrite the table wording to make these fields conditionally required instead of
fully optional.

In `@tests/cold/test_cold_migration_xfs.py`:
- Around line 153-165: Restore the missing preserve_static_ips argument when
calling create_plan_resource() in the cold migration XFS test setup. The Plan CR
builder still accepts this field and the scenario depends on it, so pass
prepared_plan["preserve_static_ips"] alongside the existing parameters to keep
networking behavior aligned with the test case and preserve the later
SSH/check_vms validation flow.

In `@tests/warm/test_warm_migration_xfs.py`:
- Around line 57-58: The new dict[str, Any] annotations in the warm migration
test need an explicit justification or narrower types. Update the first relevant
declaration in test_warm_migration_xfs.py, near the prepared_plan and
fixture_store parameters, to add a short inline or nearby comment explaining
that these test payloads are intentionally schema-flexible and
scenario-dependent; if the structure is fixed, replace Any with a concrete
mapping type instead. Keep the explanation close to the first occurrence so
later dict[str, Any] usages are clearly intentional.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d347aca1-a8bd-4b16-b3c4-d8833b95654a

📥 Commits

Reviewing files that changed from the base of the PR and between 161835e and 842b6a7.

📒 Files selected for processing (9)
  • AGENTS.md
  • README.md
  • tests/cold/test_cold_migration_xfs.py
  • tests/tests_config/config.py
  • tests/warm/test_warm_migration_xfs.py
  • utilities/mtv_migration.py
  • utilities/post_migration.py
  • utilities/shared_disk.py
  • utilities/ssh_utils.py

Comment thread AGENTS.md Outdated
Comment thread tests/cold/test_cold_migration_xfs.py
Comment thread tests/warm/test_warm_migration_xfs.py Outdated
Signed-off-by: Chenli Hu <chhu@redhat.com>
@Chenli-Hu

Copy link
Copy Markdown
Contributor Author

/verified

@myakove myakove left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

Found 1 issue(s) in this PR:

💡 Suggestions (1)

File Line Issue
utilities/ssh_utils.py 48 [SUGGESTION] run_cmd_in_vm validates rrmngmnt_host but not `rrmngmnt_use

Review generated by pi

Comment thread utilities/ssh_utils.py
ConnectionError: If SSH connection is not established.
GuestCommandError: If the command fails (non-zero return code).
"""
if ssh_conn.rrmngmnt_host is None:

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[SUGGESTION] run_cmd_in_vm validates rrmngmnt_host but not rrmngmnt_user or local_port.

This function was promoted from private (_run_cmd_on_vm) to public. It validates rrmngmnt_host is None but doesn't check rrmngmnt_user or local_port. If connection state is inconsistent:

  • executor(user=None) uses rrmngmnt's default user (wrong auth)
  • executor.port = None could fall back to port 22 on localhost — executing on the host instead of the VM

Fix: Extend guard:

if ssh_conn.rrmngmnt_host is None or ssh_conn.rrmngmnt_user is None or ssh_conn.local_port is None:
    raise ConnectionError(f"{description}: SSH connection is not fully established")

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants