title | authors | owners | creation-date | last-updated | status | ||
---|---|---|---|---|---|---|---|
VolumeBindingMode |
|
|
2021-06-16 |
2021-06-16 |
Implemented |
This proposal points out workflow details to support volume binding modes.
- As a user, I should be able to provision volume before deploying an application.
- As a user, I should be able to provision volume only when an application is requested.
LVM-LocalPV doesn't have any direct dependency over volumebinding modes moreover these are standard Kubernetes storageclass option. For more information about workflow is available here.
LVM-LocalPV honours both types of VolumeBindingModes Immediate
& WaitForFirstConsumer
.
- Configuring
Immediate
informs Kubernetes volume provisioning should be instantiated right after creation of PersistentVolumeClaim(PVC). - Configuring
WaitForFirstConsumer
inform Kubernetes volume provisioning should be only after availability of consumer.
Note: If VolumeBindingMode is unspecified then defaults to Immediate
mode.
- User/Admin can specify type of binding mode according to their usecases:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: openebs-lvm
provisioner: local.csi.openebs.io
parameters:
storage: "lvm"
vgpattern: "lvmvg.*"
volumeBindingMode: WaitForFirstConsumer ## It can also replaced by Immediate volume binding mode depends on use case.
- Provision volume with immediate binding mode and verify that volume should get provisioned.
- Provision volume with delayed binding mode and verify that volume should remain in pending state till application deployed on volume.
- Provision application with delayed volume binding mode and verify whether pod is scheduled on a node where maximum capacity is available.
All testcases mentioned in Test Plan section need to be automated
NA
NA