Project

General

Profile

Actions

Feature #45309

open

[RBD] Clone a RBD volume from an existing volume

Added by Humble Chirammal almost 4 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
% Done:

0%

Source:
Development
Tags:
RBD, CLONE
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

To provide support for `clone` or `smart cloning` functionality in kubernetes/OCP, we need an interface or functionality which allows
to create a RBD volume from an existing volume.

Afaict, its not possible to create a volume from an existing volume by a single command/interface, rather the available functionality is the creation of a volume from exising snapshot and not directly from the volume. The workaround/hack would be to achieve this functionality here is creating an intermedia snapshot and then create a volume from the intermediate snapshot , then, upon completion of the new volume creation, delete the intermediate snap. However the cloning functionality expects an operation that allows a new volume creation directly from an existing volume.

More details about this clone functionality can be found here:

https://kubernetes.io/docs/concepts/storage/volume-pvc-datasource/

To give some more context about 'cloning' functionality:

There are mainly 2 operations to create a new PVC ( empty volume creation is omitted here to avoid confusion).

1) From the snapshot 2) From an existing PVC

In the first case the `dataSource` field in the PVC will be referring to "Snapshot" and in the second case the data source will be referring to an `existing PVC`. The latter is "referred" as CLONE in kube. `A Clone is defined as a duplicate of an existing Kubernetes Volume that can be consumed as any standard Volume would be. The only difference is that upon provisioning, rather than creating a “new” empty Volume, the back end device creates an exact duplicate of the specified Volume.`.

Regarding consistency: There wont be any inflight I/Os on the source PVC, so we are good to take a path of source copy directly to new volume

The data source can be defined in the second case like this:

```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: clone-of-pvc-1
namespace: myns
spec:
accessModes:
- ReadWriteOnce
storageClassName: cloning
resources:
requests:
storage: 5Gi
dataSource:
kind: PersistentVolumeClaim
name: pvc-1
```

Actions #1

Updated by Jason Dillaman almost 4 years ago

Humble Chirammal wrote:

To provide support for `clone` or `smart cloning` functionality in kubernetes/OCP, we need an interface or functionality which allows
to create a RBD volume from an existing volume.

That interface already exists out-of-the-box in the rbd CLI and in the librbd API.

Afaict, its not possible to create a volume from an existing volume by a single command/interface, rather the available functionality is the creation of a volume from exising snapshot and not directly from the volume. The workaround/hack would be to achieve this functionality here is creating an intermedia snapshot and then create a volume from the intermediate snapshot , then, upon completion of the new volume creation, delete the intermediate snap. However the cloning functionality expects an operation that allows a new volume creation directly from an existing volume.

As per the discussed and agreed upon design for RBD CSI cloning, the above is exactly the goal. That means that k8s clones behave exactly like k8s snapshot+create volume from snapshot and therefore share code paths and logic.

Actions #2

Updated by Madhu Rajanna almost 4 years ago

Jason Dillaman wrote:

Humble Chirammal wrote:

To provide support for `clone` or `smart cloning` functionality in kubernetes/OCP, we need an interface or functionality which allows
to create a RBD volume from an existing volume.

That interface already exists out-of-the-box in the rbd CLI and in the librbd API.

@Jason Borden do we have a rbd CLI to clone from rbd image?

Afaict, its not possible to create a volume from an existing volume by a single command/interface, rather the available functionality is the creation of a volume from exising snapshot and not directly from the volume. The workaround/hack would be to achieve this functionality here is creating an intermedia snapshot and then create a volume from the intermediate snapshot , then, upon completion of the new volume creation, delete the intermediate snap. However the cloning functionality expects an operation that allows a new volume creation directly from an existing volume.

As per the discussed and agreed upon design for RBD CSI cloning, the above is exactly the goal. That means that k8s clones behave exactly like k8s snapshot+create volume from snapshot and therefore share code paths and logic.

Yes, this is what we had discussed in the meeting. as we didn't have a direct command to clone from an image we went ahead with this approach(still under implementation) if we can get a direct command from rbd to clone from an image that will be really helpful for CSI

Actions

Also available in: Atom PDF