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 GuideUpdates to WFFC handling in VirtualDisk controller: logic now dynamically fetches StorageClass binding mode, excludes disks with attached VMs from staying in WaitForFirstConsumer phase, and corresponding test adjustments were made. Sequence diagram for VirtualDisk phase update after VM attachmentsequenceDiagram
participant VDController
participant VirtualDisk
participant StorageClass
participant VM
participant DataVolume
VDController->>VirtualDisk: Check Status.Phase
VDController->>StorageClass: Fetch by StorageClassName
StorageClass-->>VDController: Return VolumeBindingMode
VDController->>VirtualDisk: Check AttachedToVirtualMachines
alt VolumeBindingMode is WaitForFirstConsumer and no VM attached
VDController->>VirtualDisk: Set Phase to WaitForFirstConsumer
else VM is attached
VDController->>VirtualDisk: Do not set Phase to WaitForFirstConsumer
end
Class diagram for updated VirtualDisk WaitForFirstConsumer logicclassDiagram
class BlockDeviceHandler {
+checkVirtualDisksToBeWFFC(ctx, s)
client
}
class VirtualDisk {
Status
Status.Phase
Status.StorageClassName
Status.Conditions
Status.AttachedToVirtualMachines
}
class StorageClass {
VolumeBindingMode
}
BlockDeviceHandler --> VirtualDisk : checks
BlockDeviceHandler --> StorageClass : fetches
VirtualDisk --> StorageClass : references by StorageClassName
class WaitForDVStep {
+setForFirstConsumerIsAwaited(ctx, vd)
dv
cb
}
WaitForDVStep --> VirtualDisk : updates phase
WaitForDVStep --> StorageClass : checks binding mode
class DataVolume {
Status.Phase
}
WaitForDVStep --> DataVolume : checks phase
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?
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.
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