Propose KEP to extend allowed DataSource entries to include PVC #642

j-griffith · 2018-12-03T17:44:42Z

Propose extending DataSource field in PVCs to allow existing in
namespace PVCs (Clones) and external data population CRDs (Populators).

thockin · 2018-12-04T04:57:04Z

@jingxu97 and @saad-ali showed me some of this last week. I think cloning a disk is legitimate and self-evident use-case. Focus on that.

The idea of software initializers is interesting, but can mostly be solved with sidecars, right? Sidecars have the distinct advantage of being active - they can resync if you need, which these initializers can never do. I'm not super inclined to go out of our way to support initializers that could just be sidecars. If they happen to fall out of the clone design, I won't go out of my way to break them, but I'd need to be convinced to lift a finger to support them.

j-griffith · 2018-12-04T05:26:19Z

@thockin thanks for the feedback. Fore sure, the initializer portion could be a side-car; the appealing thing about the DataSource in this case for me was simply a way to formally/consistently express that, and follow the pattern that the Snapshot Controller uses (and well, because it was there).

I like the side car idea, I'll have to research a bit to understand how I would express that though. Regardless, I'll focus on Cloning for now.

j-griffith · 2018-12-13T22:40:51Z

@thockin I updated the PR to remove the populator component and just focus on the cloning use case. I'll follow up with a single proposal for the init/populator use cases to keep things focused.

mattfarina

Quick process note, this is an API change which means it needs to go through the API review process.

Has this been discussed at SIG Storage, yet?

mattfarina · 2019-01-03T16:23:19Z

keps/sig-storage/0033-20181111-extend-datasource-field.md

+reviewers:
+  - TBD
+approvers:
+  - TBD


Can we please have approvers listed? I think this would be the SIG Storage chairs/tech leads but may review this guidance later.

mattfarina · 2019-01-03T16:27:13Z

keps/sig-storage/0033-20181111-extend-datasource-field.md

+
+The external risk to adding PVC as a valid DataSource is minimal, there are also minimal risks or impacts associated with the addition of the new allowed type.  The bulk of the needed changes needed are in the Provisioner and of course the implementation via the CSI plugins themeselves.
+
+## Graduation Criteria


The template for graduation criteria notes:

How will we know that this has succeeded? Gathering user feedback is crucial for building high quality experiences and SIGs have the important responsibility of setting milestones for stability and completeness. Hopefully the content previously contained in umbrella issues will be tracked in the Graduation Criteria section.

Aside from the basic requirements which are things being implemented, how can we know this GA quality vs beta quality?

Added additional wording, thanks!

j-griffith · 2019-01-07T18:23:15Z

@mattfarina

Quick process note, this is an API change which means it needs to go through the API review process.
Has this been discussed at SIG Storage, yet?

Yes, we've discussed this at length in sig-storage

mattfarina · 2019-01-15T15:27:27Z

@j-griffith @saad-ali @childsb What was the output of the conversation in SIG Storage?

justaugustus

Please remove any references to NEXT_KEP_NUMBER and rename the KEP to just be the draft date and KEP title.
KEP numbers will be obsolete once #703 merges.

justaugustus · 2019-01-26T11:18:44Z

/uncc

j-griffith · 2019-02-08T16:26:05Z

@thockin I've reworked this a bit based on discussions in sig-storage yesterday and as per recommendations from @saad-ali

The proposal removes any reference to "populators", and instead just proposes removing API validation checks against the PVC DataSource 1 (which was apparently the original intent of the field).

Currently works with old style provisioners requires 2 to work with CSI provisioners

keps/sig-storage/20181111-extend-datasource-field.md

saad-ali · 2019-02-23T01:34:05Z

We should finalize on the end to end plan for how generic populators will work before relaxing the validation. Specifically we should finalize on how PVCs will be safely mounted to populators (but no other workloads) until the populator is done.

j-griffith · 2019-02-23T14:56:29Z

@saad-ali

Specifically we should finalize on how PVCs will be safely mounted to populators (but no other workloads) until the populator is done.

WRT to this KEP I disagree, I specifically removed any mention of Populators, I just want to enable PVC's for cloning at this point.

Additionally; why wouldn't we use the same taint mechanism we've agreed upon for snapshots? I've somewhat given up on Populators (at least for the short term) but I still think that we should get Clones working. After all it's in the CSI Spec, It doesn't introduce any risk that I can think of, and it's a pretty common back end storage feature.

