fix(vd): prevent VirtualDisk from stuck in WaitForFirstConsumer phase when VM is attached #1516
Conversation
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
Reviewer's GuideThis PR refines the handling of WaitForFirstConsumer (WFFC) storage classes by fetching the StorageClass in relevant controllers, checking the DataVolumeRunning condition before setting the VirtualDisk phase, and updating watchers—all to prevent VirtualDisks from appearing stuck once a VM is attached and provisioning has started. Sequence diagram for VirtualDisk phase transition with WFFC after VM attachmentsequenceDiagram
participant VD as VirtualDisk Controller
participant SC as StorageClass
participant DV as DataVolume
participant VM as VirtualMachine
VD->SC: Fetch StorageClass for VD
SC-->>VD: Return StorageClass with WFFC mode
VD->DV: Check DataVolumeRunning condition
DV-->>VD: Return DataVolumeRunning status
VD->VM: Detect VM attachment to VD
VD->VD: Set phase to WaitForFirstConsumer only if DVRunning is false and reason is empty
VD->VD: Transition out of WaitForFirstConsumer if provisioning started
Class diagram for updated VirtualDisk phase handling logicclassDiagram
class VirtualDisk {
+Status: Phase, StorageClassName, Conditions
}
class StorageClass {
+VolumeBindingMode
}
class DataVolume {
+Status: Phase, Conditions
}
class BlockDeviceHandler {
+checkVirtualDisksToBeWFFC()
}
class WaitForDVStep {
+setForFirstConsumerIsAwaited()
}
VirtualDisk --> StorageClass : fetches
VirtualDisk --> DataVolume : checks DataVolumeRunning
BlockDeviceHandler --> VirtualDisk : checks phase
WaitForDVStep --> VirtualDisk : sets phase
WaitForDVStep --> DataVolume : checks DVRunning condition
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Signed-off-by: Daniil Loktev <[email protected]>
loktev-d
force-pushed
the
fix/vd/wffc-stuck-in-waiting-phase
branch
from
7cb3b44 to
1909f13
Compare
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
|
Workflow has started. The target step completed with status: failure. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `images/virtualization-artifact/pkg/controller/vm/internal/block_device_condition.go:60-66` </location>
<code_context>
for _, vd := range vds {
- if vd.Status.Phase == v1alpha2.DiskWaitForFirstConsumer {
- return true, nil
+ scName := vd.Status.StorageClassName
+ sc, err := object.FetchObject(ctx, types.NamespacedName{Name: scName}, h.client, &storagev1.StorageClass{})
+ if err != nil {
+ return false, fmt.Errorf("fetch storage class %s: %w", scName, err)
+ }
+
+ if sc != nil && sc.VolumeBindingMode != nil && *sc.VolumeBindingMode == storagev1.VolumeBindingWaitForFirstConsumer {
+ readyCondition, _ := conditions.GetCondition(vdcondition.ReadyType, vd.Status.Conditions)
+ if readyCondition.Status != metav1.ConditionTrue {
</code_context>
<issue_to_address>
**suggestion:** Consider handling missing or empty StorageClassName more explicitly.
If vd.Status.StorageClassName is empty, FetchObject will try to fetch a storage class with an empty name, which could cause errors or unnecessary log entries. Consider adding a check to handle this case before calling FetchObject.
</issue_to_address>
### Comment 2
<location> `images/virtualization-artifact/pkg/controller/vm/internal/block_device_condition.go:68` </location>
<code_context>
+ readyCondition, _ := conditions.GetCondition(vdcondition.ReadyType, vd.Status.Conditions)
</code_context>
<issue_to_address>
**issue (bug_risk):** Check for nil readyCondition before accessing Status.
Add a nil check for readyCondition before accessing its Status to prevent a potential panic.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+60
to
+66
| scName := vd.Status.StorageClassName | ||
| sc, err := object.FetchObject(ctx, types.NamespacedName{Name: scName}, h.client, &storagev1.StorageClass{}) | ||
| if err != nil { | ||
| return false, fmt.Errorf("fetch storage class %s: %w", scName, err) | ||
| } | ||
|
|
||
| if sc != nil && sc.VolumeBindingMode != nil && *sc.VolumeBindingMode == storagev1.VolumeBindingWaitForFirstConsumer { |
There was a problem hiding this comment.
suggestion: Consider handling missing or empty StorageClassName more explicitly.
If vd.Status.StorageClassName is empty, FetchObject will try to fetch a storage class with an empty name, which could cause errors or unnecessary log entries. Consider adding a check to handle this case before calling FetchObject.
|
|
||
| if sc != nil && sc.VolumeBindingMode != nil && *sc.VolumeBindingMode == storagev1.VolumeBindingWaitForFirstConsumer { | ||
| readyCondition, _ := conditions.GetCondition(vdcondition.ReadyType, vd.Status.Conditions) | ||
| if readyCondition.Status != metav1.ConditionTrue { |
There was a problem hiding this comment.
issue (bug_risk): Check for nil readyCondition before accessing Status.
Add a nil check for readyCondition before accessing its Status to prevent a potential panic.
LopatinDmitr
reviewed
Oct 8, 2025
| for _, vd := range vds { | ||
| if vd.Status.Phase == v1alpha2.DiskWaitForFirstConsumer { | ||
| return true, nil | ||
| scName := vd.Status.StorageClassName |
There was a problem hiding this comment.
Why do we check the SC type of the disk in VM? Why can't we trust the VD phase?
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
loktev-d
force-pushed
the
fix/vd/wffc-stuck-in-waiting-phase
branch
from
36aa92e to
ed1e88c
Compare
This reverts commit 33dd5f1. Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
loktev-d
force-pushed
the
fix/vd/wffc-stuck-in-waiting-phase
branch
from
ed1e88c to
99449cc
Compare
Signed-off-by: Daniil Loktev <[email protected]>
Signed-off-by: Daniil Loktev <[email protected]>
|
Workflow has started. The target step completed with status: success. |
There was a problem hiding this comment.
Hey there - I've reviewed your changes and they look great!
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location> `images/virtualization-artifact/pkg/controller/vm/internal/block_device_condition.go:61` </location>
<code_context>
- if vd.Status.Phase == v1alpha2.DiskWaitForFirstConsumer {
- return true, nil
+ scName := vd.Status.StorageClassName
+ sc, err := object.FetchObject(ctx, types.NamespacedName{Name: scName}, h.client, &storagev1.StorageClass{})
+ if err != nil {
+ return false, fmt.Errorf("fetch storage class %s: %w", scName, err)
</code_context>
<issue_to_address>
**suggestion:** Consider handling the case where scName is empty before fetching the StorageClass.
A guard clause for empty scName would avoid unnecessary API calls and reduce confusion from attempting to fetch a StorageClass with no name.
</issue_to_address>
### Comment 2
<location> `images/virtualization-artifact/pkg/controller/vd/internal/source/step/wait_for_dv_step.go:138` </location>
<code_context>
return false, fmt.Errorf("get sc: %w", err)
}
+ dvRunningCond, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, s.dv.Status.Conditions)
isWFFC := sc != nil && sc.VolumeBindingMode != nil && *sc.VolumeBindingMode == storagev1.VolumeBindingWaitForFirstConsumer
- if isWFFC && (s.dv.Status.Phase == cdiv1.PendingPopulation || s.dv.Status.Phase == cdiv1.WaitForFirstConsumer) {
</code_context>
<issue_to_address>
**issue (bug_risk):** Consider checking for nil dvRunningCond before accessing its fields.
Accessing dvRunningCond.Status or dvRunningCond.Reason without a nil check may cause a panic if GetDataVolumeCondition returns nil. Please add a nil check to prevent this.
</issue_to_address>
### Comment 3
<location> `images/virtualization-artifact/pkg/controller/vd/internal/source/sources.go:185` </location>
<code_context>
}
- if isStorageClassWFFC(sc) && (dv.Status.Phase == cdiv1.PendingPopulation || dv.Status.Phase == cdiv1.WaitForFirstConsumer) {
+
+ dvRunningCond, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, dv.Status.Conditions)
+ if isStorageClassWFFC(sc) && (dv.Status.Phase == cdiv1.PendingPopulation || dv.Status.Phase == cdiv1.WaitForFirstConsumer) && dvRunningCond.Status == corev1.ConditionFalse && dvRunningCond.Reason == "" {
vd.Status.Phase = v1alpha2.DiskWaitForFirstConsumer
</code_context>
<issue_to_address>
**issue (bug_risk):** Missing nil check for dvRunningCond could lead to panics.
Add a nil check for dvRunningCond before accessing its fields to prevent potential panics.
</issue_to_address>
### Comment 4
<location> `images/virtualization-artifact/pkg/controller/vd/internal/watcher/datavolume_watcher.go:76-79` </location>
<code_context>
return true
}
+ oldDVRunning, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, e.ObjectOld.Status.Conditions)
+ newDVRunning, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, e.ObjectNew.Status.Conditions)
+
+ if oldDVRunning.Reason != newDVRunning.Reason {
+ return true
+ }
</code_context>
<issue_to_address>
**issue (bug_risk):** Potential nil dereference if oldDVRunning or newDVRunning is nil.
Add nil checks for oldDVRunning and newDVRunning before accessing their Reason fields to prevent panics.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
| if vd.Status.Phase == v1alpha2.DiskWaitForFirstConsumer { | ||
| return true, nil | ||
| scName := vd.Status.StorageClassName | ||
| sc, err := object.FetchObject(ctx, types.NamespacedName{Name: scName}, h.client, &storagev1.StorageClass{}) |
There was a problem hiding this comment.
suggestion: Consider handling the case where scName is empty before fetching the StorageClass.
A guard clause for empty scName would avoid unnecessary API calls and reduce confusion from attempting to fetch a StorageClass with no name.
| return false, fmt.Errorf("get sc: %w", err) | ||
| } | ||
|
|
||
| dvRunningCond, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, s.dv.Status.Conditions) |
There was a problem hiding this comment.
issue (bug_risk): Consider checking for nil dvRunningCond before accessing its fields.
Accessing dvRunningCond.Status or dvRunningCond.Reason without a nil check may cause a panic if GetDataVolumeCondition returns nil. Please add a nil check to prevent this.
| } | ||
| if isStorageClassWFFC(sc) && (dv.Status.Phase == cdiv1.PendingPopulation || dv.Status.Phase == cdiv1.WaitForFirstConsumer) { | ||
|
|
||
| dvRunningCond, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, dv.Status.Conditions) |
There was a problem hiding this comment.
issue (bug_risk): Missing nil check for dvRunningCond could lead to panics.
Add a nil check for dvRunningCond before accessing its fields to prevent potential panics.
Comment on lines
+76
to
+79
| oldDVRunning, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, e.ObjectOld.Status.Conditions) | ||
| newDVRunning, _ := conditions.GetDataVolumeCondition(conditions.DVRunningConditionType, e.ObjectNew.Status.Conditions) | ||
|
|
||
| if oldDVRunning.Reason != newDVRunning.Reason { |
There was a problem hiding this comment.
issue (bug_risk): Potential nil dereference if oldDVRunning or newDVRunning is nil.
Add nil checks for oldDVRunning and newDVRunning before accessing their Reason fields to prevent panics.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Description
Fix VirtualDisk remaining in
WaitForFirstConsumerphase even after VM attachment and provisioning has started.Why do we need it, and what problem does it solve?
When using WFFC storage class with volume populators:
WaitForFirstConsumerwaiting for VMWaitForFirstConsumerbecause DataVolume is inPendingPopulationstate, even though the "first consumer" (VM) already existsThis creates perception of "hanging" - users see VD stuck in WFFC for minutes while provisioning is actually running.
What is the expected result?
Checklist
Changelog entries