Skip to content
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

[do not merge]: Allow reclamation of PersistentVolumes #8334

Closed
wants to merge 18 commits into from

Conversation

markturansky
Copy link
Contributor

  • New pv.Spec.ReclamationPolicy
    • Allows Recycle/Delete on release. Retain by default.
  • New volume plugin interfaces
    • RecyclableVolumePlugin -- allows recycling of PVs
    • DeletableVolumePlugin -- allows deletion of PVs from the infrastructure
  • New PersistentVolumeRecycler controller loop
    • single threaded initially for correctness
    • separate from PersistentVolumeClaimBinder because we don't want the binder to block on reclamation tasks
    • works with the binder to remove or re-add reclaimed volumes to/from the pool of available volumes

Needs implementations:

  • Basic scrub impl: run a pod w/ busybox "rm -rf" on the volume
    • develop/test with HostPath, use for NFS, potentially other volumes
  • Cloud volumes: delete via API

PVs deleted from cloud providers as policy will be reprovisioned by #6773

Edit: The purpose of this PR is to dynamically reclaim used and released resources. As PersistentVolumeClaims are deleted, their backing PersistentVolumes are released, but they are not yet reusable. Either they need to be scrubbed of their data before become Available again or the volumes should be deleted from the infrastructure.

The scrubbing use case is a build server using NFS as scratch space. No need for an admin to reprovision the cluster after the volumes are used up. Basic scrub is sufficient to put them back into the pool. Don't use basic scrub at The Fed or the NSA.

@markturansky
Copy link
Contributor Author

@pmorie @thockin would love feedback on the direction, particularly around the new types of volume plugins (to allow some but not all PVs to be recycled or deleted).

@markturansky
Copy link
Contributor Author

I will remove Deleter as an interface to narrow the scope to just Recycler. I would like confirmation that using new types of plugins is the correct way of handling this, though, so the current Recycler can be implemented and we'll know the future Deleter would be the correct solution.

@pmorie
Copy link
Member

pmorie commented May 18, 2015

Gonna take a pass at this today at some point.

@@ -256,6 +256,11 @@ func (s *CMServer) Run(_ []string) error {

pvclaimBinder := volumeclaimbinder.NewPersistentVolumeClaimBinder(kubeClient, s.PVClaimBinderSyncPeriod)
pvclaimBinder.Run()
pvRecycler, err := volumeclaimbinder.NewPersistentVolumeRecycler(kubeClient, s.PVClaimBinderSyncPeriod, ProbeRecyclableVolumePlugins())
if err != nil {
glog.Errorf("Failed to start persistent volume recycler: %+v", err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this an error or a Fatal?

@thockin
Copy link
Member

thockin commented May 22, 2015

Overall LGTM, I'll let it percolate. It'll need a finer-grained review when I have a bit more time for it.

@markturansky
Copy link
Contributor Author

Thanks @thockin. I'll ping again when ready for a full review.

@markturansky markturansky force-pushed the pv_recycling branch 3 times, most recently from 41ad32b to e024dc9 Compare May 26, 2015 17:50
@saad-ali
Copy link
Member

Thank you very much for the pull request - we sincerely appreciate the work that goes into sending us a change.

We are currently in a feature-freeze and general code slush as we work toward our 1.0 release. Our initial triage indicates that this is a non-critical change at this time, so we'd like to leave it open and revisit it after 1.0. We expect the freeze to wrap up in early to mid July.

If you feel that this triage is incorrect, please respond and let us know why. We're currently accepting changes that meet any of the following criteria:

  1. Changes directly related to v1.0 issues
  2. Changes addressing P0 bugs
  3. Changes to supported platforms to bring them up to par with the primary development platforms
  4. Docs, user experience, and test related fixes

@saad-ali saad-ali added this to the v1.0-post milestone May 26, 2015
@smarterclayton
Copy link
Contributor

This in on the RH priority list for merge.

@smarterclayton
Copy link
Contributor

We can potentially push it if the risk is seen as high, but I haven't seen that triage performed.

@thockin
Copy link
Member

thockin commented May 26, 2015

Iff we can turn this around reasonably quickly we can get it in.

On Tue, May 26, 2015 at 12:11 PM, Clayton Coleman notifications@github.com
wrote:

We can potentially push it if the risk is seen as high, but I haven't seen
that triage performed.


Reply to this email directly or view it on GitHub
#8334 (comment)
.

@smarterclayton
Copy link
Contributor

Mark is today or tomorrow reasonable or is there more still there?

On May 26, 2015, at 3:47 PM, Tim Hockin notifications@github.com wrote:

Iff we can turn this around reasonably quickly we can get it in.

On Tue, May 26, 2015 at 12:11 PM, Clayton Coleman notifications@github.com
wrote:

We can potentially push it if the risk is seen as high, but I haven't seen
that triage performed.


Reply to this email directly or view it on GitHub
#8334 (comment)
.


Reply to this email directly or view it on GitHub.

@markturansky
Copy link
Contributor Author

I am only working through the busybox implementation. debugging it to scrub the volume. that is all.

@markturansky
Copy link
Contributor Author

The basic implementation is in for HostPath but i'm working through bugs. Once it's good, I'll apply it to NFS.

@eparis
Copy link
Contributor

eparis commented May 26, 2015

Realistically this is a pretty key thing needed to make persistentVolumes useful, which are a 1.0 feature...

@eparis
Copy link
Contributor

eparis commented May 26, 2015

So @markturansky is basically full time on figuring this out right!

@markturansky
Copy link
Contributor Author

@eparis hopefully it won't be a long night. the pod and watch currently works, just need to get the pod scrub command correct. I'll need a good test, too.

@markturansky
Copy link
Contributor Author

@thockin e2e passes, but like the volumes e2e test (on which this was created), it requires privileged, so it won't run in the e2e suite by default.

Here is a full run of the recycler: https://gist.github.com/jsafrane/6dc167d752a70a570b7e

@markturansky
Copy link
Contributor Author

all green tests, too, FWIW.

@markturansky markturansky changed the title WIP: Allow reclamation of PersistentVolumes [do not merge]: Allow reclamation of PersistentVolumes May 29, 2015
@markturansky
Copy link
Contributor Author

This large PR is broken down into smaller, linked PRs. They should be reviewed and merged roughly in order, as each cherry-picks the the former.

@markturansky
Copy link
Contributor Author

Closing this PR. All commits accounted for in #9024.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

8 participants