fix(juicefs): correct stale PV fuse label key after Dataset recreation#6090
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a fix for issue #6089 by adding syncPVFuseLabelKey to keep the PV's mount_pod_node_selector_key CSI attribute in sync with the current fuse label key, preventing mount failures when the owner dataset UID changes. It also includes a unit test to verify this behavior. The review feedback points out a critical issue where assigning a value to pv.Spec.CSI.VolumeAttributes could cause a runtime panic if the map is nil, and provides a code suggestion to safely initialize it.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
…ative#6089) When namespace+name exceeds ~52 chars, GetFuseLabelName falls back to a UID-based key (fluid.io/f-<ownerDatasetUID>). If the Dataset is deleted and recreated the ownerDatasetUID changes, so SyncRuntime updates the fuse daemonset's nodeSelector to the new key while the PV's mount_pod_node_selector_key retains the old key. The CSI node plugin reads the stale key from the PV to label nodes, but the fuse daemonset has a different nodeSelector, so fuse pods never get scheduled and mounts fail. Fix: add syncPVFuseLabelKey() called unconditionally in syncFuseSpec() on every reconcile. It compares the PV's mount_pod_node_selector_key against runtimeInfo.GetFuseLabelName() and patches the PV if stale. Running it unconditionally ensures the PV is corrected even when no other fuse spec change is detected in the same reconcile cycle. Fixes: fluid-cloudnative#6089 Signed-off-by: Monika Jakhar <jakharmonika364@gmail.com>
b13e76f to
e26857d
Compare
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6090 +/- ##
==========================================
- Coverage 64.77% 64.76% -0.02%
==========================================
Files 484 484
Lines 33892 33925 +33
==========================================
+ Hits 21954 21970 +16
- Misses 10215 10227 +12
- Partials 1723 1728 +5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@jakharmonika364 Thanks for your PR that tries to fix the issue! But I think the changes won't fix the issue because PV is immutable after creation. So syncing PV fuse label key is not possible. We had some internal discussion with JuiceFSRuntime's maintainer @zwwhdls , and we decide to fix that issue by disable syncing fuse nodeSelector (I've opened a PR #6092 ). So I'll close this PR. |



Ⅰ. Describe what this PR does
When
namespace+nameexceeds ~52 characters,GetFuseLabelNamefalls back to a UID-based label key (fluid.io/f-<ownerDatasetUID>). If the Dataset gets deleted and recreated, theownerDatasetUIDchanges.SyncRuntimepicks up the new UID and updates the fuse daemonset's nodeSelector, butCreatePersistentVolumeForRuntimeonly creates PVs and never updates them, so the PV'smount_pod_node_selector_keykeeps pointing to the old key. The CSI node plugin reads this stale key from the PV to label nodes, the fuse daemonset nodeSelector no longer matches, fuse pods don't get scheduled, and mounts fail.This PR adds
syncPVFuseLabelKey()which is called unconditionally insyncFuseSpec()on every reconcile. It reads the PV's currentmount_pod_node_selector_keyand patches it if it doesn't matchruntimeInfo.GetFuseLabelName(). Running it unconditionally covers the case where the daemonset was already updated in a prior reconcile but the PV patch hadn't happened yet.Ⅱ. Does this pull request fix one issue?
fixes #6089
Ⅲ. List the added test cases (unit test/integration test) if any, please explain if no tests are needed.
Added
TestSyncPVFuseLabelKeyinpkg/ddc/juicefs/fuse_label_consistency_test.go:ownerDatasetUID_A)ownerDatasetUID_B(simulating Dataset recreation)syncPVFuseLabelKey()and asserts the PV'smount_pod_node_selector_keyis updated to the UID_B based keyⅣ. Describe how to verify it
Run the unit test:
go test ./pkg/ddc/juicefs/ -run TestSyncPVFuseLabelKey -vExpected output:
Ⅴ. Special notes for reviews
The fix runs a PV GET on every
syncFuseSpeccall. If the key already matches (common case), no update is made. The slight extra cost per reconcile is acceptable given mounts would otherwise fail silently.