feat(zfspv): pvc should be bound only if volume has been created. #121
Conversation
This file contains 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
pawanpraka1
added
enhancement
pawanpraka1
force-pushed
the
pvcBound
branch
2 times, most recently
from
bfdc6df
to
f29006a
Compare
Codecov Report
@@ Coverage Diff @@
## master #121 +/- ##
=======================================
Coverage 22.90% 22.90%
=======================================
Files 14 14
Lines 489 489
=======================================
Hits 112 112
Misses 376 376
Partials 1 1 Continue to review full report at Codecov.
|
kmova
reviewed
May 20, 2020
kmova
reviewed
May 20, 2020
kmova
reviewed
May 20, 2020
| @@ -0,0 +1 @@ | |||
| enhancement to bound the pvc only if volume has been created | |||
There was a problem hiding this comment.
Fixes an issue where ZFS PV with an invalid pool was bound to PVC.
There was a problem hiding this comment.
updated the description.
kmova
reviewed
May 20, 2020
kmova
reviewed
May 20, 2020
kmova
reviewed
May 20, 2020
| @@ -0,0 +1 @@ | |||
| Fixes an issue where PVC was bound to PV because of invalid/wrong parameters in PVC/Storageclass. | |||
There was a problem hiding this comment.
n_ : Fixes an issue where PVC was bound to invalid PV created using incorrect values provided in PVC/Storageclass.
Need to find a better word for "invalid" to qualify this PV.
There was a problem hiding this comment.
made it unusable.
Fixes an issue where PVC was bound to unusable PV created using incorrect values provided in PVC/Storageclass.
The controller does not check whether the volume has been created or not and return successful. Which in turn binds the pvc to the pv. The PVC should not bound until corresponding zfs volume has been created. Now controller will check the ZFSVolume CR state to be "Ready" before returning successful. The CSI will retry the CreateVolume request when it will get a error reply and when the ZFS node agent creates the ZFS volume and sets the ZFSVolume CR state to be "Ready", the controller will return success for the CreateVolume Request and then PVC will be bound. Signed-off-by: Pawan <pawan@mayadata.io>
kmova
approved these changes
May 21, 2020
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 4, 2020
When we are deleting a PVC which is not bound because of the wrong parameters/poolname in the storageclass. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still zv will be showing state a Pending until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 4, 2020
PVC will not bound if there is wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
7 tasks
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 4, 2020
PVC will not bound if there is wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 4, 2020
PVC will not bound if there is wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 5, 2020
PVC will not bound if there are wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
pawanpraka1
added a commit
to pawanpraka1/zfs-localpv
that referenced
this pull request
Jun 5, 2020
PVC will not bound if there are wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in openebs#121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
kmova
pushed a commit
that referenced
this pull request
Jun 8, 2020
PVC will not bound if there are wrong parameters/poolname in the storageclass, the ZFSVolume CR will be still created and will remain in Pending State, deletion of the PVC will delete PVC and since PVC is not bound, ZFS-LocalPV driver will not get the delete call and will leave the ZFSVolume CR hanging there. Reverting the behavior introduced in #121, Now PVC will be bound but still ZFSVolume will be in Pending state until the volume is created. Signed-off-by: Pawan <pawan@mayadata.io>
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.
fixes: #111
Signed-off-by: Pawan pawan@mayadata.io
Why is this PR required? What issue does it fix?:
The controller does not check whether the volume has been created or not
and return successful. Which in turn binds the pvc to the pv.
What this PR does?:
The PVC should not bound until corresponding zfs volume has been created.
Now controller will check the ZFSVolume CR state to be "Ready" before returning
successful. The CSI will retry the CreateVolume request when it will get
a error reply and when the ZFS node agent creates the ZFS volume and sets the
ZFSVolume CR state to be "Ready", the controller will return success for the
CreateVolume Request and then PVC will be bound.
Checklist:
<type>(<scope>): <subject>