MTV 2.12.0 release notes draft - #934
Open
anarnold97 wants to merge 3 commits into
Open
Conversation
Signed-off-by: A.Arnold <anarnold@redhat.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Warning Review limit reached
More reviews will be available in 5 minutes and 53 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR updates Forklift documentation from release 2.11 to 2.12 by advancing version attributes, creating new 2.12 release-notes modules with technical changes, features, known issues, and resolved issues, and rewriting the master assembly to include the 2.12 content. ChangesVersion 2.12 Release Notes Documentation
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (2)
documentation/modules/ref_technical-changes-2-12.adoc (1)
12-12: ⚡ Quick winTechnical changes content is not yet documented.
This module currently serves as a structural placeholder with only header and abstract. Since this is a draft release notes PR, this may be intentional, but verify that technical changes content will be added before the final 2.12 release.
🤖 Prompt for 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. In `@documentation/modules/ref_technical-changes-2-12.adoc` at line 12, The module "Technical changes" placeholder currently contains only a header and abstract; replace the stub by adding the actual technical changes content for the 2.12 release: populate the abstract with a short summary, add a detailed section listing each technical change (feature, bugfix, breaking change) as bullets with concise descriptions, link to relevant PRs/issue IDs and author names, and ensure the section "Technical changes" is reviewed and completed before finalizing the 2.12 release notes (update the ref_technical-changes-2-12.adoc header/abstract and add the new content under the "Technical changes" section).documentation/modules/ref_known-issues-2-12.adoc (1)
12-13: ⚡ Quick winClarify the title to reflect that this is a known limitation.
The title "Virtual machine migrations with XFS v4 file systems no longer fail unexpectedly during conversion" sounds like a resolved issue rather than a known limitation. The description clarifies that MTV now prevents these migrations rather than fixing them, making this a configuration restriction. Consider rewording the title to something like "XFS v4 migrations with virt_v2v_memsize or virt_v2v_smp parameters are not supported" to better reflect that this is a known limitation rather than a fix.
🤖 Prompt for 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. In `@documentation/modules/ref_known-issues-2-12.adoc` around lines 12 - 13, The current title misrepresents the behavior as a fix rather than a known limitation—update the heading text to make it explicit this is a restriction (for example: "XFS v4 migrations with virt_v2v_memsize or virt_v2v_smp parameters are not supported"); keep the body as-is but ensure it references the configuration keys xfsCompatibility, virt_v2v_memsize, and virt_v2v_smp and the product token {project-short}; change only the title line (the one starting "Virtual machine migrations with XFS v4 file systems no longer fail unexpectedly during conversion") so it clearly states this is unsupported/forbidden rather than resolved.
🤖 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 `@documentation/modules/common-attributes.adoc`:
- Line 26: The docs reference a non-existent MTV 2.12.0 tag and CSVs: update or
gate publication so we don't publish docs unless the artifacts exist by (1)
checking the tag referenced by :project-z-version in
documentation/modules/common-attributes.adoc actually exists in the Red Hat
catalog, and (2) verifying the CSV names interpolated in
documentation/modules/proc_installing-mtv-operator.adoc (the startingCSV values
`"{namespace}-operator.{project-z-version}"` and
`"mtv-operator.v{project-z-version}"`) match real catalog entries; if the
tag/CSVs are missing, either bump :project-z-version to a published release or
add a pre-publish validation that aborts docs publish until the image/CSV
artifacts are present.
- Around line 13-14: The OCP link generation is broken because :ocp-version:
4.22 is being interpolated into a docs URL that expects the version directory
(and not the html-single path) and the MTV 2.12 compatibility claim lacks a
citation; update the AsciiDoc variables so the generated ocp-doc URL points to
the real docs root (e.g., use the /openshift_container_platform/4.22/ root or
remove the /html-single suffix when building ocp-doc) by adjusting the :ocp-doc:
construction tied to :ocp-version: (reference the :ocp-version: variable and
wherever ocp-doc is assembled), and either add an authoritative
citation/evidence for MTV 2.12 compatibility with OCP 4.22 in the text or revert
the version bump to 2.11 until a source is provided.
In `@documentation/modules/ref_resolved-issues-2-12-0.adoc`:
- Around line 12-15: The AsciiDoc paragraph describing RDM disks contains stray
citation markers "[1, 2]" that will render literally; remove all occurrences of
"[1, 2]" from the text that mentions spec.rdmAsLun=true, MigrationPlan, RDM,
LUN, and SCSI so the sentence reads naturally (e.g., "With this release, the
interface type conversion for RDM disks in a MigrationPlan is corrected." and
"As a result, RDM disks converted to a LUN have the required SCSI interface
type.") and keep the existing link to MTV-5610 unchanged.
---
Nitpick comments:
In `@documentation/modules/ref_known-issues-2-12.adoc`:
- Around line 12-13: The current title misrepresents the behavior as a fix
rather than a known limitation—update the heading text to make it explicit this
is a restriction (for example: "XFS v4 migrations with virt_v2v_memsize or
virt_v2v_smp parameters are not supported"); keep the body as-is but ensure it
references the configuration keys xfsCompatibility, virt_v2v_memsize, and
virt_v2v_smp and the product token {project-short}; change only the title line
(the one starting "Virtual machine migrations with XFS v4 file systems no longer
fail unexpectedly during conversion") so it clearly states this is
unsupported/forbidden rather than resolved.
In `@documentation/modules/ref_technical-changes-2-12.adoc`:
- Line 12: The module "Technical changes" placeholder currently contains only a
header and abstract; replace the stub by adding the actual technical changes
content for the 2.12 release: populate the abstract with a short summary, add a
detailed section listing each technical change (feature, bugfix, breaking
change) as bullets with concise descriptions, link to relevant PRs/issue IDs and
author names, and ensure the section "Technical changes" is reviewed and
completed before finalizing the 2.12 release notes (update the
ref_technical-changes-2-12.adoc header/abstract and add the new content under
the "Technical changes" section).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: ec55595d-5025-4275-baca-07e0ed36cf8a
📒 Files selected for processing (17)
documentation/doc-Release_notes/master.adocdocumentation/modules/common-attributes.adocdocumentation/modules/ref_known-issues-2-11.adocdocumentation/modules/ref_known-issues-2-12.adocdocumentation/modules/ref_new-features-and-enhancements-2-11.adocdocumentation/modules/ref_new-features-and-enhancements-2-12.adocdocumentation/modules/ref_resolved-issues-2-11-0.adocdocumentation/modules/ref_resolved-issues-2-11-1.adocdocumentation/modules/ref_resolved-issues-2-11-3.adocdocumentation/modules/ref_resolved-issues-2-11-4.adocdocumentation/modules/ref_resolved-issues-2-11-5.adocdocumentation/modules/ref_resolved-issues-2-11-6.adocdocumentation/modules/ref_resolved-issues-2-11-7.adocdocumentation/modules/ref_resolved-issues-2-12-0.adocdocumentation/modules/ref_rn-2-12.adocdocumentation/modules/ref_technical-changes-2-11.adocdocumentation/modules/ref_technical-changes-2-12.adoc
💤 Files with no reviewable changes (10)
- documentation/modules/ref_resolved-issues-2-11-0.adoc
- documentation/modules/ref_resolved-issues-2-11-1.adoc
- documentation/modules/ref_technical-changes-2-11.adoc
- documentation/modules/ref_resolved-issues-2-11-5.adoc
- documentation/modules/ref_resolved-issues-2-11-4.adoc
- documentation/modules/ref_resolved-issues-2-11-6.adoc
- documentation/modules/ref_new-features-and-enhancements-2-11.adoc
- documentation/modules/ref_resolved-issues-2-11-3.adoc
- documentation/modules/ref_known-issues-2-11.adoc
- documentation/modules/ref_resolved-issues-2-11-7.adoc
Comment on lines
+13
to
+14
| :ocp-version: 4.22 | ||
| :ocp-y-version: 4.22, 4.21, 4.20, 4.19 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check if OpenShift 4.22 documentation exists
echo "Checking OpenShift 4.22 documentation availability..."
curl -s -o /dev/null -w "%{http_code}" "https://docs.redhat.com/en/documentation/openshift_container_platform/4.22/"Repository: kubev2v/forklift-documentation
Length of output: 131
🌐 Web query:
OpenShift Container Platform 4.22 release date and MTV 2.12 compatibility
💡 Result:
OpenShift Container Platform (OCP) 4.22 release date and MTV 2.12 compatibility (as of 2026-06-05) 1) OCP 4.22 release date I could not find an authoritative “GA release date” (a specific calendar date for the first public stable release) for OCP 4.22 from the sources retrieved. What I can source is that 4.22 build tags progressed through RC/EC phases in 2026: - Release 4.22.0-rc.2 was created on 2026-04-30 13:56:48 UTC [1]. - Release 4.22.0-rc.4 was created on 2026-05-18 11:17:21 UTC [2]. - Release 4.22.0-rc.5 was created on 2026-05-27 15:50:26 UTC [3]. - Release 4.22.0-ec.0 was created on 2026-01-12 16:45:09 UTC [4]. If you want, tell me whether you need the “first available stable (4.22.0) GA date” for customers or the “stable stream promotion date,” and I’ll do one more targeted lookup for that exact GA date. 2) MTV 2.12 compatibility with OCP 4.22 I did not find a Red Hat Migration Toolkit for Virtualization (MTV) 2.12 compatibility table specifically naming OCP 4.22 in the sources retrieved. The only compatibility guidance I found is for MTV 2.11, which states that live migration requires MTV 2.10 or later and OpenShift Virtualization 4.20 or later (not OCP 4.22) [5][6]. Practical takeaway from the available sources: MTV compatibility is documented in “software compatibility guidelines” by MTV version, and you should use the MTV version’s specific table for the exact OCP version support matrix; with the sources retrieved, I cannot confirm the “MTV 2.12 works with OCP 4.22” claim. Sources used: [1] Created timestamp for 4.22.0-rc.2 [4] Created timestamp for 4.22.0-ec.0 [3] Created timestamp for 4.22.0-rc.5 [2] Created timestamp for 4.22.0-rc.4 [5] MTV 2.11 migration planning (live migration requires MTV 2.10+ and OCP Virtualization 4.20+) [6] MTV 2.11 live migration chapter (same requirement)
Citations:
- 1: https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasetag/4.22.0-rc.2?from=4.21.13
- 2: https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasetag/4.22.0-rc.4?from=4.22.0-ec.1
- 3: https://openshift-release.apps.ci.l2s4.p1.openshiftapps.com/releasetag/4.22.0-rc.5?from=4.22.0-rc.2
- 4: https://amd64.ocp.releases.ci.openshift.org/releasetag/4.22.0-ec.0
- 5: https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.11/html-single/planning_your_migration_to_red_hat_openshift_virtualization/index
- 6: https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.11/html/planning_your_migration_to_red_hat_openshift_virtualization/assembly_live-migration_mtv
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="documentation/modules/common-attributes.adoc"
echo "== $FILE =="
nl -ba "$FILE" | sed -n '1,120p'Repository: kubev2v/forklift-documentation
Length of output: 186
🏁 Script executed:
#!/bin/bash
set -euo pipefail
FILE="documentation/modules/common-attributes.adoc"
echo "== $FILE (lines 1-80) =="
cat -n "$FILE" | sed -n '1,80p'Repository: kubev2v/forklift-documentation
Length of output: 3415
Fix broken OpenShift 4.22 documentation links (and add MTV 2.12 compatibility evidence)
documentation/modules/common-attributes.adocsets:ocp-version: 4.22and builds:ocp-docashttps://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html-single; the current OCP 4.22 docs root at.../openshift_container_platform/4.22/returns 404, so the generated links are likely to break.- No authoritative source was found for MTV 2.12 compatibility specifically with OCP 4.22 (only MTV 2.11 guidance was located), so the 2.12/4.22 compatibility basis needs a citation or the version bump should be deferred.
🤖 Prompt for 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.
In `@documentation/modules/common-attributes.adoc` around lines 13 - 14, The OCP
link generation is broken because :ocp-version: 4.22 is being interpolated into
a docs URL that expects the version directory (and not the html-single path) and
the MTV 2.12 compatibility claim lacks a citation; update the AsciiDoc variables
so the generated ocp-doc URL points to the real docs root (e.g., use the
/openshift_container_platform/4.22/ root or remove the /html-single suffix when
building ocp-doc) by adjusting the :ocp-doc: construction tied to :ocp-version:
(reference the :ocp-version: variable and wherever ocp-doc is assembled), and
either add an authoritative citation/evidence for MTV 2.12 compatibility with
OCP 4.22 in the text or revert the version bump to 2.11 until a source is
provided.
| :mtv-plan: https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{project-version}/html/planning_your_migration_to_red_hat_openshift_virtualization/ | ||
| :mtv-mig: https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/{project-version}/html/migrating_your_virtual_machines_to_red_hat_openshift_virtualization/ | ||
| :project-z-version: 2.11.7 | ||
| :project-z-version: 2.12.0 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for MTV operator v2.12.0 in the catalog
echo "Checking MTV operator availability..."
# Use oc or podman to check if the operator version exists
# Note: This requires authenticated access to Red Hat registries
# Check if the must-gather container image exists
echo "Checking must-gather container image..."
podman search registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8 --limit 5 || echo "Image search requires authentication"
# Alternative: Check the Red Hat Catalog API
curl -s "https://catalog.redhat.com/api/containers/v1/repositories/registry/registry.redhat.io/repository/migration-toolkit-virtualization/mtv-must-gather-rhel8/tag/2.12.0" | jq -r '.data[0].name // "Not found"'Repository: kubev2v/forklift-documentation
Length of output: 262
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Repo usage of :project-z-version: =="
rg -n ":project-z-version" -S documentation/modules || true
echo
echo "== StartingCSV usage =="
rg -n "startingCSV" -S documentation/modules || true
echo
echo "== Image tag usage (mtv-must-gather-rhel8) =="
rg -n "mtv-must-gather-rhel8.*\\{project-z-version\\}|mtv-must-gather-rhel8.*2\\." -S documentation/modules || true
echo
echo "== Inspect snippet around common-attributes.adoc line 26 =="
sed -n '1,80p' documentation/modules/common-attributes.adoc | nl -ba | sed -n '1,80p' || true
echo
echo "== Inspect other doc for operator CSV template =="
# show small window around likely doc usage
rg -n "mtv-operator\\.v\\{project-z-version\\}" -S documentation/modules || true
echo
# Robust check of Red Hat catalog endpoint used earlier
VER="2.12.0"
URL="https://catalog.redhat.com/api/containers/v1/repositories/registry/registry.redhat.io/repository/migration-toolkit-virtualization/mtv-must-gather-rhel8/tag/${VER}"
echo "== Curl check for must-gather tag $VER =="
# capture HTTP status and first bytes
http_status="$(curl -sS -o /tmp/redhat_catalog_resp.json -w "%{http_code}" "$URL" || true)"
echo "HTTP status: $http_status"
echo "Response bytes: $(wc -c < /tmp/redhat_catalog_resp.json 2>/dev/null || echo 0)"
echo "Response head:"
head -c 1000 /tmp/redhat_catalog_resp.json 2>/dev/null || true
echo
echo "Parsed output:"
python3 - <<'PY'
import json,sys,os
p="/tmp/redhat_catalog_resp.json"
try:
data=open(p,'rb').read()
if not data:
print("EMPTY")
raise SystemExit
j=json.loads(data)
# best effort extraction
out=None
# old attempt looked at .data[0].name
if isinstance(j,dict) and "data" in j and isinstance(j["data"],list) and j["data"]:
out=j["data"][0].get("name") or "Not found"
else:
out="Not found (unexpected shape)"
print(out)
except Exception as e:
print("Parse error:",e)
PY
echo
# Try an alternate endpoint: tags listing to confirm repository visibility
echo "== Curl check for repository tags listing (limited) =="
URL2="https://catalog.redhat.com/api/containers/v1/repositories/registry/registry.redhat.io/repository/migration-toolkit-virtualization/mtv-must-gather-rhel8/tags?limit=50"
http_status2="$(curl -sS -o /tmp/redhat_catalog_tags.json -w "%{http_code}" "$URL2" || true)"
echo "HTTP status: $http_status2"
echo "Response bytes: $(wc -c < /tmp/redhat_catalog_tags.json 2>/dev/null || echo 0)"
echo "Response head:"
head -c 1000 /tmp/redhat_catalog_tags.json 2>/dev/null || true
echo
python3 - <<'PY'
import json
p="/tmp/redhat_catalog_tags.json"
try:
j=json.load(open(p))
tags=[]
# attempt to find keys containing "data"
if isinstance(j,dict):
data=j.get("data")
if isinstance(data,list):
# each item might have name or id
for it in data:
if isinstance(it,dict):
tags.append(it.get("name") or it.get("version") or it.get("tag") or it.get("digest"))
print("Extracted tag entries (sample up to 20):", tags[:20])
print("Contains 2.12.0:", "2.12.0" in str(tags))
except Exception as e:
print("Parse error:",e)
PYRepository: kubev2v/forklift-documentation
Length of output: 1467
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Repo usage of :project-z-version: =="
rg -n ":project-z-version" -S documentation/modules || true
echo
echo "== StartingCSV usage =="
rg -n "startingCSV" -S documentation/modules || true
echo
echo "== Image tag usage (mtv-must-gather-rhel8) =="
rg -n "mtv-must-gather-rhel8.*\\{project-z-version\\}|mtv-must-gather-rhel8.*2\\." -S documentation/modules || true
echo
echo "== Inspect snippet around common-attributes.adoc line 26 =="
sed -n '1,80p' documentation/modules/common-attributes.adoc | nl -ba | sed -n '1,80p' || true
echo
echo "== Inspect other doc for operator CSV template =="
rg -n "mtv-operator\\.v\\{project-z-version\\}" -S documentation/modules || true
echo
# Robust check of Red Hat catalog endpoint used earlier
VER="2.12.0"
URL="https://catalog.redhat.com/api/containers/v1/repositories/registry/registry.redhat.io/repository/migration-toolkit-virtualization/mtv-must-gather-rhel8/tag/${VER}"
echo "== Curl check for must-gather tag $VER =="
# capture HTTP status and first bytes
http_status="$(curl -sS -o /tmp/redhat_catalog_resp.json -w "%{http_code}" "$URL" || true)"
echo "HTTP status: $http_status"
echo "Response bytes: $(wc -c < /tmp/redhat_catalog_resp.json 2>/dev/null || echo 0)"
echo "Response head:"
head -c 1000 /tmp/redhat_catalog_resp.json 2>/dev/null || true
echo
echo "Parsed output:"
python3 - <<'PY'
import json,sys,os
p="/tmp/redhat_catalog_resp.json"
try:
data=open(p,'rb').read()
if not data:
print("EMPTY")
raise SystemExit
j=json.loads(data)
# best effort extraction
out=None
# old attempt looked at .data[0].name
if isinstance(j,dict) and "data" in j and isinstance(j["data"],list) and j["data"]:
out=j["data"][0].get("name") or "Not found"
else:
out="Not found (unexpected shape)"
print(out)
except Exception as e:
print("Parse error:",e)
PY
echo
# Try an alternate endpoint: tags listing to confirm repository visibility
echo "== Curl check for repository tags listing (limited) =="
URL2="https://catalog.redhat.com/api/containers/v1/repositories/registry/registry.redhat.io/repository/migration-toolkit-virtualization/mtv-must-gather-rhel8/tags?limit=50"
http_status2="$(curl -sS -o /tmp/redhat_catalog_tags.json -w "%{http_code}" "$URL2" || true)"
echo "HTTP status: $http_status2"
echo "Response bytes: $(wc -c < /tmp/redhat_catalog_tags.json 2>/dev/null || echo 0)"
echo "Response head:"
head -c 1000 /tmp/redhat_catalog_tags.json 2>/dev/null || true
echo
python3 - <<'PY'
import json
p="/tmp/redhat_catalog_tags.json"
try:
j=json.load(open(p))
tags=[]
# attempt to find keys containing "data"
if isinstance(j,dict):
data=j.get("data")
if isinstance(data,list):
# each item might have name or id
for it in data:
if isinstance(it,dict):
tags.append(it.get("name") or it.get("version") or it.get("tag") or it.get("digest"))
print("Extracted tag entries (sample up to 20):", tags[:20])
print("Contains 2.12.0:", "2.12.0" in str(tags))
except Exception as e:
print("Parse error:",e)
PYRepository: kubev2v/forklift-documentation
Length of output: 1467
Fix: Don’t publish docs unless MTV 2.12.0 image/CSV artifacts exist
- documentation/modules/common-attributes.adoc:29 interpolates
registry.redhat.io/migration-toolkit-virtualization/mtv-must-gather-rhel8:{project-z-version}→ tag:2.12.0; the Red Hat catalog tag endpoint for.../mtv-must-gather-rhel8/tag/2.12.0returnsHTTP 200with{"data": [], ... "total": 0}, so the2.12.0tag isn’t present there. - Operator CSV name interpolation must also match real catalog entries:
- documentation/modules/proc_installing-mtv-operator.adoc:95
startingCSV: "{namespace}-operator.{project-z-version}" - documentation/modules/proc_installing-mtv-operator.adoc:115
startingCSV: "mtv-operator.v{project-z-version}"
Verify the corresponding CSVs for2.12.0exist before release/publishing.
- documentation/modules/proc_installing-mtv-operator.adoc:95
🤖 Prompt for 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.
In `@documentation/modules/common-attributes.adoc` at line 26, The docs reference
a non-existent MTV 2.12.0 tag and CSVs: update or gate publication so we don't
publish docs unless the artifacts exist by (1) checking the tag referenced by
:project-z-version in documentation/modules/common-attributes.adoc actually
exists in the Red Hat catalog, and (2) verifying the CSV names interpolated in
documentation/modules/proc_installing-mtv-operator.adoc (the startingCSV values
`"{namespace}-operator.{project-z-version}"` and
`"mtv-operator.v{project-z-version}"`) match real catalog entries; if the
tag/CSVs are missing, either bump :project-z-version to a published release or
add a pre-publish validation that aborts docs publish until the image/CSV
artifacts are present.
Comment on lines
+12
to
+15
| RDM disks converted to a LUN now have the correct SCSI interface type:: | ||
| Before this update, setting `spec.rdmAsLun=true` in a `MigrationPlan` converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN) but kept the `virtio` interface instead of changing it to Small Computer System Interface (SCSI) [1, 2]. As a consequence, the LUN disk type was incompatible with the user interface (UI) [1, 2]. With this release, the interface type conversion for RDM disks in a `MigrationPlan` is corrected [1, 2]. As a result, RDM disks converted to a LUN have the required `SCSI` interface type [1, 2]. | ||
| + | ||
| link:https://redhat.atlassian.net/browse/MTV-5610[MTV-5610] |
There was a problem hiding this comment.
Remove citation markers from the text.
The description contains multiple [1, 2] markers that appear to be remnants from another documentation format. These will render literally in the AsciiDoc output and confuse readers. Remove all occurrences of [1, 2] from the text.
📝 Proposed fix to remove citation markers
-RDM disks converted to a LUN now have the correct SCSI interface type::
-Before this update, setting `spec.rdmAsLun=true` in a `MigrationPlan` converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN) but kept the `virtio` interface instead of changing it to Small Computer System Interface (SCSI) [1, 2]. As a consequence, the LUN disk type was incompatible with the user interface (UI) [1, 2]. With this release, the interface type conversion for RDM disks in a `MigrationPlan` is corrected [1, 2]. As a result, RDM disks converted to a LUN have the required `SCSI` interface type [1, 2].
+RDM disks converted to a LUN now have the correct SCSI interface type::
+Before this update, setting `spec.rdmAsLun=true` in a `MigrationPlan` converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN) but kept the `virtio` interface instead of changing it to Small Computer System Interface (SCSI). As a consequence, the LUN disk type was incompatible with the user interface (UI). With this release, the interface type conversion for RDM disks in a `MigrationPlan` is corrected. As a result, RDM disks converted to a LUN have the required `SCSI` interface type.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| RDM disks converted to a LUN now have the correct SCSI interface type:: | |
| Before this update, setting `spec.rdmAsLun=true` in a `MigrationPlan` converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN) but kept the `virtio` interface instead of changing it to Small Computer System Interface (SCSI) [1, 2]. As a consequence, the LUN disk type was incompatible with the user interface (UI) [1, 2]. With this release, the interface type conversion for RDM disks in a `MigrationPlan` is corrected [1, 2]. As a result, RDM disks converted to a LUN have the required `SCSI` interface type [1, 2]. | |
| + | |
| link:https://redhat.atlassian.net/browse/MTV-5610[MTV-5610] | |
| RDM disks converted to a LUN now have the correct SCSI interface type:: | |
| Before this update, setting `spec.rdmAsLun=true` in a `MigrationPlan` converted the Raw Device Mapping (RDM) disk to a logical unit number (LUN) but kept the `virtio` interface instead of changing it to Small Computer System Interface (SCSI). As a consequence, the LUN disk type was incompatible with the user interface (UI). With this release, the interface type conversion for RDM disks in a `MigrationPlan` is corrected. As a result, RDM disks converted to a LUN have the required `SCSI` interface type. | |
| link:https://redhat.atlassian.net/browse/MTV-5610[MTV-5610] |
🤖 Prompt for 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.
In `@documentation/modules/ref_resolved-issues-2-12-0.adoc` around lines 12 - 15,
The AsciiDoc paragraph describing RDM disks contains stray citation markers "[1,
2]" that will render literally; remove all occurrences of "[1, 2]" from the text
that mentions spec.rdmAsLun=true, MigrationPlan, RDM, LUN, and SCSI so the
sentence reads naturally (e.g., "With this release, the interface type
conversion for RDM disks in a MigrationPlan is corrected." and "As a result, RDM
disks converted to a LUN have the required SCSI interface type.") and keep the
existing link to MTV-5610 unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by CodeRabbit
Documentation
New Features
Known Issues