-
Notifications
You must be signed in to change notification settings - Fork 175
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
Add separate workqueue for unsaved PVs #33
Add separate workqueue for unsaved PVs #33
Conversation
f58fcf3
to
e2acbb3
Compare
4b0e843
to
dc9d3c9
Compare
dc9d3c9
to
e001d72
Compare
e001d72
to
86d0187
Compare
86d0187
to
84dad7d
Compare
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jsafrane The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Added unit tests and removed WIP:, ready for review. |
84dad7d
to
8ab08f2
Compare
controller/controller.go
Outdated
c.createProvisionedPVInterval = createProvisionedPVInterval | ||
return nil | ||
} | ||
} | ||
|
||
// CreateProvisionedPVBackoff is the configuration of exponential backoff between retries when we create a | ||
// PV object for a provisioned volume. Defaults to linear backoff, 10 seconds 5 times. | ||
// If PV is not saved after given number of retries, corresponding storage asset (volume) is deleted! | ||
// Only one of CreateProvisionedPVInterval+CreateProvisionedPVRetryCount or CreateProvisionedPVBackoff | ||
// can be used. |
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.
still want to deprecate this?
Deprecated: Use CreateProvisionedPVLimiter instead.
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.
Added
Factor: 1, // linear backoff | ||
Steps: controller.createProvisionedPVRetryCount, | ||
Cap: controller.createProvisionedPVInterval, | ||
if controller.createProvisionerPVLimiter != nil { |
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.
should it be default someday? is there any performance hit? I guess it does not matter as long as csi-provisioner uses it.
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.
I'd say eventually it should be default, but after a long deprecation period. As you wrote, csi-provisioner is going to use it and that's what matters.
|
||
var _ VolumeStore = &queueStore{} | ||
|
||
func NewVolumeStoreQueue( |
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.
need comment to pass repo-infra
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.
Fixed
|
||
var _ VolumeStore = &backoffStore{} | ||
|
||
func NewBackoffStore(client kubernetes.Interface, |
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.
need comment to pass repo-infra
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.
Fixed
8ab08f2
to
f7a8a33
Compare
/lgtm |
…pansion Enable hostpath expansion
Work in progress:
CreateProvisionedPV*
options?This PR yet another configuration option to run provisioning controller with a separate workqueue of unsaved PVs (their
client.CoreV1().PersistentVolumes().Create(volume)
failed).The workqueue gets its limiter from provisioner, exponential backoff is expected. When a PV enters the queue, it cannot be deleted, i.e. the controller tries to create the PV even if user deleted corresponding PVC. Expectation is that API server error is a temporary hiccup that's going to be resolved quickly or the provisioner looses its leadership and exits. Unsaved PVs are lost in this case (or when the controller exits from any other reason)!
cc @wongma7 @msau42
I'd also suggest that at least
CreateProvisionedPVBackoff
option is deprecated and removed in a next release.