I'd just file a bug and add only PVC, but I can't do that because of the API validation checks without a KEP.

rollandf · 2019-02-24T10:02:19Z

LGTM

Propose extending DataSource field in PVCs to allow existing in namespace PVCs (Clones).

j-griffith · 2019-02-25T20:32:02Z

@saad-ali @thockin Should be explicitly Clone only now and put the other things in the "non goals" category explicitly, thanks!

keps/sig-storage/20181111-extend-datasource-field.md

saad-ali · 2019-02-26T19:37:28Z

keps/sig-storage/20181111-extend-datasource-field.md

+
+## Motivation
+
+Features like Cloning are common in most storage devices, not only is the capability available on most devices, it's also frequently used in various use cases whether it be for duplicating data or to use as a disaster recovery method.


Cloning is a common feature on most storage devices. It is used for duplicating data and, in some cases, as a disaster recovery method.

saad-ali · 2019-02-26T19:46:44Z

keps/sig-storage/20181111-extend-datasource-field.md

+#### Story 4
+As a cluster admin or user, I want to be able to provide the equivalent of data templates to users in the Cluster to ensure consistent and secure data sets
+
+### Implementation Details/Notes/Constraints [optional]


Let's specify that this functionality will only be added for CSI. In-tree volume plugins and Flex drivers will not get this functionality.

This could be added in non-goals or constraints.

I went ahead and added it non-goals, and also put a note in the Implementation Details/Notes section to just stress the point. Thanks

saad-ali · 2019-02-26T19:48:44Z

keps/sig-storage/20181111-extend-datasource-field.md

+
+### Risks and Mitigations
+
+The primary risk of this feature is a Plugin that doesn't handle Cloning in a safe way for running applications.  It's assumed that the responsibility for reporting Clone Capabilities in this case is up to the Plugin, and if a Plugin is reporting Clone support that implies that they can in fact Clone Volumes without disrupting or corrupting users that may be actively using the specified source volume.


nit: plugin -> CSI Driver

cool, added csi driver and csi plugin so there shouldn't be any question going forward

saad-ali · 2019-02-26T19:51:49Z

keps/sig-storage/20181111-extend-datasource-field.md

+* API changes allowing specification of a PVC as a valid DataSource in a new PVC spec
+* Implementation of the PVC DataSource in the CSI external provisioner
+
+The API can be immediately promoted to Beta, as it's just an extension of the existing DataSource field.  There are no implementations or changes needed in Kubernetes other than accepting Object Types in the DataSource field.  This should be promoted to GA after a release assuming no major issues or changes were needed/required during the Beta stage.


Currently the PVC Datasource field is gated by the VolumeSnapshotDataSource alpha feature gate.
Going forward it makes sense to add additional feature gates for each type of datasource, e.g. cloning.
But I'm not sure that cloning should get to skip alpha?

Sure, I can change that. It just seemed that since all we were doing was adding a feature gate for PVC to be specified in DataSource that it shouldn't take a full alpha and beta to be comfortable with it. I'll remove the "skip to beta" verbage and we can go from there. If we feel more comfortable with an alpha then beta release that's great.

saad-ali · 2019-02-26T19:52:43Z

keps/sig-storage/20181111-extend-datasource-field.md

+
+## Alternatives [optional]
+
+Snapshots and Clones are very closely related, in fact some back ends my implement cloning via snapshots (take a snapshot, create a volume from that snapshot).  Users can do this currently with Kubernetes, and it's good, however some back ends have specific clone functionality that is much more efficient, and even for those that don't, this proposal provides a simple one-step process for a user to request a Clone of a volume.


Should we recommend against storage systems implementing it this way? I.e. do we want to provide storage systems constraints on how and when to implement clone?

I'm not sure honeslty; I used this as an alternative example because it came up :) The only reason I could see any storage provider using this as a clone implementation is because they don't offer cloning on their backend; in which case it's not ideal, but "ok"; they still eliminate the multi step process for the end user.

I think honestly I should've reworded this completely and left out the implementation part; and just pointed out that it's a possible alternative to get the clone behavior without this KEP.

IMO, the clone api should be a common/single interface exposed to the user and storage provider/driver can do it by their choice in the backend. ie from snapshot or directly by their clone api.

