-
Notifications
You must be signed in to change notification settings - Fork 3
fix(vmbda): report error when device is unavailable on VM node #1561
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Daniil Loktev <[email protected]>
Reviewer's GuideAdds explicit node affinity validation for PersistentVolumes in VMBDA: AttachmentService now fetches the PV and target Node to verify the volume’s node affinity, and the handler fails hot-plug operations with a clear 'DeviceNotAvailableOnNode' status when the PV isn’t available on the VM’s node. Sequence diagram for VMBDA block device attachment with node affinity validationsequenceDiagram
participant "LifeCycleHandler"
participant "AttachmentService"
participant "PersistentVolumeClaim (PVC)"
participant "PersistentVolume (PV)"
participant "Node"
participant "VirtualMachineInstance (kvvmi)"
actor "User"
"User"->>"LifeCycleHandler": Request block device attachment
"LifeCycleHandler"->>"AttachmentService": GetPersistentVolumeClaim(ad)
"AttachmentService"->>"PersistentVolumeClaim (PVC)": Fetch PVC
"AttachmentService"->>"LifeCycleHandler": Return PVC
"LifeCycleHandler"->>"AttachmentService": IsPVAvailableOnVMNode(pvc, kvvmi)
"AttachmentService"->>"PersistentVolume (PV)": Fetch PV
"AttachmentService"->>"Node": Fetch Node (kvvmi.Status.NodeName)
"AttachmentService"->>"AttachmentService": Check PV node affinity against Node
alt PV not available on VM node
"AttachmentService"->>"LifeCycleHandler": Return false
"LifeCycleHandler"->>"User": Report error: DeviceNotAvailableOnNode
else PV available on VM node
"AttachmentService"->>"LifeCycleHandler": Return true
"LifeCycleHandler"->>"AttachmentService": HotPlugDisk(...)
end
Class diagram for updated AttachmentService and LifeCycleHandlerclassDiagram
class AttachmentService {
+GetPersistentVolumeClaim(ctx, ad)
+GetPersistentVolume(ctx, pvName)
+GetVirtualMachine(ctx, name, namespace)
+GetKVVMI(ctx, vm)
+IsPVAvailableOnVMNode(ctx, pvc, kvvmi)
}
class LifeCycleHandler {
+Handle(ctx, vmbda)
-attacher: AttachmentService
}
AttachmentService <.. LifeCycleHandler: uses
Class diagram for vmbdacondition with new DeviceNotAvailableOnNode reasonclassDiagram
class AttachedReason {
+Conflict
+DeviceNotAvailableOnNode
}
class DiskAttachmentCapacityAvailableReason {
+CapacityAvailable
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Workflow has started. The target step completed with status: failure. |
Workflow has started. The target step completed with status: failure. |
Workflow has started. The target step completed with status: failure. |
Workflow has started. The target step completed with status: failure. |
Signed-off-by: Daniil Loktev <[email protected]>
Workflow has started. The target step completed with status: failure. |
Workflow has started. The target step completed with status: success. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description
Add condition error for PersistentVolume node affinity when attached block devices via VMBDA is not available on VM node.
Why do we need it, and what problem does it solve?
When using storage classes with node affinity, the PersistentVolume is pinned to a specific node. If a user tries to hot-plug such a disk to a VM running on a different node, the attachment fails silently or with unclear errors.
What is the expected result?
Checklist
Changelog entries