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 Dec 13, 2018
1 parent c7ab566 commit 7a2a6b8
Show file tree
Hide file tree
Showing 2 changed files with 116 additions and 1 deletion.
2 changes: 1 addition & 1 deletion keps/NEXT_KEP_NUMBER
Original file line number Diff line number Diff line change
@@ -1 +1 @@
33
34
115 changes: 115 additions & 0 deletions keps/sig-storage/0033-20181111-extend-datasource-field.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,115 @@
---
kep-number: 33
title: Extend usage of Volume DataSource field
authors:
- "@j-griffith"
owning-sig: sig-storage
participating-sigs:
- sig-architecture
reviewers:
- TBD
approvers:
- TBD
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 proposes expanding the allowed uses of the DataSource field for PVC creation in Kubernetes to include PVCs. Currently we allow Snapshots, which is used by the CSI provisioner to enable creating volumes from snapshots. In addition to Snaphsots however, the CSI Spec includes the ability to create "clones" (creating a new duplicate volume from an existing volume), in which case the DataSource is an existing Volume on the backend device.

## 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.

### Goals

* Extend the existing DataSource field for PVCs to allow specifying existing PVCs on the system


### Non-Goals

* The actual clone logic is NOT proposed to be implemented in Kubernetes. This proposal simply proposes the ability to communicate to the CSI Provisioner that we want to perform a clone, it's up to the CSI Plugin/Backend device to handle the implementation.

## Proposal

Modify the checks on the dataSource field to allow:
1. Existing PVCs in the users namespace (clones).

Tihs proposal is just to allow communication of intent, there's no implementation proposed in Kubernetes. The Clone case is fairly straight forward given that the CSI spec already includes volumes as a data source and has a cloning capability that plugins are required to report:

```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 changes being proposed to Kubernetes to enable Volume cloning are minimal. After adding PVCs as an accepted DataSource type, the remaining work is limited to implementation work in the CSI provisioner. Checks for capabilities can be performed in the CSI Provisioner:
* Storage classes match (src and destination)
* The storage class capabilities report support for cloning
### Risks and Mitigations
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
There are two basic requirements required for graduation:
1. Support for use of PVC as a DataSource type in the Create PVC object
2. Cloning implementation in the CSI external provisioner
## 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 unwieldly to use.
## Infrastructure Needed [optional]

0 comments on commit 7a2a6b8

Please sign in to comment.