j-griffith · 2019-03-19T13:01:50Z

@saad-ali Now that we're heading into a new release and I've removed all wording regarding populators and just discuss Clone only; any chance we can get this approved/merged so I can get the implementations done here and in the provisioner hopefully for this next release?

j-griffith · 2019-03-19T13:03:02Z

@justaugustus I squashed your request for changes so can't really fix things up; any chance I could get you to take a look and either update or remove your review change request?

Dismissing as KEP number is removed.

justaugustus · 2019-03-24T12:01:44Z

/uncc

j-griffith · 2019-04-05T17:04:28Z

@saad-ali @thockin Any chance I could get either of you to comment on the updates and get this moving along again?

saad-ali

/lgtm
/approve

We can implement alpha of this in Q2 for Kubernetes 1.15.

k8s-ci-robot · 2019-04-09T22:12:32Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: j-griffith, saad-ali

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:

~~keps/sig-storage/OWNERS~~ [saad-ali]

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

k8s-ci-robot added the cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. label Dec 3, 2018

k8s-ci-robot requested review from calebamiles and justaugustus December 3, 2018 17:44

j-griffith force-pushed the extend_volume_source_kep branch from fb0ad4f to 7a2a6b8 Compare December 13, 2018 22:38

j-griffith changed the title ~~Propose KEP to extend allowed DataSource entries~~ Propose KEP to extend allowed DataSource entries to include PVC Dec 13, 2018

mattfarina reviewed Jan 3, 2019

View reviewed changes

j-griffith mentioned this pull request Jan 7, 2019

Propose KEP to transfer PVC between namespaces #643

Closed

j-griffith force-pushed the extend_volume_source_kep branch from 7a2a6b8 to 5ca8f61 Compare January 7, 2019 18:30

justaugustus previously requested changes Jan 20, 2019

View reviewed changes

j-griffith force-pushed the extend_volume_source_kep branch from 5ca8f61 to aa0e1f8 Compare January 25, 2019 23:57

k8s-ci-robot added the do-not-merge/blocked-paths Indicates that a PR should not merge because it touches files in blocked paths. label Jan 25, 2019

j-griffith force-pushed the extend_volume_source_kep branch from aa0e1f8 to f7e14e8 Compare January 26, 2019 01:25

k8s-ci-robot removed the do-not-merge/blocked-paths Indicates that a PR should not merge because it touches files in blocked paths. label Jan 26, 2019

j-griffith mentioned this pull request Jan 29, 2019

Extend allowed DataSources kubernetes-csi/external-provisioner#220

Merged

j-griffith force-pushed the extend_volume_source_kep branch from f7e14e8 to 8ba2a21 Compare February 8, 2019 16:21

msau42 mentioned this pull request Feb 15, 2019

REQUEST: New membership for j-griffith kubernetes/org#495

Closed

6 tasks

rollandf reviewed Feb 19, 2019

View reviewed changes

keps/sig-storage/20181111-extend-datasource-field.md Outdated Show resolved Hide resolved

keps/sig-storage/20181111-extend-datasource-field.md Outdated Show resolved Hide resolved

keps/sig-storage/20181111-extend-datasource-field.md Outdated Show resolved Hide resolved

j-griffith force-pushed the extend_volume_source_kep branch from 8ba2a21 to f3f1944 Compare February 21, 2019 20:27

j-griffith force-pushed the extend_volume_source_kep branch from f3f1944 to 85d3354 Compare February 21, 2019 20:49

Propose KEP to allowed PVC DataSource (Clone)

a36f891

Propose extending DataSource field in PVCs to allow existing in namespace PVCs (Clones).

j-griffith force-pushed the extend_volume_source_kep branch from 85d3354 to a36f891 Compare February 25, 2019 20:18

saad-ali reviewed Feb 26, 2019

View reviewed changes

review-updates

d222ac7

j-griffith mentioned this pull request Mar 13, 2019

[DNM] [WIP] Add support for smart cloning ceph/ceph-csi#248

Closed

k8s-ci-robot assigned saad-ali Apr 9, 2019

saad-ali approved these changes Apr 9, 2019

View reviewed changes

k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Apr 9, 2019

k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 9, 2019

k8s-ci-robot merged commit 8a08ffe into kubernetes:master Apr 9, 2019

