Replace MutatorConfig with CreatePVCPrimeFn that allows custom creation of a PVC

[pwschuurman]

What type of PR is this?

Uncomment only one /kind <> line, hit enter to put that in a new line, and remove leading whitespaces from that line:

/kind api-change
/kind bug
/kind cleanup
/kind design
/kind documentation
/kind failing-test
/kind feature
/kind flake

What this PR does / why we need it: This is a follow-up to #176. While useful, the previous approach of mutating a PVC prior to creation is not flexible enough for some providers. This enables some functionality for implementations to perform some custom steps prior to the create of a PVCPrime.

• Remove MutatorConfig to Volume Populator Controller
• Add a CreatePVCPrimeFn function to the ProviderFunctionConfig interface, to allow for custom PVC prime creation

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?:

Add optional CreatePVCPrimeFn to ProviderFunctionConfig to allow a custom PVC prime to be created for volume population. Remove the existing PvcPrimeMutator and MutatorConfig as CreatePVCPrimeFn provides the same functionality with more flexibility.

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pwschuurman
Once this PR has been reviewed and has the lgtm label, please assign saad-ali for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[pwschuurman]

/retest

[dannawang0221]

The only thing I'm not sure about is that there is a check of "" == pvcPrime.Spec.VolumeName[1]. Previous implementation was based on dynamic provisioning PV which will guarantee the check only get passed when the PVC' gets created. With CreatePVCPrimeFn if there is a static provisioned PV, is it possible that pvcPrime.Spec.VolumeName gets set, kubeClient.create.pvc' gets stuck for some reason, but the "" == pvcPrime.Spec.VolumeName pass?

[1]https://github.com/kubernetes-csi/lib-volume-populator/blob/master/populator-machinery/controller.go#L773

[pwschuurman]

That would be up to the client implementation. But, if the client uses static provisioning, the proper way to do this is to create a PV with a claimRef, and then a PVC without a volumeName set. The volume controller then binds the two, and sets volumeName.

[msau42]

It's a recommendation but not a requirement that users leave PVC.spec.volumeName unset.

[sunnylovestiramisu]

This flow probably should get added to the KEP or README later.

[pwschuurman]

/retest

[dannawang0221]

/lgtm

[pwschuurman]

/cc @sunnylovestiramisu
/assign @msau42

[sunnylovestiramisu]

/retest