Skip to content

Commit

Permalink
Propose KEP to extend allowed DataSource entries
Browse files Browse the repository at this point in the history
Propose extending DataSource field in PVCs to allow existing in
namespace PVCs (Clones).
  • Loading branch information
j-griffith committed Feb 21, 2019
1 parent c7ab566 commit 85d3354
Showing 1 changed file with 113 additions and 0 deletions.
113 changes: 113 additions & 0 deletions keps/sig-storage/20181111-extend-datasource-field.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
---
title: Extend usage of Volume DataSource field
authors:
- "@j-griffith"
owning-sig: sig-storage
participating-sigs:
- sig-architecture
reviewers:
- TBD
approvers:
- @saad-ali
- @childsb
editor: @j-griffith
creation-date: 2018-11-11
last-updated: 2018-11-11
status: provisional
see-also:
replaces:
superseded-by:
---

# Allow the use of the dataSource field for clones (existing PVCs)

## Table of Contents

* [Table of Contents](#table-of-contents)
* [Summary](#summary)
* [Motivation](#motivation)
* [Goals](#goals)
* [Non-Goals](#non-goals)
* [Proposal](#proposal)
* [User Stories [optional]](#user-stories-optional)
* [Story 1](#story-1)
* [Story 2](#story-2)
* [Implementation Details/Notes/Constraints [optional]](#implementation-detailsnotesconstraints-optional)
* [Risks and Mitigations](#risks-and-mitigations)
* [Graduation Criteria](#graduation-criteria)
* [Implementation History](#implementation-history)
* [Drawbacks [optional]](#drawbacks-optional)
* [Alternatives [optional]](#alternatives-optional)

[Tools for generating]: https://github.com/ekalinin/github-markdown-toc

## Summary

This KEP propposes removing the restrictions on the use of the PVC DataSource field. Currently API validation includes a check that only allows a value of VolumeSnapshot, however DataSource was intended to be a generic field that could be used for PVCs as well as external objects.

## Motivation

Features like Cloning are common in almost all modern day 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. In addition, there are external CRDs that can take advantage of this field.

### Goals

* Remove restrictions imposed by API validation on Object types permitted to be set on the DataSource field
* Enable ability to request a Clone of an existing PVC


### Non-Goals

* This does not verify the existence of the supplied Object Reference in the DataSource field
* This does not provide any sort of action from Kubernetes on the object provided in the DataSource field

## Proposal

Remove Validation checks against the PVC DataSource field, due to the validation checks currently in place it's not possible to specify anything other than Snapshots as a DataSource. Removing this check enables Cloning, as well as external object types.

```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: pvc-2
namespace: myns
spec:
capacity:
storage: 10Gi
dataSource:
kind: PersistentVolumeClaim
name: pvc-1
```
The result would be a new and independent PV/PVC (pvc-2) on the backend device that is a duplicate of the data that existed on pvc-1.
### User Stories [optional]
#### Story 1
As a cluster user, I want to be able to Clone a volume and run a different set of PODs/Applications against it
### Implementation Details/Notes/Constraints [optional]
The Kubernetes changes are minimal, and only require removal of the API Validation checks against allowed DataSource object types. In order to maintain the existing behaviors, a feature gate "AnyDataSource" is added, with a default enablement of False. The existing SnapshotDataSource checks will still continue to function as expected if this is not enabled, if this feature is enabled however, any correctly formed API Group Kind can be specified as a DataSource.
### Risks and Mitigations
The primary risk identified with this proposal is that a DataSource object could be provided that doesn't exist on the Cluster. In this case the PVC will be created but the user may be expecting some sort of action to take place based on the DataSource specification and that won't actually happen.
## Graduation Criteria
* 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.
## Implementation History
## Drawbacks [optional]
## Alternatives [optional]
Currently Cloning is implemented by most plugins through the use of annotations. This however leads to an inconsistent user experience, and the annotation usage is not only informal but can be a bit unwieldy to use.
Another alternative for a user that wants a Clone to take a Snapshot of a volume, and then create a volume from the Snapshot. This does not however utilize the enhancements of the backend device, and it's a manual process for the user.
## Infrastructure Needed [optional]

0 comments on commit 85d3354

Please sign in to comment.