j-griffith mentioned this pull request Apr 11, 2019

Enable PVC as DataSource for PVC creation kubernetes/kubernetes#76459

Closed

j-griffith mentioned this pull request Apr 22, 2019

Cleaned enable pvc datasource kubernetes/kubernetes#76913

Merged

justaugustus removed the sig/pm label Apr 19, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Propose KEP to extend allowed DataSource entries to include PVC #642

Propose KEP to extend allowed DataSource entries to include PVC #642

j-griffith commented Dec 3, 2018

thockin commented Dec 4, 2018

j-griffith commented Dec 4, 2018

j-griffith commented Dec 13, 2018

mattfarina left a comment

mattfarina Jan 3, 2019

j-griffith Jan 7, 2019

mattfarina Jan 3, 2019

j-griffith Jan 7, 2019

j-griffith commented Jan 7, 2019

mattfarina commented Jan 15, 2019

justaugustus left a comment

justaugustus commented Jan 26, 2019

j-griffith commented Feb 8, 2019 •

edited

Loading

saad-ali commented Feb 23, 2019

j-griffith commented Feb 23, 2019

rollandf commented Feb 24, 2019

j-griffith commented Feb 25, 2019

saad-ali Feb 26, 2019

saad-ali Feb 26, 2019

saad-ali Feb 26, 2019

j-griffith Mar 1, 2019

saad-ali Feb 26, 2019

j-griffith Mar 1, 2019

saad-ali Feb 26, 2019

j-griffith Mar 1, 2019 •

edited

Loading

saad-ali Feb 26, 2019

j-griffith Mar 1, 2019 •

edited

Loading

humblec Mar 19, 2019

j-griffith commented Mar 19, 2019

j-griffith commented Mar 19, 2019

justaugustus commented Mar 24, 2019

j-griffith commented Apr 5, 2019

saad-ali left a comment

k8s-ci-robot commented Apr 9, 2019


		The external risk to adding PVC as a valid DataSource is minimal, there are also minimal risks or impacts associated with the addition of the new allowed type. The bulk of the needed changes needed are in the Provisioner and of course the implementation via the CSI plugins themeselves.

		## Graduation Criteria


		## Motivation

		Features like Cloning are common in most storage devices, not only is the capability available on most devices, it's also frequently used in various use cases whether it be for duplicating data or to use as a disaster recovery method.


		### Risks and Mitigations

		The primary risk of this feature is a Plugin that doesn't handle Cloning in a safe way for running applications. It's assumed that the responsibility for reporting Clone Capabilities in this case is up to the Plugin, and if a Plugin is reporting Clone support that implies that they can in fact Clone Volumes without disrupting or corrupting users that may be actively using the specified source volume.


		## Alternatives [optional]

		Snapshots and Clones are very closely related, in fact some back ends my implement cloning via snapshots (take a snapshot, create a volume from that snapshot). Users can do this currently with Kubernetes, and it's good, however some back ends have specific clone functionality that is much more efficient, and even for those that don't, this proposal provides a simple one-step process for a user to request a Clone of a volume.

Propose KEP to extend allowed DataSource entries to include PVC #642

Propose KEP to extend allowed DataSource entries to include PVC #642

Conversation

j-griffith commented Dec 3, 2018

thockin commented Dec 4, 2018

j-griffith commented Dec 4, 2018

j-griffith commented Dec 13, 2018

mattfarina left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j-griffith commented Jan 7, 2019

mattfarina commented Jan 15, 2019

justaugustus left a comment

Choose a reason for hiding this comment

justaugustus commented Jan 26, 2019

j-griffith commented Feb 8, 2019 • edited Loading

saad-ali commented Feb 23, 2019

j-griffith commented Feb 23, 2019

rollandf commented Feb 24, 2019

j-griffith commented Feb 25, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j-griffith Mar 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j-griffith Mar 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

j-griffith commented Mar 19, 2019

j-griffith commented Mar 19, 2019

justaugustus commented Mar 24, 2019

j-griffith commented Apr 5, 2019

saad-ali left a comment

Choose a reason for hiding this comment

k8s-ci-robot commented Apr 9, 2019

j-griffith commented Feb 8, 2019 •

edited

Loading

j-griffith Mar 1, 2019 •

edited

Loading

j-griffith Mar 1, 2019 •

edited

Loading