<fix>[kvm]: normalize osVersion when matching DVD metadata#3748
Closed
ZStack-Robot wants to merge 1 commit into5.5.12from
Closed
<fix>[kvm]: normalize osVersion when matching DVD metadata#3748ZStack-Robot wants to merge 1 commit into5.5.12from
ZStack-Robot wants to merge 1 commit into5.5.12from
Conversation
Strip a leading V/v from osVersion before building the HostOsCategoryVO lookup key, so that distributions that expose VERSION_ID="V10" (notably Kylin Linux Advanced Server) join correctly with DVD metadata that records the same release as plain "10". 1. Why is this change necessary? KvmHypervisorInfoHelper.collectExpectedHypervisorInfoForHosts builds the lookup key as "<distribution> <version>" and compares it against HostOsCategoryVO.osReleaseVersion. On Kylin V10 hosts KVMHostVO.osVersion is persisted as "V10" straight from /etc/os-release VERSION_ID, while the DVD script /opt/zstack-dvd/x86_64/ky10sp3/Extra/virtualizer-info.sh hard-codes platform.version:10. The two sides build "kylin V10" vs "kylin 10", the join silently returns nothing and matchTargetVersion stays null, leaving every Kylin host in matchState=Unknown even when its qemu-kvm version matches the DVD exactly. Was masked before by the alarm filter only looking at Unmatched. 2. How does it address the problem? Add KvmHypervisorInfoHelper.normalizeOsVersion that strips a leading V/v only when the next character is a digit, so "V10" -> "10" but "Vrouter" stays "Vrouter". Apply the same normalization on both sides: when lookup builds the osReleaseVersion key, and when HypervisorMetadataCollectorImpl writes a fresh metadata row from the DVD script output. With both sides normalized the join succeeds and the existing matchState pipeline reports Matched/Unmatched. 3. Are there any side effects? None on existing CentOS/Rocky/Helix hosts whose osVersion is already a plain numeric string. Existing metadata is rebuilt with the normalized form on the next refreshMetadata call (i.e. MN restart) so no manual data migration is needed. # Summary of changes (by module): - kvm: add normalizeOsVersion helper and apply it both in collectExpectedHypervisorInfoForHosts (lookup) and in HypervisorMetadataCollectorImpl.collectHypervisorMetadata (metadata write). Related: ZSTAC-83682 Change-Id: I4c160f416490e91a08df0acdc5594effb23160e4
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: http://open.zstack.ai:20001/code-reviews/zstack-cloud.yaml (via .coderabbit.yaml) Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
演进概览两个KVM超管理器文件现已规范化操作系统版本值。新增 变更明细
代码审阅工作量估计🎯 2 (简单) | ⏱️ ~10 分钟 庆祝诗
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
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
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.
ZSTAC-83682 (reopen)
Root Cause
On Kylin Linux Advanced Server V10 hosts,
KVMHostVO.osVersionis persisted asV10straight from/etc/os-release(VERSION_ID="V10"), while the matching DVD script/opt/zstack-dvd/x86_64/ky10sp3/Extra/virtualizer-info.shhard-codesplatform.version:10.KvmHypervisorInfoHelper.collectExpectedHypervisorInfoForHostsbuilds the lookup key asString.format("%s %s", os.distribution, os.version), so the host side asks forkylin V10whileHostOsCategoryVO.osReleaseVersiononly haskylin 10. The join silently returns 0 rows,matchTargetVersionstays null and every Kylin host is stuck inmatchState=Unknowneven when its qemu-kvm version matches the DVD exactly. Verified on env 172.24.189.63 — 4 hosts, host qemu and DVD metadata both6.2.0-451.g623f2a5caf.ky10, all stuck in Unknown.This was masked before the alarm-side fixes because the alarm filter only looked at
Unmatched. Once the alarm side started covering non-Matched states, the casetest_zstack_mn_host_qemu(which asserts API field values directly) exposed the lookup miss.Changes
plugin/kvmKvmHypervisorInfoHelper.normalizeOsVersion. Strip a leadingV/vonly when followed by a digit (V10->10,VrouterstaysVrouter).plugin/kvmnormalizeOsVersionincollectExpectedHypervisorInfoForHostswhen building the lookup key.plugin/kvmnormalizeOsVersioninHypervisorMetadataCollectorImpl.collectHypervisorMetadatawhen persisting a fresh metadata row from the DVD script output.Test
HypervisorMetadataCase.testNormalizeOsVersionForKylinHostsubtest (in the linked premium MR) covers the helper boundaries (V10/v10/10/null/empty/V/Vrouter/whitespace) and a simulated Kylin V10 host plus DVDplatform.version:10end-to-end join.Impact
osVersionis already a plain numeric string see no behavioral change (normalization is a no-op for them).refreshMetadata()call (i.e. MN restart). No manual data migration needed.Related MRs
bugfix/ZSTAC-83682-reopen@@2on premiumRelated: ZSTAC-83682
sync from gitlab !9616