-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Propose KEP to extend allowed DataSource entries
Propose extending DataSource field in PVCs to allow existing in namespace PVCs (Clones).
- Loading branch information
1 parent
c7ab566
commit 7a2a6b8
Showing
2 changed files
with
116 additions
and
1 deletion.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1 +1 @@ | ||
33 | ||
34 |
115 changes: 115 additions & 0 deletions
115
keps/sig-storage/0033-20181111-extend-datasource-field.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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] | ||