technofab/zfs-localpv
1
0
Fork 0
mirror of https://github.com/TECHNOFAB11/zfs-localpv.git synced 2025-12-11 22:10:11 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
zfs-localpv/deploy/zfs-operator.yaml

2102 lines
107 KiB
YAML
Raw Normal View History

feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
# This manifest is autogenerated via `make manifests` command
# Do the modification to the zfs-driver.yaml in directory deploy/yamls/
# and then run `make manifests` command
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
# This manifest deploys the OpenEBS ZFS control plane components,
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
# with associated CRs & RBAC rules.
# Create the OpenEBS namespace
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
# This is the default namespace where the ZFS driver will create all
# its resources. If we want to change it to use a different namespace
# modify this to create the new namespace and also modify the OPENEBS_NAMESPACE
# env for the ZFS Driver's controller and agent deployments.
# please note that this should be changed while initial setup, once ZFS Driver
# is deployed with a namespace, we should never modify it as old resources will
# not be available under the new namespace and ZFS Driver looks for all the resources
# in the OPENEBS_NAMESPACE namespace passed as an env.
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
apiVersion: v1
kind: Namespace
metadata:
name: openebs
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
##############################################
########### ############
########### ZFSVolume CRD ############
########### ############
##############################################
# ZFSVolume CRD is autogenerated via `make manifests` command.
# Do the modification in the code and run the `make manifests` command
# to generate the CRD definition
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
annotations:
controller-gen.kubebuilder.io/version: v0.2.8
creationTimestamp: null
refactor(crd): move CR from openebs.io to zfs.openebs.io (#70) Changed the group name from openebs.io to zfs.openebs.io. Now ZFS Volume CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfszvolumes.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: zfsvolumes singular: zfsvolume kind:ZFSVolume shortNames: - zfsvol - zv ``` Snapshot CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfssnapshots.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: fssnapshots singular: zfssnapshot kind: ZFSSnapshot shortNames: - zfssnapshot - zfssnap ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-30 22:12:34 +05:30
name: zfsvolumes.zfs.openebs.io
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
spec:
additionalPrinterColumns:
feat(ZFSPV): volume count based scheduler for ZFSPV (#8) This is an initial scheduler implementation for ZFS Local PV. * adding scheduler as a configurable option * adding volumeWeightedScheduler as scheduling logic The volumeWeightedScheduler will go through all the nodes as per topology information and it will pick the node which has less volume provisioned in the given pool. lets say there are 2 nodes node1 and node2 with below pool configuration :- ``` node1 | |-----> pool1 | | | |------> pvc1 | |------> pvc2 |-----> pool2 |------> pvc3 node2 | |-----> pool1 | | | |------> pvc4 |-----> pool2 |------> pvc5 |------> pvc6 ``` So if application is using pool1 as shown in the below storage class, then ZFS driver will schedule it on node2 as it has one volume as compared to node1 which has 2 volumes in pool1. ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: openebs-zfspv provisioner: zfs.csi.openebs.io parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "pool1" ``` So if application is using pool2 as shown in the below storage class, then ZFS driver will schedule it on node1 as it has one volume only as compared node2 which has 2 volumes in pool2. ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: openebs-zfspv provisioner: zfs.csi.openebs.io parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "pool2" ``` In case of same number of volumes on all the nodes for the given pool, it can pick any node and schedule the PV on that. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-06 21:20:49 +05:30
- JSONPath: .spec.poolName
description: ZFS Pool where the volume is created
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
name: ZPool
feat(ZFSPV): volume count based scheduler for ZFSPV (#8) This is an initial scheduler implementation for ZFS Local PV. * adding scheduler as a configurable option * adding volumeWeightedScheduler as scheduling logic The volumeWeightedScheduler will go through all the nodes as per topology information and it will pick the node which has less volume provisioned in the given pool. lets say there are 2 nodes node1 and node2 with below pool configuration :- ``` node1 | |-----> pool1 | | | |------> pvc1 | |------> pvc2 |-----> pool2 |------> pvc3 node2 | |-----> pool1 | | | |------> pvc4 |-----> pool2 |------> pvc5 |------> pvc6 ``` So if application is using pool1 as shown in the below storage class, then ZFS driver will schedule it on node2 as it has one volume as compared to node1 which has 2 volumes in pool1. ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: openebs-zfspv provisioner: zfs.csi.openebs.io parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "pool1" ``` So if application is using pool2 as shown in the below storage class, then ZFS driver will schedule it on node1 as it has one volume only as compared node2 which has 2 volumes in pool2. ```yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: openebs-zfspv provisioner: zfs.csi.openebs.io parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "pool2" ``` In case of same number of volumes on all the nodes for the given pool, it can pick any node and schedule the PV on that. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-06 21:20:49 +05:30
type: string
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- JSONPath: .spec.ownerNodeID
description: Node where the volume is created
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
name: Node
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
type: string
- JSONPath: .spec.capacity
description: Size of the volume
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
name: Size
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
type: string
feat(zfspv): pvc should be bound only if volume has been created. The controller does not check whether the volume has been created or not and return successful. Which in turn binds the pvc to the pv. The PVC should not bound until corresponding zfs volume has been created. Now controller will check the ZFSVolume CR state to be "Ready" before returning successful. The CSI will retry the CreateVolume request when it will get a error reply and when the ZFS node agent creates the ZFS volume and sets the ZFSVolume CR state to be "Ready", the controller will return success for the CreateVolume Request and then PVC will be bound. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-18 16:30:20 +05:30
- JSONPath: .status.state
description: Status of the volume
name: Status
type: string
feat(ZFSPV): adding support for applications to create "zfs" flesystem (#15) Application can now create a storageclass to create zfs filesystem apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv5 allowVolumeExpansion: true parameters: blocksize: "4k" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ZFSPV was supporting ext2/3/4 and xfs filesystem only which adds one extra filesystem layer on top of ZFS filesystem. So now we can driectly write to the ZFS filesystem and get the optimal performance by directly creating ZFS filesystem for storage. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-21 19:00:15 +05:30
- JSONPath: .spec.fsType
description: filesystem created on the volume
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
name: Filesystem
feat(ZFSPV): adding support for applications to create "zfs" flesystem (#15) Application can now create a storageclass to create zfs filesystem apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv5 allowVolumeExpansion: true parameters: blocksize: "4k" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ZFSPV was supporting ext2/3/4 and xfs filesystem only which adds one extra filesystem layer on top of ZFS filesystem. So now we can driectly write to the ZFS filesystem and get the optimal performance by directly creating ZFS filesystem for storage. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-21 19:00:15 +05:30
type: string
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
- JSONPath: .metadata.creationTimestamp
feat(print): removing unnecessary printer columns Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-21 13:54:22 +05:30
description: Age of the volume
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
name: Age
type: date
group: zfs.openebs.io
names:
kind: ZFSVolume
listKind: ZFSVolumeList
plural: zfsvolumes
shortNames:
- zfsvol
- zv
singular: zfsvolume
preserveUnknownFields: false
scope: Namespaced
subresources: {}
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
version: v1
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
versions:
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
- name: v1
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
schema:
openAPIV3Schema:
description: ZFSVolume represents a ZFS based volume
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: VolumeInfo defines ZFS volume parameters for all modes in
which ZFS volumes can be created like - ZFS volume with filesystem,
ZFS Volume exposed as zfs or ZFS volume exposed as raw block device.
Some of the parameters can be only set during creation time (as specified
in the details of the parameter), and a few are editable. In case of
Cloned volumes, the parameters are assigned the same values as the source
volume.
properties:
capacity:
description: Capacity of the volume
minLength: 1
type: string
compression:
description: 'Compression specifies the block-level compression algorithm
to be applied to the ZFS Volume. The value "on" indicates ZFS to
use the default compression algorithm. The default compression algorithm
used by ZFS will be either lzjb or, if the lz4_compress feature
is enabled, lz4. Compression property can be edited after the volume
has been created. The change will only be applied to the newly-written
data. For instance, if the Volume was created with "off" and the
next day the compression was modified to "on", the data written
prior to setting "on" will not be compressed. Default Value: off.'
pattern: ^(on|off|lzjb|gzip|gzip-[1-9]|zle|lz4)$
type: string
dedup:
description: 'Deduplication is the process for removing redundant
data at the block level, reducing the total amount of data stored.
If a file system has the dedup property enabled, duplicate data
blocks are removed synchronously. The result is that only unique
data is stored and common components are shared among files. Deduplication
can consume significant processing power (CPU) and memory as well
as generate additional disk IO. Before creating a pool with deduplication
enabled, ensure that you have planned your hardware requirements
appropriately and implemented appropriate recovery practices, such
as regular backups. As an alternative to deduplication consider
using compression=lz4, as a less resource-intensive alternative.
should be enabled on the zvol. Dedup property can be edited after
the volume has been created. Default Value: off.'
enum:
- "on"
- "off"
type: string
encryption:
description: 'Enabling the encryption feature allows for the creation
of encrypted filesystems and volumes. ZFS will encrypt file and
zvol data, file attributes, ACLs, permission bits, directory listings,
FUID mappings, and userused / groupused data. ZFS will not encrypt
metadata related to the pool structure, including dataset and snapshot
names, dataset hierarchy, properties, file size, file holes, and
deduplication tables (though the deduplicated data itself is encrypted).
Default Value: off.'
pattern: ^(on|off|aes-128-[c,g]cm|aes-192-[c,g]cm|aes-256-[c,g]cm)$
type: string
fsType:
description: 'FsType specifies filesystem type for the zfs volume/dataset.
If FsType is provided as "zfs", then the driver will create a ZFS
dataset, formatting is not required as underlying filesystem is
ZFS anyway. If FsType is ext2, ext3, ext4 or xfs, then the driver
will create a ZVOL and format the volume accordingly. FsType can
not be modified once volume has been provisioned. Default Value:
ext4.'
type: string
keyformat:
description: KeyFormat specifies format of the encryption key The
supported KeyFormats are passphrase, raw, hex.
enum:
- passphrase
- raw
- hex
type: string
keylocation:
description: KeyLocation is the location of key for the encryption
type: string
ownerNodeID:
description: OwnerNodeID is the Node ID where the ZPOOL is running
which is where the volume has been provisioned. OwnerNodeID can
not be edited after the volume has been provisioned.
minLength: 1
type: string
poolName:
description: poolName specifies the name of the pool where the volume
has been created. PoolName can not be edited after the volume has
been provisioned.
minLength: 1
type: string
recordsize:
description: 'Specifies a suggested block size for files in the file
system. The size specified must be a power of two greater than or
equal to 512 and less than or equal to 128 Kbytes. RecordSize property
can be edited after the volume has been created. Changing the file
system''s recordsize affects only files created afterward; existing
files are unaffected. Default Value: 128k.'
minLength: 1
type: string
shared:
description: Shared specifies whether the volume can be shared among
multiple pods. If it is not set to "yes", then the ZFS-LocalPV Driver
will not allow the volumes to be mounted by more than one pods.
enum:
- "yes"
- "no"
type: string
snapname:
description: SnapName specifies the name of the snapshot where the
volume has been cloned from. Snapname can not be edited after the
volume has been provisioned.
type: string
thinProvision:
description: 'ThinProvision describes whether space reservation for
the source volume is required or not. The value "yes" indicates
that volume should be thin provisioned and "no" means thick provisioning
of the volume. If thinProvision is set to "yes" then volume can
be provisioned even if the ZPOOL does not have the enough capacity.
If thinProvision is set to "no" then volume can be provisioned only
if the ZPOOL has enough capacity and capacity required by volume
can be reserved. ThinProvision can not be modified once volume has
been provisioned. Default Value: no.'
enum:
- "yes"
- "no"
type: string
volblocksize:
description: 'VolBlockSize specifies the block size for the zvol.
The volsize can only be set to a multiple of volblocksize, and cannot
be zero. VolBlockSize can not be edited after the volume has been
provisioned. Default Value: 8k.'
minLength: 1
type: string
volumeType:
description: volumeType determines whether the volume is of type "DATASET"
or "ZVOL". If fstype provided in the storageclass is "zfs", a volume
of type dataset will be created. If "ext4", "ext3", "ext2" or "xfs"
is mentioned as fstype in the storageclass, then a volume of type
zvol will be created, which will be further formatted as the fstype
provided in the storageclass. VolumeType can not be modified once
volume has been provisioned.
enum:
- ZVOL
- DATASET
type: string
required:
- capacity
- ownerNodeID
- poolName
- volumeType
type: object
status:
feat(zfspv) Add golint check to travis (#175) Signed-off-by: vaniisgh <vanisingh@live.co.uk>
2020-07-07 18:21:02 +05:30
description: VolStatus string that specifies the current state of the
volume provisioning request.
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
properties:
state:
description: State specifies the current state of the volume provisioning
request. The state "Pending" means that the volume creation request
has not processed yet. The state "Ready" means that the volume has
been created and it is ready for the use.
enum:
- Pending
- Ready
type: string
type: object
required:
- spec
type: object
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
served: true
storage: true
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
- name: v1alpha1
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
schema:
openAPIV3Schema:
description: ZFSVolume represents a ZFS based volume
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: VolumeInfo defines ZFS volume parameters for all modes in
which ZFS volumes can be created like - ZFS volume with filesystem,
ZFS Volume exposed as zfs or ZFS volume exposed as raw block device.
Some of the parameters can be only set during creation time (as specified
in the details of the parameter), and a few are editable. In case of
Cloned volumes, the parameters are assigned the same values as the source
volume.
properties:
capacity:
description: Capacity of the volume
minLength: 1
type: string
compression:
description: 'Compression specifies the block-level compression algorithm
to be applied to the ZFS Volume. The value "on" indicates ZFS to
use the default compression algorithm. The default compression algorithm
used by ZFS will be either lzjb or, if the lz4_compress feature
is enabled, lz4. Compression property can be edited after the volume
has been created. The change will only be applied to the newly-written
data. For instance, if the Volume was created with "off" and the
next day the compression was modified to "on", the data written
prior to setting "on" will not be compressed. Default Value: off.'
pattern: ^(on|off|lzjb|gzip|gzip-[1-9]|zle|lz4)$
type: string
dedup:
description: 'Deduplication is the process for removing redundant
data at the block level, reducing the total amount of data stored.
If a file system has the dedup property enabled, duplicate data
blocks are removed synchronously. The result is that only unique
data is stored and common components are shared among files. Deduplication
can consume significant processing power (CPU) and memory as well
as generate additional disk IO. Before creating a pool with deduplication
enabled, ensure that you have planned your hardware requirements
appropriately and implemented appropriate recovery practices, such
as regular backups. As an alternative to deduplication consider
using compression=lz4, as a less resource-intensive alternative.
should be enabled on the zvol. Dedup property can be edited after
the volume has been created. Default Value: off.'
enum:
- "on"
- "off"
type: string
encryption:
description: 'Enabling the encryption feature allows for the creation
of encrypted filesystems and volumes. ZFS will encrypt file and
zvol data, file attributes, ACLs, permission bits, directory listings,
FUID mappings, and userused / groupused data. ZFS will not encrypt
metadata related to the pool structure, including dataset and snapshot
names, dataset hierarchy, properties, file size, file holes, and
deduplication tables (though the deduplicated data itself is encrypted).
Default Value: off.'
pattern: ^(on|off|aes-128-[c,g]cm|aes-192-[c,g]cm|aes-256-[c,g]cm)$
type: string
fsType:
description: 'FsType specifies filesystem type for the zfs volume/dataset.
If FsType is provided as "zfs", then the driver will create a ZFS
dataset, formatting is not required as underlying filesystem is
ZFS anyway. If FsType is ext2, ext3, ext4 or xfs, then the driver
will create a ZVOL and format the volume accordingly. FsType can
not be modified once volume has been provisioned. Default Value:
ext4.'
type: string
keyformat:
description: KeyFormat specifies format of the encryption key The
supported KeyFormats are passphrase, raw, hex.
enum:
- passphrase
- raw
- hex
type: string
keylocation:
description: KeyLocation is the location of key for the encryption
type: string
ownerNodeID:
description: OwnerNodeID is the Node ID where the ZPOOL is running
which is where the volume has been provisioned. OwnerNodeID can
not be edited after the volume has been provisioned.
minLength: 1
type: string
poolName:
description: poolName specifies the name of the pool where the volume
has been created. PoolName can not be edited after the volume has
been provisioned.
minLength: 1
type: string
recordsize:
description: 'Specifies a suggested block size for files in the file
system. The size specified must be a power of two greater than or
equal to 512 and less than or equal to 128 Kbytes. RecordSize property
can be edited after the volume has been created. Changing the file
system''s recordsize affects only files created afterward; existing
files are unaffected. Default Value: 128k.'
minLength: 1
type: string
snapname:
description: SnapName specifies the name of the snapshot where the
volume has been cloned from. Snapname can not be edited after the
volume has been provisioned.
type: string
thinProvision:
description: 'ThinProvision describes whether space reservation for
the source volume is required or not. The value "yes" indicates
that volume should be thin provisioned and "no" means thick provisioning
of the volume. If thinProvision is set to "yes" then volume can
be provisioned even if the ZPOOL does not have the enough capacity.
If thinProvision is set to "no" then volume can be provisioned only
if the ZPOOL has enough capacity and capacity required by volume
can be reserved. ThinProvision can not be modified once volume has
been provisioned. Default Value: no.'
enum:
- "yes"
- "no"
type: string
volblocksize:
description: 'VolBlockSize specifies the block size for the zvol.
The volsize can only be set to a multiple of volblocksize, and cannot
be zero. VolBlockSize can not be edited after the volume has been
provisioned. Default Value: 8k.'
minLength: 1
type: string
volumeType:
description: volumeType determines whether the volume is of type "DATASET"
or "ZVOL". If fstype provided in the storageclass is "zfs", a volume
of type dataset will be created. If "ext4", "ext3", "ext2" or "xfs"
is mentioned as fstype in the storageclass, then a volume of type
zvol will be created, which will be further formatted as the fstype
provided in the storageclass. VolumeType can not be modified once
volume has been provisioned.
enum:
- ZVOL
- DATASET
type: string
required:
- capacity
- ownerNodeID
- poolName
- volumeType
type: object
status:
feat(zfspv) Add golint check to travis (#175) Signed-off-by: vaniisgh <vanisingh@live.co.uk>
2020-07-07 18:21:02 +05:30
description: VolStatus string that specifies the current state of the
volume provisioning request.
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
properties:
state:
description: State specifies the current state of the volume provisioning
request. The state "Pending" means that the volume creation request
has not processed yet. The state "Ready" means that the volume has
been created and it is ready for the use.
enum:
- Pending
- Ready
type: string
type: object
required:
- spec
type: object
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
served: true
storage: false
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
##############################################
########### ############
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
########### ZFSSnapshot CRD ############
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
########### ############
##############################################
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
# ZFSSnapshot CRD is autogenerated via `make manifests` command.
# Do the modification in the code and run the `make manifests` command
# to generate the CRD definition
---
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
annotations:
controller-gen.kubebuilder.io/version: v0.2.8
creationTimestamp: null
refactor(crd): move CR from openebs.io to zfs.openebs.io (#70) Changed the group name from openebs.io to zfs.openebs.io. Now ZFS Volume CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfszvolumes.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: zfsvolumes singular: zfsvolume kind:ZFSVolume shortNames: - zfsvol - zv ``` Snapshot CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfssnapshots.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: fssnapshots singular: zfssnapshot kind: ZFSSnapshot shortNames: - zfssnapshot - zfssnap ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-30 22:12:34 +05:30
name: zfssnapshots.zfs.openebs.io
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
spec:
refactor(crd): move CR from openebs.io to zfs.openebs.io (#70) Changed the group name from openebs.io to zfs.openebs.io. Now ZFS Volume CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfszvolumes.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: zfsvolumes singular: zfsvolume kind:ZFSVolume shortNames: - zfsvol - zv ``` Snapshot CR will look like this : ``` apiVersion: apiextensions.k8s.io/v1beta1 kind: CustomResourceDefinition metadata: name: zfssnapshots.zfs.openebs.io spec: group: zfs.openebs.io version: v1alpha1 scope: Namespaced names: plural: fssnapshots singular: zfssnapshot kind: ZFSSnapshot shortNames: - zfssnapshot - zfssnap ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-30 22:12:34 +05:30
group: zfs.openebs.io
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
names:
kind: ZFSSnapshot
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
listKind: ZFSSnapshotList
plural: zfssnapshots
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
shortNames:
- zfssnap
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
singular: zfssnapshot
preserveUnknownFields: false
scope: Namespaced
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
version: v1
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
versions:
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
- name: v1
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
schema:
openAPIV3Schema:
description: ZFSSnapshot represents a ZFS Snapshot of the zfsvolume
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: VolumeInfo defines ZFS volume parameters for all modes in
which ZFS volumes can be created like - ZFS volume with filesystem,
ZFS Volume exposed as zfs or ZFS volume exposed as raw block device.
Some of the parameters can be only set during creation time (as specified
in the details of the parameter), and a few are editable. In case of
Cloned volumes, the parameters are assigned the same values as the source
volume.
properties:
capacity:
description: Capacity of the volume
minLength: 1
type: string
compression:
description: 'Compression specifies the block-level compression algorithm
to be applied to the ZFS Volume. The value "on" indicates ZFS to
use the default compression algorithm. The default compression algorithm
used by ZFS will be either lzjb or, if the lz4_compress feature
is enabled, lz4. Compression property can be edited after the volume
has been created. The change will only be applied to the newly-written
data. For instance, if the Volume was created with "off" and the
next day the compression was modified to "on", the data written
prior to setting "on" will not be compressed. Default Value: off.'
pattern: ^(on|off|lzjb|gzip|gzip-[1-9]|zle|lz4)$
type: string
dedup:
description: 'Deduplication is the process for removing redundant
data at the block level, reducing the total amount of data stored.
If a file system has the dedup property enabled, duplicate data
blocks are removed synchronously. The result is that only unique
data is stored and common components are shared among files. Deduplication
can consume significant processing power (CPU) and memory as well
as generate additional disk IO. Before creating a pool with deduplication
enabled, ensure that you have planned your hardware requirements
appropriately and implemented appropriate recovery practices, such
as regular backups. As an alternative to deduplication consider
using compression=lz4, as a less resource-intensive alternative.
should be enabled on the zvol. Dedup property can be edited after
the volume has been created. Default Value: off.'
enum:
- "on"
- "off"
type: string
encryption:
description: 'Enabling the encryption feature allows for the creation
of encrypted filesystems and volumes. ZFS will encrypt file and
zvol data, file attributes, ACLs, permission bits, directory listings,
FUID mappings, and userused / groupused data. ZFS will not encrypt
metadata related to the pool structure, including dataset and snapshot
names, dataset hierarchy, properties, file size, file holes, and
deduplication tables (though the deduplicated data itself is encrypted).
Default Value: off.'
pattern: ^(on|off|aes-128-[c,g]cm|aes-192-[c,g]cm|aes-256-[c,g]cm)$
type: string
fsType:
description: 'FsType specifies filesystem type for the zfs volume/dataset.
If FsType is provided as "zfs", then the driver will create a ZFS
dataset, formatting is not required as underlying filesystem is
ZFS anyway. If FsType is ext2, ext3, ext4 or xfs, then the driver
will create a ZVOL and format the volume accordingly. FsType can
not be modified once volume has been provisioned. Default Value:
ext4.'
type: string
keyformat:
description: KeyFormat specifies format of the encryption key The
supported KeyFormats are passphrase, raw, hex.
enum:
- passphrase
- raw
- hex
type: string
keylocation:
description: KeyLocation is the location of key for the encryption
type: string
ownerNodeID:
description: OwnerNodeID is the Node ID where the ZPOOL is running
which is where the volume has been provisioned. OwnerNodeID can
not be edited after the volume has been provisioned.
minLength: 1
type: string
poolName:
description: poolName specifies the name of the pool where the volume
has been created. PoolName can not be edited after the volume has
been provisioned.
minLength: 1
type: string
recordsize:
description: 'Specifies a suggested block size for files in the file
system. The size specified must be a power of two greater than or
equal to 512 and less than or equal to 128 Kbytes. RecordSize property
can be edited after the volume has been created. Changing the file
system''s recordsize affects only files created afterward; existing
files are unaffected. Default Value: 128k.'
minLength: 1
type: string
shared:
description: Shared specifies whether the volume can be shared among
multiple pods. If it is not set to "yes", then the ZFS-LocalPV Driver
will not allow the volumes to be mounted by more than one pods.
enum:
- "yes"
- "no"
type: string
snapname:
description: SnapName specifies the name of the snapshot where the
volume has been cloned from. Snapname can not be edited after the
volume has been provisioned.
type: string
thinProvision:
description: 'ThinProvision describes whether space reservation for
the source volume is required or not. The value "yes" indicates
that volume should be thin provisioned and "no" means thick provisioning
of the volume. If thinProvision is set to "yes" then volume can
be provisioned even if the ZPOOL does not have the enough capacity.
If thinProvision is set to "no" then volume can be provisioned only
if the ZPOOL has enough capacity and capacity required by volume
can be reserved. ThinProvision can not be modified once volume has
been provisioned. Default Value: no.'
enum:
- "yes"
- "no"
type: string
volblocksize:
description: 'VolBlockSize specifies the block size for the zvol.
The volsize can only be set to a multiple of volblocksize, and cannot
be zero. VolBlockSize can not be edited after the volume has been
provisioned. Default Value: 8k.'
minLength: 1
type: string
volumeType:
description: volumeType determines whether the volume is of type "DATASET"
or "ZVOL". If fstype provided in the storageclass is "zfs", a volume
of type dataset will be created. If "ext4", "ext3", "ext2" or "xfs"
is mentioned as fstype in the storageclass, then a volume of type
zvol will be created, which will be further formatted as the fstype
provided in the storageclass. VolumeType can not be modified once
volume has been provisioned.
enum:
- ZVOL
- DATASET
type: string
required:
- capacity
- ownerNodeID
- poolName
- volumeType
type: object
status:
feat(zfspv) Add golint check to travis (#175) Signed-off-by: vaniisgh <vanisingh@live.co.uk>
2020-07-07 18:21:02 +05:30
description: SnapStatus string that reflects if the snapshot was cretaed
successfully
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
properties:
state:
type: string
type: object
required:
- spec
- status
type: object
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
served: true
storage: true
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
- name: v1alpha1
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
schema:
openAPIV3Schema:
description: ZFSSnapshot represents a ZFS Snapshot of the zfsvolume
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: VolumeInfo defines ZFS volume parameters for all modes in
which ZFS volumes can be created like - ZFS volume with filesystem,
ZFS Volume exposed as zfs or ZFS volume exposed as raw block device.
Some of the parameters can be only set during creation time (as specified
in the details of the parameter), and a few are editable. In case of
Cloned volumes, the parameters are assigned the same values as the source
volume.
properties:
capacity:
description: Capacity of the volume
minLength: 1
type: string
compression:
description: 'Compression specifies the block-level compression algorithm
to be applied to the ZFS Volume. The value "on" indicates ZFS to
use the default compression algorithm. The default compression algorithm
used by ZFS will be either lzjb or, if the lz4_compress feature
is enabled, lz4. Compression property can be edited after the volume
has been created. The change will only be applied to the newly-written
data. For instance, if the Volume was created with "off" and the
next day the compression was modified to "on", the data written
prior to setting "on" will not be compressed. Default Value: off.'
pattern: ^(on|off|lzjb|gzip|gzip-[1-9]|zle|lz4)$
type: string
dedup:
description: 'Deduplication is the process for removing redundant
data at the block level, reducing the total amount of data stored.
If a file system has the dedup property enabled, duplicate data
blocks are removed synchronously. The result is that only unique
data is stored and common components are shared among files. Deduplication
can consume significant processing power (CPU) and memory as well
as generate additional disk IO. Before creating a pool with deduplication
enabled, ensure that you have planned your hardware requirements
appropriately and implemented appropriate recovery practices, such
as regular backups. As an alternative to deduplication consider
using compression=lz4, as a less resource-intensive alternative.
should be enabled on the zvol. Dedup property can be edited after
the volume has been created. Default Value: off.'
enum:
- "on"
- "off"
type: string
encryption:
description: 'Enabling the encryption feature allows for the creation
of encrypted filesystems and volumes. ZFS will encrypt file and
zvol data, file attributes, ACLs, permission bits, directory listings,
FUID mappings, and userused / groupused data. ZFS will not encrypt
metadata related to the pool structure, including dataset and snapshot
names, dataset hierarchy, properties, file size, file holes, and
deduplication tables (though the deduplicated data itself is encrypted).
Default Value: off.'
pattern: ^(on|off|aes-128-[c,g]cm|aes-192-[c,g]cm|aes-256-[c,g]cm)$
type: string
fsType:
description: 'FsType specifies filesystem type for the zfs volume/dataset.
If FsType is provided as "zfs", then the driver will create a ZFS
dataset, formatting is not required as underlying filesystem is
ZFS anyway. If FsType is ext2, ext3, ext4 or xfs, then the driver
will create a ZVOL and format the volume accordingly. FsType can
not be modified once volume has been provisioned. Default Value:
ext4.'
type: string
keyformat:
description: KeyFormat specifies format of the encryption key The
supported KeyFormats are passphrase, raw, hex.
enum:
- passphrase
- raw
- hex
type: string
keylocation:
description: KeyLocation is the location of key for the encryption
type: string
ownerNodeID:
description: OwnerNodeID is the Node ID where the ZPOOL is running
which is where the volume has been provisioned. OwnerNodeID can
not be edited after the volume has been provisioned.
minLength: 1
type: string
poolName:
description: poolName specifies the name of the pool where the volume
has been created. PoolName can not be edited after the volume has
been provisioned.
minLength: 1
type: string
recordsize:
description: 'Specifies a suggested block size for files in the file
system. The size specified must be a power of two greater than or
equal to 512 and less than or equal to 128 Kbytes. RecordSize property
can be edited after the volume has been created. Changing the file
system''s recordsize affects only files created afterward; existing
files are unaffected. Default Value: 128k.'
minLength: 1
type: string
snapname:
description: SnapName specifies the name of the snapshot where the
volume has been cloned from. Snapname can not be edited after the
volume has been provisioned.
type: string
thinProvision:
description: 'ThinProvision describes whether space reservation for
the source volume is required or not. The value "yes" indicates
that volume should be thin provisioned and "no" means thick provisioning
of the volume. If thinProvision is set to "yes" then volume can
be provisioned even if the ZPOOL does not have the enough capacity.
If thinProvision is set to "no" then volume can be provisioned only
if the ZPOOL has enough capacity and capacity required by volume
can be reserved. ThinProvision can not be modified once volume has
been provisioned. Default Value: no.'
enum:
- "yes"
- "no"
type: string
volblocksize:
description: 'VolBlockSize specifies the block size for the zvol.
The volsize can only be set to a multiple of volblocksize, and cannot
be zero. VolBlockSize can not be edited after the volume has been
provisioned. Default Value: 8k.'
minLength: 1
type: string
volumeType:
description: volumeType determines whether the volume is of type "DATASET"
or "ZVOL". If fstype provided in the storageclass is "zfs", a volume
of type dataset will be created. If "ext4", "ext3", "ext2" or "xfs"
is mentioned as fstype in the storageclass, then a volume of type
zvol will be created, which will be further formatted as the fstype
provided in the storageclass. VolumeType can not be modified once
volume has been provisioned.
enum:
- ZVOL
- DATASET
type: string
required:
- capacity
- ownerNodeID
- poolName
- volumeType
type: object
status:
feat(zfspv) Add golint check to travis (#175) Signed-off-by: vaniisgh <vanisingh@live.co.uk>
2020-07-07 18:21:02 +05:30
description: SnapStatus string that reflects if the snapshot was cretaed
successfully
feat(shared): adding shared mount support ZFSPV volumes Applications who want to share a volume can use below storageclass to make their volumes shared by multiple pods ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv parameters: shared: "yes" fstype: "zfs" poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Now the provisioned volume using this storageclass can be used by multiple pods. Here pods have to make sure of the data consistency and have to have locking mechanism. One thing to note here is pods will be scheduled to the node where volume is present so that all the pods can use the same volume as they can access it locally only. This was we can avoid the NFS overhead and can get the optimal performance also. Also fixed the log formatting in the GRPC log. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-26 12:38:09 +05:30
properties:
state:
type: string
type: object
required:
- spec
- status
type: object
feat(beta): adding v1 CRD for ZFS-LocalPV Moving the CRDs to stable v1 version. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-22 18:07:17 +05:30
served: true
storage: false
feat(validation): adding validation for ZFSPV CR parameters (#66) Validating few parameters for the ZFSVolume custom resource - compression can be "on", "off", "lzjb", "gzip", "gzip-[1-9]", "zle" and "lz4" - encryption can be "on", "off", "aes-128-ccm", "aes-192-ccm", "aes-256-ccm", "aes-128-gcm", "aes-192-gcm", and "aes-256-gcm" - dedup can be "on" and "off" - poolname can be string - ownernodeid can be string - thinprovision can be "yes" and "no" - volumetype can be "DATASET" and "ZVOL" Also added required fields needed to create ZFSVolume CR - ownerNodeID - poolname - volumeType - capacity Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-14 17:26:46 +05:30
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
##############################################
########### ############
########### ZFSBackup CRD ############
########### ############
##############################################
# ZFSBackups CRD is autogenerated via `make manifests` command.
# Do the modification in the code and run the `make manifests` command
# to generate the CRD definition
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.2.8
creationTimestamp: null
name: zfsbackups.zfs.openebs.io
spec:
additionalPrinterColumns:
- JSONPath: .spec.prevSnapName
description: Previous snapshot for backup
name: PrevSnap
type: string
- JSONPath: .status
description: Backup status
name: Status
type: string
- JSONPath: .metadata.creationTimestamp
description: Age of the volume
name: Age
type: date
group: zfs.openebs.io
names:
kind: ZFSBackup
listKind: ZFSBackupList
plural: zfsbackups
shortNames:
- zb
singular: zfsbackup
preserveUnknownFields: false
scope: Namespaced
subresources: {}
validation:
openAPIV3Schema:
description: ZFSBackup describes a zfs backup resource created as a custom resource
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: ZFSBackupSpec is the spec for a ZFSBackup resource
properties:
backupDest:
description: BackupDest is the remote address for backup transfer
minLength: 1
feat(backup,restore): adding validation for backup and restore Added a schema validation for backup and restore CR. Also validating the server address in the backup/restore controller. Validating the server address as : ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$ which is : <any number>.<any number>.<any number>.<any number>:<any number> Here we are validating just the format of the IP, not validating that IP should be correct which will be little more complex. In any case if IP is not correct, the zfs send will fail, so no need to do complex validation to validate the correct IP and port. Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-16 19:17:48 +05:30
pattern: ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
type: string
ownerNodeID:
description: OwnerNodeID is a name of the nodes where the source volume
is
minLength: 1
type: string
prevSnapName:
description: PrevSnapName is the last completed-backup's snapshot name
type: string
snapName:
description: SnapName is the snapshot name for backup
minLength: 1
type: string
volumeName:
description: VolumeName is a name of the volume for which this backup
is destined
minLength: 1
type: string
required:
- backupDest
- ownerNodeID
- volumeName
type: object
status:
description: ZFSBackupStatus is to hold status of backup
feat(backup,restore): adding validation for backup and restore Added a schema validation for backup and restore CR. Also validating the server address in the backup/restore controller. Validating the server address as : ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$ which is : <any number>.<any number>.<any number>.<any number>:<any number> Here we are validating just the format of the IP, not validating that IP should be correct which will be little more complex. In any case if IP is not correct, the zfs send will fail, so no need to do complex validation to validate the correct IP and port. Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-16 19:17:48 +05:30
enum:
- Init
- Done
- Failed
- Pending
- InProgress
- Invalid
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
type: string
required:
- spec
- status
type: object
version: v1
versions:
- name: v1
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
##############################################
########### ############
########### ZFSRestore CRD ############
########### ############
##############################################
# ZFSRestores CRD is autogenerated via `make manifests` command.
# Do the modification in the code and run the `make manifests` command
# to generate the CRD definition
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: v0.2.8
creationTimestamp: null
name: zfsrestores.zfs.openebs.io
spec:
group: zfs.openebs.io
names:
kind: ZFSRestore
listKind: ZFSRestoreList
plural: zfsrestores
singular: zfsrestore
preserveUnknownFields: false
scope: Namespaced
validation:
openAPIV3Schema:
description: ZFSRestore describes a cstor restore resource created as a custom
resource
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation
of an object. Servers should convert recognized schemas to the latest
internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this
object represents. Servers may infer this from the endpoint the client
submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds'
type: string
metadata:
type: object
spec:
description: ZFSRestoreSpec is the spec for a ZFSRestore resource
properties:
ownerNodeID:
description: owner node name where restore volume is present
minLength: 1
type: string
restoreSrc:
description: it can be ip:port in case of restore from remote or volumeName
in case of local restore
minLength: 1
feat(backup,restore): adding validation for backup and restore Added a schema validation for backup and restore CR. Also validating the server address in the backup/restore controller. Validating the server address as : ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$ which is : <any number>.<any number>.<any number>.<any number>:<any number> Here we are validating just the format of the IP, not validating that IP should be correct which will be little more complex. In any case if IP is not correct, the zfs send will fail, so no need to do complex validation to validate the correct IP and port. Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-16 19:17:48 +05:30
pattern: ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
type: string
volumeName:
description: volume name to where restore has to be performed
minLength: 1
type: string
required:
- ownerNodeID
- restoreSrc
- volumeName
type: object
status:
description: ZFSRestoreStatus is to hold result of action.
feat(backup,restore): adding validation for backup and restore Added a schema validation for backup and restore CR. Also validating the server address in the backup/restore controller. Validating the server address as : ^([0-9]+.[0-9]+.[0-9]+.[0-9]+:[0-9]+)$ which is : <any number>.<any number>.<any number>.<any number>:<any number> Here we are validating just the format of the IP, not validating that IP should be correct which will be little more complex. In any case if IP is not correct, the zfs send will fail, so no need to do complex validation to validate the correct IP and port. Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-16 19:17:48 +05:30
enum:
- Init
- Done
- Failed
- Pending
- InProgress
- Invalid
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
type: string
required:
- spec
- status
type: object
version: v1
versions:
- name: v1
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
---
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
feat(attach): avoid creation of volumeattachment object k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object. (k8s issue https://github.com/kubernetes/kubernetes/issues/84169) The volumeattachment is not required for ZFSPV, so avoid creation of attachment object, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object : k8s issue https://github.com/kubernetes/kubernetes/issues/84169). Volumeattachment is a CR created just to tell the watcher of it which is csi-attacher, that it has to call the Controller Publish/Unpublish grpc. Which does all the tasks to attach the volumes to a node for example call to the DigitalOcean Block Storage API service to attach a created volume to a specified node. Since for ZFSPV, volume is already present locally, nothing needs to done in Controller Publish/Unpublish, so it is good to remove them. so avoiding creation of attachment object in this change, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. Removed csi-cluster-driver-registrar container also as it is deprecated and not needed anymore. We are using csidriver beta CRDs so minimum k8s version required is 1.14+. Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-17 13:59:28 +05:30
# Create the CSI Driver object
apiVersion: storage.k8s.io/v1beta1
kind: CSIDriver
metadata:
name: zfs.csi.openebs.io
spec:
# do not require volumeattachment
attachRequired: false
podInfoOnMount: false
---
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
apiVersion: apiextensions.k8s.io/v1
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
kind: CustomResourceDefinition
metadata:
annotations:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
controller-gen.kubebuilder.io/version: v0.4.0
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/419"
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
creationTimestamp: null
name: volumesnapshotclasses.snapshot.storage.k8s.io
spec:
group: snapshot.storage.k8s.io
names:
kind: VolumeSnapshotClass
listKind: VolumeSnapshotClassList
plural: volumesnapshotclasses
singular: volumesnapshotclass
scope: Cluster
versions:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
- additionalPrinterColumns:
- jsonPath: .driver
name: Driver
type: string
- description: Determines whether a VolumeSnapshotContent created through the VolumeSnapshotClass should be deleted when its bound VolumeSnapshot is deleted.
jsonPath: .deletionPolicy
name: DeletionPolicy
type: string
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: VolumeSnapshotClass specifies parameters that a underlying storage system uses when creating a volume snapshot. A specific VolumeSnapshotClass is used by specifying its name in a VolumeSnapshot object. VolumeSnapshotClasses are non-namespaced
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
deletionPolicy:
description: deletionPolicy determines whether a VolumeSnapshotContent created through the VolumeSnapshotClass should be deleted when its bound VolumeSnapshot is deleted. Supported values are "Retain" and "Delete". "Retain" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are kept. "Delete" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are deleted. Required.
enum:
- Delete
- Retain
type: string
driver:
description: driver is the name of the storage driver that handles this VolumeSnapshotClass. Required.
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
parameters:
additionalProperties:
type: string
description: parameters is a key-value map with storage driver specific parameters for creating snapshots. These values are opaque to Kubernetes.
type: object
required:
- deletionPolicy
- driver
type: object
served: true
storage: false
subresources: {}
- additionalPrinterColumns:
- jsonPath: .driver
name: Driver
type: string
- description: Determines whether a VolumeSnapshotContent created through the VolumeSnapshotClass should be deleted when its bound VolumeSnapshot is deleted.
jsonPath: .deletionPolicy
name: DeletionPolicy
type: string
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1beta1
schema:
openAPIV3Schema:
description: VolumeSnapshotClass specifies parameters that a underlying storage system uses when creating a volume snapshot. A specific VolumeSnapshotClass is used by specifying its name in a VolumeSnapshot object. VolumeSnapshotClasses are non-namespaced
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
deletionPolicy:
description: deletionPolicy determines whether a VolumeSnapshotContent created through the VolumeSnapshotClass should be deleted when its bound VolumeSnapshot is deleted. Supported values are "Retain" and "Delete". "Retain" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are kept. "Delete" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are deleted. Required.
enum:
- Delete
- Retain
type: string
driver:
description: driver is the name of the storage driver that handles this VolumeSnapshotClass. Required.
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
parameters:
additionalProperties:
type: string
description: parameters is a key-value map with storage driver specific parameters for creating snapshots. These values are opaque to Kubernetes.
type: object
required:
- deletionPolicy
- driver
type: object
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
served: true
storage: true
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
subresources: {}
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
---
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
apiVersion: apiextensions.k8s.io/v1
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
kind: CustomResourceDefinition
metadata:
annotations:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
controller-gen.kubebuilder.io/version: v0.4.0
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/419"
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
creationTimestamp: null
name: volumesnapshotcontents.snapshot.storage.k8s.io
spec:
group: snapshot.storage.k8s.io
names:
kind: VolumeSnapshotContent
listKind: VolumeSnapshotContentList
plural: volumesnapshotcontents
singular: volumesnapshotcontent
scope: Cluster
versions:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
- additionalPrinterColumns:
- description: Indicates if the snapshot is ready to be used to restore a volume.
jsonPath: .status.readyToUse
name: ReadyToUse
type: boolean
- description: Represents the complete size of the snapshot in bytes
jsonPath: .status.restoreSize
name: RestoreSize
type: integer
- description: Determines whether this VolumeSnapshotContent and its physical snapshot on the underlying storage system should be deleted when its bound VolumeSnapshot is deleted.
jsonPath: .spec.deletionPolicy
name: DeletionPolicy
type: string
- description: Name of the CSI driver used to create the physical snapshot on the underlying storage system.
jsonPath: .spec.driver
name: Driver
type: string
- description: Name of the VolumeSnapshotClass to which this snapshot belongs.
jsonPath: .spec.volumeSnapshotClassName
name: VolumeSnapshotClass
type: string
- description: Name of the VolumeSnapshot object to which this VolumeSnapshotContent object is bound.
jsonPath: .spec.volumeSnapshotRef.name
name: VolumeSnapshot
type: string
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: VolumeSnapshotContent represents the actual "on-disk" snapshot object in the underlying storage system
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
spec:
description: spec defines properties of a VolumeSnapshotContent created by the underlying storage system. Required.
properties:
deletionPolicy:
description: deletionPolicy determines whether this VolumeSnapshotContent and its physical snapshot on the underlying storage system should be deleted when its bound VolumeSnapshot is deleted. Supported values are "Retain" and "Delete". "Retain" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are kept. "Delete" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are deleted. For dynamically provisioned snapshots, this field will automatically be filled in by the CSI snapshotter sidecar with the "DeletionPolicy" field defined in the corresponding VolumeSnapshotClass. For pre-existing snapshots, users MUST specify this field when creating the VolumeSnapshotContent object. Required.
enum:
- Delete
- Retain
type: string
driver:
description: driver is the name of the CSI driver used to create the physical snapshot on the underlying storage system. This MUST be the same as the name returned by the CSI GetPluginName() call for that driver. Required.
type: string
source:
description: source specifies whether the snapshot is (or should be) dynamically provisioned or already exists, and just requires a Kubernetes object representation. This field is immutable after creation. Required.
properties:
snapshotHandle:
description: snapshotHandle specifies the CSI "snapshot_id" of a pre-existing snapshot on the underlying storage system for which a Kubernetes object representation was (or should be) created. This field is immutable.
type: string
volumeHandle:
description: volumeHandle specifies the CSI "volume_id" of the volume from which a snapshot should be dynamically taken from. This field is immutable.
type: string
type: object
oneOf:
- required: ["snapshotHandle"]
- required: ["volumeHandle"]
volumeSnapshotClassName:
description: name of the VolumeSnapshotClass from which this snapshot was (or will be) created. Note that after provisioning, the VolumeSnapshotClass may be deleted or recreated with different set of values, and as such, should not be referenced post-snapshot creation.
type: string
volumeSnapshotRef:
description: volumeSnapshotRef specifies the VolumeSnapshot object to which this VolumeSnapshotContent object is bound. VolumeSnapshot.Spec.VolumeSnapshotContentName field must reference to this VolumeSnapshotContent's name for the bidirectional binding to be valid. For a pre-existing VolumeSnapshotContent object, name and namespace of the VolumeSnapshot object MUST be provided for binding to happen. This field is immutable after creation. Required.
properties:
apiVersion:
description: API version of the referent.
type: string
fieldPath:
description: 'If referring to a piece of an object instead of an entire object, this string should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2]. For example, if the object reference is to a container within a pod, this would take on a value like: "spec.containers{name}" (where "name" refers to the name of the container that triggered the event) or if no container name is specified "spec.containers[2]" (container with index 2 in this pod). This syntax is chosen only to have some well-defined way of referencing a part of an object. TODO: this design is not final and this field is subject to change in the future.'
type: string
kind:
description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
name:
description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names'
type: string
namespace:
description: 'Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/'
type: string
resourceVersion:
description: 'Specific resourceVersion to which this reference is made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency'
type: string
uid:
description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
type: string
type: object
required:
- deletionPolicy
- driver
- source
- volumeSnapshotRef
type: object
status:
description: status represents the current information of a snapshot.
properties:
creationTime:
description: creationTime is the timestamp when the point-in-time snapshot is taken by the underlying storage system. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "creation_time" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "creation_time" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. If not specified, it indicates the creation time is unknown. The format of this field is a Unix nanoseconds time encoded as an int64. On Unix, the command `date +%s%N` returns the current time in nanoseconds since 1970-01-01 00:00:00 UTC.
format: int64
type: integer
error:
description: error is the last observed error during snapshot creation, if any. Upon success after retry, this error field will be cleared.
properties:
message:
description: 'message is a string detailing the encountered error during snapshot creation if specified. NOTE: message may be logged, and it should not contain sensitive information.'
type: string
time:
description: time is the timestamp when the error was encountered.
format: date-time
type: string
type: object
readyToUse:
description: readyToUse indicates if a snapshot is ready to be used to restore a volume. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "ready_to_use" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "ready_to_use" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it, otherwise, this field will be set to "True". If not specified, it means the readiness of a snapshot is unknown.
type: boolean
restoreSize:
description: restoreSize represents the complete size of the snapshot in bytes. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "size_bytes" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "size_bytes" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. When restoring a volume from this snapshot, the size of the volume MUST NOT be smaller than the restoreSize if it is specified, otherwise the restoration will fail. If not specified, it indicates that the size is unknown.
format: int64
minimum: 0
type: integer
snapshotHandle:
description: snapshotHandle is the CSI "snapshot_id" of a snapshot on the underlying storage system. If not specified, it indicates that dynamic snapshot creation has either failed or it is still in progress.
type: string
type: object
required:
- spec
type: object
served: true
storage: false
subresources:
status: {}
- additionalPrinterColumns:
- description: Indicates if the snapshot is ready to be used to restore a volume.
jsonPath: .status.readyToUse
name: ReadyToUse
type: boolean
- description: Represents the complete size of the snapshot in bytes
jsonPath: .status.restoreSize
name: RestoreSize
type: integer
- description: Determines whether this VolumeSnapshotContent and its physical snapshot on the underlying storage system should be deleted when its bound VolumeSnapshot is deleted.
jsonPath: .spec.deletionPolicy
name: DeletionPolicy
type: string
- description: Name of the CSI driver used to create the physical snapshot on the underlying storage system.
jsonPath: .spec.driver
name: Driver
type: string
- description: Name of the VolumeSnapshotClass to which this snapshot belongs.
jsonPath: .spec.volumeSnapshotClassName
name: VolumeSnapshotClass
type: string
- description: Name of the VolumeSnapshot object to which this VolumeSnapshotContent object is bound.
jsonPath: .spec.volumeSnapshotRef.name
name: VolumeSnapshot
type: string
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1beta1
schema:
openAPIV3Schema:
description: VolumeSnapshotContent represents the actual "on-disk" snapshot object in the underlying storage system
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
spec:
description: spec defines properties of a VolumeSnapshotContent created by the underlying storage system. Required.
properties:
deletionPolicy:
description: deletionPolicy determines whether this VolumeSnapshotContent and its physical snapshot on the underlying storage system should be deleted when its bound VolumeSnapshot is deleted. Supported values are "Retain" and "Delete". "Retain" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are kept. "Delete" means that the VolumeSnapshotContent and its physical snapshot on underlying storage system are deleted. For dynamically provisioned snapshots, this field will automatically be filled in by the CSI snapshotter sidecar with the "DeletionPolicy" field defined in the corresponding VolumeSnapshotClass. For pre-existing snapshots, users MUST specify this field when creating the VolumeSnapshotContent object. Required.
enum:
- Delete
- Retain
type: string
driver:
description: driver is the name of the CSI driver used to create the physical snapshot on the underlying storage system. This MUST be the same as the name returned by the CSI GetPluginName() call for that driver. Required.
type: string
source:
description: source specifies whether the snapshot is (or should be) dynamically provisioned or already exists, and just requires a Kubernetes object representation. This field is immutable after creation. Required.
properties:
snapshotHandle:
description: snapshotHandle specifies the CSI "snapshot_id" of a pre-existing snapshot on the underlying storage system for which a Kubernetes object representation was (or should be) created. This field is immutable.
type: string
volumeHandle:
description: volumeHandle specifies the CSI "volume_id" of the volume from which a snapshot should be dynamically taken from. This field is immutable.
type: string
type: object
volumeSnapshotClassName:
description: name of the VolumeSnapshotClass from which this snapshot was (or will be) created. Note that after provisioning, the VolumeSnapshotClass may be deleted or recreated with different set of values, and as such, should not be referenced post-snapshot creation.
type: string
volumeSnapshotRef:
description: volumeSnapshotRef specifies the VolumeSnapshot object to which this VolumeSnapshotContent object is bound. VolumeSnapshot.Spec.VolumeSnapshotContentName field must reference to this VolumeSnapshotContent's name for the bidirectional binding to be valid. For a pre-existing VolumeSnapshotContent object, name and namespace of the VolumeSnapshot object MUST be provided for binding to happen. This field is immutable after creation. Required.
properties:
apiVersion:
description: API version of the referent.
type: string
fieldPath:
description: 'If referring to a piece of an object instead of an entire object, this string should contain a valid JSON/Go field access statement, such as desiredState.manifest.containers[2]. For example, if the object reference is to a container within a pod, this would take on a value like: "spec.containers{name}" (where "name" refers to the name of the container that triggered the event) or if no container name is specified "spec.containers[2]" (container with index 2 in this pod). This syntax is chosen only to have some well-defined way of referencing a part of an object. TODO: this design is not final and this field is subject to change in the future.'
type: string
kind:
description: 'Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
name:
description: 'Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names'
type: string
namespace:
description: 'Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/'
type: string
resourceVersion:
description: 'Specific resourceVersion to which this reference is made, if any. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#concurrency-control-and-consistency'
type: string
uid:
description: 'UID of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#uids'
type: string
type: object
required:
- deletionPolicy
- driver
- source
- volumeSnapshotRef
type: object
status:
description: status represents the current information of a snapshot.
properties:
creationTime:
description: creationTime is the timestamp when the point-in-time snapshot is taken by the underlying storage system. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "creation_time" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "creation_time" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. If not specified, it indicates the creation time is unknown. The format of this field is a Unix nanoseconds time encoded as an int64. On Unix, the command `date +%s%N` returns the current time in nanoseconds since 1970-01-01 00:00:00 UTC.
format: int64
type: integer
error:
description: error is the last observed error during snapshot creation, if any. Upon success after retry, this error field will be cleared.
properties:
message:
description: 'message is a string detailing the encountered error during snapshot creation if specified. NOTE: message may be logged, and it should not contain sensitive information.'
type: string
time:
description: time is the timestamp when the error was encountered.
format: date-time
type: string
type: object
readyToUse:
description: readyToUse indicates if a snapshot is ready to be used to restore a volume. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "ready_to_use" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "ready_to_use" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it, otherwise, this field will be set to "True". If not specified, it means the readiness of a snapshot is unknown.
type: boolean
restoreSize:
description: restoreSize represents the complete size of the snapshot in bytes. In dynamic snapshot creation case, this field will be filled in by the CSI snapshotter sidecar with the "size_bytes" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "size_bytes" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. When restoring a volume from this snapshot, the size of the volume MUST NOT be smaller than the restoreSize if it is specified, otherwise the restoration will fail. If not specified, it indicates that the size is unknown.
format: int64
minimum: 0
type: integer
snapshotHandle:
description: snapshotHandle is the CSI "snapshot_id" of a snapshot on the underlying storage system. If not specified, it indicates that dynamic snapshot creation has either failed or it is still in progress.
type: string
type: object
required:
- spec
type: object
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
served: true
storage: true
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
subresources:
status: {}
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
---
apiVersion: apiextensions.k8s.io/v1
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
kind: CustomResourceDefinition
metadata:
annotations:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
controller-gen.kubebuilder.io/version: v0.4.0
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/419"
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
creationTimestamp: null
name: volumesnapshots.snapshot.storage.k8s.io
spec:
group: snapshot.storage.k8s.io
names:
kind: VolumeSnapshot
listKind: VolumeSnapshotList
plural: volumesnapshots
singular: volumesnapshot
scope: Namespaced
versions:
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
- additionalPrinterColumns:
- description: Indicates if the snapshot is ready to be used to restore a volume.
jsonPath: .status.readyToUse
name: ReadyToUse
type: boolean
- description: If a new snapshot needs to be created, this contains the name of the source PVC from which this snapshot was (or will be) created.
jsonPath: .spec.source.persistentVolumeClaimName
name: SourcePVC
type: string
- description: If a snapshot already exists, this contains the name of the existing VolumeSnapshotContent object representing the existing snapshot.
jsonPath: .spec.source.volumeSnapshotContentName
name: SourceSnapshotContent
type: string
- description: Represents the minimum size of volume required to rehydrate from this snapshot.
jsonPath: .status.restoreSize
name: RestoreSize
type: string
- description: The name of the VolumeSnapshotClass requested by the VolumeSnapshot.
jsonPath: .spec.volumeSnapshotClassName
name: SnapshotClass
type: string
- description: Name of the VolumeSnapshotContent object to which the VolumeSnapshot object intends to bind to. Please note that verification of binding actually requires checking both VolumeSnapshot and VolumeSnapshotContent to ensure both are pointing at each other. Binding MUST be verified prior to usage of this object.
jsonPath: .status.boundVolumeSnapshotContentName
name: SnapshotContent
type: string
- description: Timestamp when the point-in-time snapshot was taken by the underlying storage system.
jsonPath: .status.creationTime
name: CreationTime
type: date
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: VolumeSnapshot is a user's request for either creating a point-in-time snapshot of a persistent volume, or binding to a pre-existing snapshot.
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
spec:
description: 'spec defines the desired characteristics of a snapshot requested by a user. More info: https://kubernetes.io/docs/concepts/storage/volume-snapshots#volumesnapshots Required.'
properties:
source:
description: source specifies where a snapshot will be created from. This field is immutable after creation. Required.
properties:
persistentVolumeClaimName:
description: persistentVolumeClaimName specifies the name of the PersistentVolumeClaim object representing the volume from which a snapshot should be created. This PVC is assumed to be in the same namespace as the VolumeSnapshot object. This field should be set if the snapshot does not exists, and needs to be created. This field is immutable.
type: string
volumeSnapshotContentName:
description: volumeSnapshotContentName specifies the name of a pre-existing VolumeSnapshotContent object representing an existing volume snapshot. This field should be set if the snapshot already exists and only needs a representation in Kubernetes. This field is immutable.
type: string
type: object
oneOf:
- required: ["persistentVolumeClaimName"]
- required: ["volumeSnapshotContentName"]
volumeSnapshotClassName:
description: 'VolumeSnapshotClassName is the name of the VolumeSnapshotClass requested by the VolumeSnapshot. VolumeSnapshotClassName may be left nil to indicate that the default SnapshotClass should be used. A given cluster may have multiple default Volume SnapshotClasses: one default per CSI Driver. If a VolumeSnapshot does not specify a SnapshotClass, VolumeSnapshotSource will be checked to figure out what the associated CSI Driver is, and the default VolumeSnapshotClass associated with that CSI Driver will be used. If more than one VolumeSnapshotClass exist for a given CSI Driver and more than one have been marked as default, CreateSnapshot will fail and generate an event. Empty string is not allowed for this field.'
type: string
required:
- source
type: object
status:
description: status represents the current information of a snapshot. Consumers must verify binding between VolumeSnapshot and VolumeSnapshotContent objects is successful (by validating that both VolumeSnapshot and VolumeSnapshotContent point at each other) before using this object.
properties:
boundVolumeSnapshotContentName:
description: 'boundVolumeSnapshotContentName is the name of the VolumeSnapshotContent object to which this VolumeSnapshot object intends to bind to. If not specified, it indicates that the VolumeSnapshot object has not been successfully bound to a VolumeSnapshotContent object yet. NOTE: To avoid possible security issues, consumers must verify binding between VolumeSnapshot and VolumeSnapshotContent objects is successful (by validating that both VolumeSnapshot and VolumeSnapshotContent point at each other) before using this object.'
type: string
creationTime:
description: creationTime is the timestamp when the point-in-time snapshot is taken by the underlying storage system. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "creation_time" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "creation_time" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. If not specified, it may indicate that the creation time of the snapshot is unknown.
format: date-time
type: string
error:
description: error is the last observed error during snapshot creation, if any. This field could be helpful to upper level controllers(i.e., application controller) to decide whether they should continue on waiting for the snapshot to be created based on the type of error reported. The snapshot controller will keep retrying when an error occurrs during the snapshot creation. Upon success, this error field will be cleared.
properties:
message:
description: 'message is a string detailing the encountered error during snapshot creation if specified. NOTE: message may be logged, and it should not contain sensitive information.'
type: string
time:
description: time is the timestamp when the error was encountered.
format: date-time
type: string
type: object
readyToUse:
description: readyToUse indicates if the snapshot is ready to be used to restore a volume. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "ready_to_use" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "ready_to_use" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it, otherwise, this field will be set to "True". If not specified, it means the readiness of a snapshot is unknown.
type: boolean
restoreSize:
type: string
description: restoreSize represents the minimum size of volume required to create a volume from this snapshot. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "size_bytes" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "size_bytes" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. When restoring a volume from this snapshot, the size of the volume MUST NOT be smaller than the restoreSize if it is specified, otherwise the restoration will fail. If not specified, it indicates that the size is unknown.
pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
x-kubernetes-int-or-string: true
type: object
required:
- spec
type: object
served: true
storage: false
subresources:
status: {}
- additionalPrinterColumns:
- description: Indicates if the snapshot is ready to be used to restore a volume.
jsonPath: .status.readyToUse
name: ReadyToUse
type: boolean
- description: If a new snapshot needs to be created, this contains the name of the source PVC from which this snapshot was (or will be) created.
jsonPath: .spec.source.persistentVolumeClaimName
name: SourcePVC
type: string
- description: If a snapshot already exists, this contains the name of the existing VolumeSnapshotContent object representing the existing snapshot.
jsonPath: .spec.source.volumeSnapshotContentName
name: SourceSnapshotContent
type: string
- description: Represents the minimum size of volume required to rehydrate from this snapshot.
jsonPath: .status.restoreSize
name: RestoreSize
type: string
- description: The name of the VolumeSnapshotClass requested by the VolumeSnapshot.
jsonPath: .spec.volumeSnapshotClassName
name: SnapshotClass
type: string
- description: Name of the VolumeSnapshotContent object to which the VolumeSnapshot object intends to bind to. Please note that verification of binding actually requires checking both VolumeSnapshot and VolumeSnapshotContent to ensure both are pointing at each other. Binding MUST be verified prior to usage of this object.
jsonPath: .status.boundVolumeSnapshotContentName
name: SnapshotContent
type: string
- description: Timestamp when the point-in-time snapshot was taken by the underlying storage system.
jsonPath: .status.creationTime
name: CreationTime
type: date
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1beta1
schema:
openAPIV3Schema:
description: VolumeSnapshot is a user's request for either creating a point-in-time snapshot of a persistent volume, or binding to a pre-existing snapshot.
properties:
apiVersion:
description: 'APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources'
type: string
kind:
description: 'Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds'
type: string
spec:
description: 'spec defines the desired characteristics of a snapshot requested by a user. More info: https://kubernetes.io/docs/concepts/storage/volume-snapshots#volumesnapshots Required.'
properties:
source:
description: source specifies where a snapshot will be created from. This field is immutable after creation. Required.
properties:
persistentVolumeClaimName:
description: persistentVolumeClaimName specifies the name of the PersistentVolumeClaim object representing the volume from which a snapshot should be created. This PVC is assumed to be in the same namespace as the VolumeSnapshot object. This field should be set if the snapshot does not exists, and needs to be created. This field is immutable.
type: string
volumeSnapshotContentName:
description: volumeSnapshotContentName specifies the name of a pre-existing VolumeSnapshotContent object representing an existing volume snapshot. This field should be set if the snapshot already exists and only needs a representation in Kubernetes. This field is immutable.
type: string
type: object
volumeSnapshotClassName:
description: 'VolumeSnapshotClassName is the name of the VolumeSnapshotClass requested by the VolumeSnapshot. VolumeSnapshotClassName may be left nil to indicate that the default SnapshotClass should be used. A given cluster may have multiple default Volume SnapshotClasses: one default per CSI Driver. If a VolumeSnapshot does not specify a SnapshotClass, VolumeSnapshotSource will be checked to figure out what the associated CSI Driver is, and the default VolumeSnapshotClass associated with that CSI Driver will be used. If more than one VolumeSnapshotClass exist for a given CSI Driver and more than one have been marked as default, CreateSnapshot will fail and generate an event. Empty string is not allowed for this field.'
type: string
required:
- source
type: object
status:
description: status represents the current information of a snapshot. Consumers must verify binding between VolumeSnapshot and VolumeSnapshotContent objects is successful (by validating that both VolumeSnapshot and VolumeSnapshotContent point at each other) before using this object.
properties:
boundVolumeSnapshotContentName:
description: 'boundVolumeSnapshotContentName is the name of the VolumeSnapshotContent object to which this VolumeSnapshot object intends to bind to. If not specified, it indicates that the VolumeSnapshot object has not been successfully bound to a VolumeSnapshotContent object yet. NOTE: To avoid possible security issues, consumers must verify binding between VolumeSnapshot and VolumeSnapshotContent objects is successful (by validating that both VolumeSnapshot and VolumeSnapshotContent point at each other) before using this object.'
type: string
creationTime:
description: creationTime is the timestamp when the point-in-time snapshot is taken by the underlying storage system. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "creation_time" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "creation_time" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. If not specified, it may indicate that the creation time of the snapshot is unknown.
format: date-time
type: string
error:
description: error is the last observed error during snapshot creation, if any. This field could be helpful to upper level controllers(i.e., application controller) to decide whether they should continue on waiting for the snapshot to be created based on the type of error reported. The snapshot controller will keep retrying when an error occurrs during the snapshot creation. Upon success, this error field will be cleared.
properties:
message:
description: 'message is a string detailing the encountered error during snapshot creation if specified. NOTE: message may be logged, and it should not contain sensitive information.'
type: string
time:
description: time is the timestamp when the error was encountered.
format: date-time
type: string
type: object
readyToUse:
description: readyToUse indicates if the snapshot is ready to be used to restore a volume. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "ready_to_use" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "ready_to_use" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it, otherwise, this field will be set to "True". If not specified, it means the readiness of a snapshot is unknown.
type: boolean
restoreSize:
type: string
description: restoreSize represents the minimum size of volume required to create a volume from this snapshot. In dynamic snapshot creation case, this field will be filled in by the snapshot controller with the "size_bytes" value returned from CSI "CreateSnapshot" gRPC call. For a pre-existing snapshot, this field will be filled with the "size_bytes" value returned from the CSI "ListSnapshots" gRPC call if the driver supports it. When restoring a volume from this snapshot, the size of the volume MUST NOT be smaller than the restoreSize if it is specified, otherwise the restoration will fail. If not specified, it indicates that the size is unknown.
pattern: ^(\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))(([KMGTPE]i)|[numkMGTPE]|([eE](\+|-)?(([0-9]+(\.[0-9]*)?)|(\.[0-9]+))))?$
x-kubernetes-int-or-string: true
type: object
required:
- spec
type: object
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
served: true
storage: true
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
subresources:
status: {}
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
---
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
##############################################
########### ############
########### Controller plugin ############
########### ############
##############################################
kind: ServiceAccount
apiVersion: v1
metadata:
name: openebs-zfs-controller-sa
namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-provisioner-role
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
feat(analytics): adding google analytics for ZFSPV Whenever a volume is provisioned and de-provisioned we will send a google event with mainly following details : 1. pvName (will shown as app title in google analytics) 2. size of the volume 3. event type : volume-provision, volume-deprovision 4. storage type zfs-localpv 5. replicacount as 1 6. ClientId as default namespace uuid Apart from this, we send the event once in 24 hr, which will have some info like number of nodes, node type, kubernetes version etc. This metric is cotrolled by OPENEBS_IO_ENABLE_ANALYTICS env. We can set it to false if we don't want to send the metrics. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-26 11:31:24 +05:30
- apiGroups: [""]
resources: ["namespaces"]
verbs: ["*"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- apiGroups: [""]
resources: ["persistentvolumes", "services"]
feat(resize): adding Online volume expansion support for ZFSPV We can resize the volume by updating the PVC yaml to the desired size and apply it. The ZFS Driver will take care of updating the quota in case of dataset. If we are using a Zvol and have mounted it as ext4 or xfs filesystem, the driver will take care of expanding the volume via reize2fs/xfs_growfs binaries. For resize, storageclass that provisions the pvc must suppo rt resize. We should have allowVolumeExpansion as true in storageclass ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-02 12:03:03 +05:30
verbs: ["get", "list", "watch", "create", "delete", "update", "patch"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
feat(resize): adding Online volume expansion support for ZFSPV We can resize the volume by updating the PVC yaml to the desired size and apply it. The ZFS Driver will take care of updating the quota in case of dataset. If we are using a Zvol and have mounted it as ext4 or xfs filesystem, the driver will take care of expanding the volume via reize2fs/xfs_growfs binaries. For resize, storageclass that provisions the pvc must suppo rt resize. We should have allowVolumeExpansion as true in storageclass ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-02 12:03:03 +05:30
- apiGroups: [""]
resources: ["persistentvolumeclaims/status"]
verbs: ["update", "patch"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses", "csinodes"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["list", "watch", "create", "update", "patch"]
feat(HA): adding support to have controller in HA We can have more than one controller in the system, but only one will be the master and others will be slave. Once master is down, one of the slave will take over via lease mechanism and start provisioning/deprovisioning the volumes. Signed-off-by: Pawan <pawan@mayadata.io>
2019-12-31 16:54:50 +05:30
- apiGroups: ["coordination.k8s.io"]
resources: ["leases"]
verbs: ["get", "watch", "list", "delete", "update", "create"]
feat(attach): avoid creation of volumeattachment object k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object. (k8s issue https://github.com/kubernetes/kubernetes/issues/84169) The volumeattachment is not required for ZFSPV, so avoid creation of attachment object, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object : k8s issue https://github.com/kubernetes/kubernetes/issues/84169). Volumeattachment is a CR created just to tell the watcher of it which is csi-attacher, that it has to call the Controller Publish/Unpublish grpc. Which does all the tasks to attach the volumes to a node for example call to the DigitalOcean Block Storage API service to attach a created volume to a specified node. Since for ZFSPV, volume is already present locally, nothing needs to done in Controller Publish/Unpublish, so it is good to remove them. so avoiding creation of attachment object in this change, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. Removed csi-cluster-driver-registrar container also as it is deprecated and not needed anymore. We are using csidriver beta CRDs so minimum k8s version required is 1.14+. Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-17 13:59:28 +05:30
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch", "update", "patch"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- apiGroups: ["*"]
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
resources: ["zfsvolumes", "zfssnapshots", "zfsbackups", "zfsrestores"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
verbs: ["*"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-provisioner-binding
subjects:
- kind: ServiceAccount
name: openebs-zfs-controller-sa
namespace: kube-system
roleRef:
kind: ClusterRole
name: openebs-zfs-provisioner-role
apiGroup: rbac.authorization.k8s.io
---
kind: StatefulSet
adding topology support for zfspv (#7) This PR adds support to allow the CSI driver to pick up a node matching the topology specified in the storage class. Admin can specify allowedTopologies in the StorageClass to specify the nodes where the zfs pools are setup ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "zfspv-pool" provisioner: zfs-localpv volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: kubernetes.io/hostname values: - gke-zfspv-pawan-default-pool-c8929518-cgd4 - gke-zfspv-pawan-default-pool-c8929518-dxzc ``` Note: This PR picks up the first node from the list of nodes available. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-01 06:46:04 +05:30
apiVersion: apps/v1
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
metadata:
name: openebs-zfs-controller
namespace: kube-system
feat(upgrade): support parallel/faster upgrades for node daemonset For ZFSPV, all the node daemonset pods can go into the terminating state at the same time since it does not need any minimum availability of those pods. Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset pods parallelly. Signed-off-by: Pawan <pawan@mayadata.io>
2020-10-20 13:55:34 +05:30
labels:
openebs.io/component-name: openebs-zfs-controller
openebs.io/version: ci
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
spec:
selector:
matchLabels:
app: openebs-zfs-controller
role: openebs-zfs
serviceName: "openebs-zfs"
feat(HA): adding antiaffinity in the controller deployment so that no two pods get scheduled on the same node. Also keeping the default replica to 1, if HA feature is required, we can change replica count to 2(or more). Signed-off-by: Pawan <pawan@mayadata.io>
2020-01-06 12:48:02 +05:30
replicas: 1
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
template:
metadata:
labels:
app: openebs-zfs-controller
role: openebs-zfs
feat(upgrade): support parallel/faster upgrades for node daemonset For ZFSPV, all the node daemonset pods can go into the terminating state at the same time since it does not need any minimum availability of those pods. Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset pods parallelly. Signed-off-by: Pawan <pawan@mayadata.io>
2020-10-20 13:55:34 +05:30
openebs.io/component-name: openebs-zfs-controller
openebs.io/version: ci
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
spec:
feat(HA): adding antiaffinity in the controller deployment so that no two pods get scheduled on the same node. Also keeping the default replica to 1, if HA feature is required, we can change replica count to 2(or more). Signed-off-by: Pawan <pawan@mayadata.io>
2020-01-06 12:48:02 +05:30
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- openebs-zfs-controller
topologyKey: "kubernetes.io/hostname"
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
priorityClassName: system-cluster-critical
serviceAccount: openebs-zfs-controller-sa
containers:
feat(resize): adding Online volume expansion support for ZFSPV We can resize the volume by updating the PVC yaml to the desired size and apply it. The ZFS Driver will take care of updating the quota in case of dataset. If we are using a Zvol and have mounted it as ext4 or xfs filesystem, the driver will take care of expanding the volume via reize2fs/xfs_growfs binaries. For resize, storageclass that provisions the pvc must suppo rt resize. We should have allowVolumeExpansion as true in storageclass ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-02 12:03:03 +05:30
- name: csi-resizer
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
image: quay.io/k8scsi/csi-resizer:v1.1.0
feat(resize): adding Online volume expansion support for ZFSPV We can resize the volume by updating the PVC yaml to the desired size and apply it. The ZFS Driver will take care of updating the quota in case of dataset. If we are using a Zvol and have mounted it as ext4 or xfs filesystem, the driver will take care of expanding the volume via reize2fs/xfs_growfs binaries. For resize, storageclass that provisions the pvc must suppo rt resize. We should have allowVolumeExpansion as true in storageclass ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: poolname: "zfspv-pool" provisioner: zfs.csi.openebs.io ``` Signed-off-by: Pawan <pawan@mayadata.io>
2020-03-02 12:03:03 +05:30
args:
- "--v=5"
- "--csi-address=$(ADDRESS)"
- "--leader-election"
env:
- name: ADDRESS
value: /var/lib/csi/sockets/pluginproxy/csi.sock
imagePullPolicy: IfNotPresent
volumeMounts:
- name: socket-dir
mountPath: /var/lib/csi/sockets/pluginproxy/
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
- name: csi-snapshotter
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
image: quay.io/k8scsi/csi-snapshotter:v4.0.0
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
imagePullPolicy: IfNotPresent
args:
- "--csi-address=$(ADDRESS)"
- "--leader-election"
env:
- name: ADDRESS
value: /var/lib/csi/sockets/pluginproxy/csi.sock
volumeMounts:
- name: socket-dir
mountPath: /var/lib/csi/sockets/pluginproxy/
- name: snapshot-controller
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
image: quay.io/k8scsi/snapshot-controller:v4.0.0
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
args:
- "--v=5"
feat(attach): avoid creation of volumeattachment object k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object. (k8s issue https://github.com/kubernetes/kubernetes/issues/84169) The volumeattachment is not required for ZFSPV, so avoid creation of attachment object, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. k8s is very slow in attaching the volumes when dealing with the large number of volume attachment object : k8s issue https://github.com/kubernetes/kubernetes/issues/84169). Volumeattachment is a CR created just to tell the watcher of it which is csi-attacher, that it has to call the Controller Publish/Unpublish grpc. Which does all the tasks to attach the volumes to a node for example call to the DigitalOcean Block Storage API service to attach a created volume to a specified node. Since for ZFSPV, volume is already present locally, nothing needs to done in Controller Publish/Unpublish, so it is good to remove them. so avoiding creation of attachment object in this change, also removed the csi-attacher container as this is also not needed as it acts on volumeattachment object. Removed csi-cluster-driver-registrar container also as it is deprecated and not needed anymore. We are using csidriver beta CRDs so minimum k8s version required is 1.14+. Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-17 13:59:28 +05:30
- "--leader-election=true"
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
imagePullPolicy: IfNotPresent
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- name: csi-provisioner
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
image: quay.io/k8scsi/csi-provisioner:v2.1.0
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
imagePullPolicy: IfNotPresent
args:
- "--csi-address=$(ADDRESS)"
- "--v=5"
- "--feature-gates=Topology=true"
adding topology support for zfspv (#7) This PR adds support to allow the CSI driver to pick up a node matching the topology specified in the storage class. Admin can specify allowedTopologies in the StorageClass to specify the nodes where the zfs pools are setup ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "zfspv-pool" provisioner: zfs-localpv volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: kubernetes.io/hostname values: - gke-zfspv-pawan-default-pool-c8929518-cgd4 - gke-zfspv-pawan-default-pool-c8929518-dxzc ``` Note: This PR picks up the first node from the list of nodes available. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-01 06:46:04 +05:30
- "--strict-topology"
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
- "--leader-election"
feat(usage): include pvc name in volume events Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-07 16:58:44 +05:30
- "--extra-create-metadata=true"
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
env:
- name: ADDRESS
value: /var/lib/csi/sockets/pluginproxy/csi.sock
volumeMounts:
- name: socket-dir
mountPath: /var/lib/csi/sockets/pluginproxy/
- name: openebs-zfs-plugin
chore(yaml): changing the zfs-driver images to multi-arch docker hub images (#237) Signed-off-by: Aman Gupta <aman.gupta@mayadata.io>
2020-11-14 12:44:38 +05:30
image: openebs/zfs-driver:ci
fix(zfspv): changing image pull policy to IfNotPresent to make it not pull the image all the time. Also, it needed so that while doing integration test, it uses the local image we just build, instead of fetching the image from the dockerhub or quay so that we can run ci on the locally built image. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-28 15:52:49 +05:30
imagePullPolicy: IfNotPresent
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
env:
- name: OPENEBS_CONTROLLER_DRIVER
value: controller
- name: OPENEBS_CSI_ENDPOINT
value: unix:///var/lib/csi/sockets/pluginproxy/csi.sock
- name: OPENEBS_NAMESPACE
value: openebs
feat(analytics): adding google analytics for ZFSPV Whenever a volume is provisioned and de-provisioned we will send a google event with mainly following details : 1. pvName (will shown as app title in google analytics) 2. size of the volume 3. event type : volume-provision, volume-deprovision 4. storage type zfs-localpv 5. replicacount as 1 6. ClientId as default namespace uuid Apart from this, we send the event once in 24 hr, which will have some info like number of nodes, node type, kubernetes version etc. This metric is cotrolled by OPENEBS_IO_ENABLE_ANALYTICS env. We can set it to false if we don't want to send the metrics. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-26 11:31:24 +05:30
- name: OPENEBS_IO_INSTALLER_TYPE
value: "zfs-operator"
- name: OPENEBS_IO_ENABLE_ANALYTICS
value: "true"
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
args :
- "--endpoint=$(OPENEBS_CSI_ENDPOINT)"
- "--plugin=$(OPENEBS_CONTROLLER_DRIVER)"
volumeMounts:
- name: socket-dir
mountPath: /var/lib/csi/sockets/pluginproxy/
volumes:
- name: socket-dir
emptyDir: {}
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-snapshotter-role
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "list"]
- apiGroups: ["snapshot.storage.k8s.io"]
resources: ["volumesnapshotclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: ["snapshot.storage.k8s.io"]
resources: ["volumesnapshotcontents"]
verbs: ["create", "get", "list", "watch", "update", "delete"]
- apiGroups: ["snapshot.storage.k8s.io"]
resources: ["volumesnapshots"]
verbs: ["get", "list", "watch", "update"]
feat(zfspv): adding snapshot and clone support for ZFSPV (#39) This commits support snapshot and clone commands via CSI driver. User can create snap and clone using the following steps. Note: - Snapshot is created via reconciliation CR - Cloned volume will be on the same zpool where the snapshot is taken - Cloned volume will have same properties as source volume. ----------------------------------- Create a Snapshotclass ``` kind: VolumeSnapshotClass apiVersion: snapshot.storage.k8s.io/v1beta1 metadata: name: zfspv-snapclass annotations: snapshot.storage.kubernetes.io/is-default-class: "true" driver: zfs.csi.openebs.io deletionPolicy: Delete ``` Once snapshotclass is created, we can use this class to create a Snapshot ``` apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: name: zfspv-snap spec: volumeSnapshotClassName: zfspv-snapclass source: persistentVolumeClaimName: csi-zfspv ``` ``` $ kubectl get volumesnapshot NAME AGE zfspv-snap 7m52s ``` ``` $ kubectl get volumesnapshot -o yaml apiVersion: v1 items: - apiVersion: snapshot.storage.k8s.io/v1beta1 kind: VolumeSnapshot metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"snapshot.storage.k8s.io/v1beta1","kind":"VolumeSnapshot","metadata":{"annotations":{},"name":"zfspv-snap","namespace":"default"},"spec":{"source":{"persistentVolumeClaimName":"csi-zfspv"},"volumeSnapshotClassName":"zfspv-snapclass"}} creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection - snapshot.storage.kubernetes.io/volumesnapshot-bound-protection generation: 1 name: zfspv-snap namespace: default resourceVersion: "30040" selfLink: /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/zfspv-snap uid: 1a5cf166-c599-4f58-9f3c-f1148be47fca spec: source: persistentVolumeClaimName: csi-zfspv volumeSnapshotClassName: zfspv-snapclass status: boundVolumeSnapshotContentName: snapcontent-1a5cf166-c599-4f58-9f3c-f1148be47fca creationTime: "2020-01-30T10:31:24Z" readyToUse: true restoreSize: "0" kind: List metadata: resourceVersion: "" selfLink: "" ``` Openebs resource for the created snapshot ``` $ kubectl get snap -n openebs -o yaml apiVersion: v1 items: - apiVersion: openebs.io/v1alpha1 kind: ZFSSnapshot metadata: creationTimestamp: "2020-01-30T10:31:24Z" finalizers: - zfs.openebs.io/finalizer generation: 2 labels: kubernetes.io/nodename: pawan-2 openebs.io/persistent-volume: pvc-18cab7c3-ec5e-4264-8507-e6f7df4c789a name: snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca namespace: openebs resourceVersion: "30035" selfLink: /apis/openebs.io/v1alpha1/namespaces/openebs/zfssnapshots/snapshot-1a5cf166-c599-4f58-9f3c-f1148be47fca uid: e29d571c-42b5-4fb7-9110-e1cfc9b96641 spec: capacity: "4294967296" fsType: zfs ownerNodeID: pawan-2 poolName: zfspv-pool status: Ready volumeType: DATASET kind: List metadata: resourceVersion: "" selfLink: "" ``` Create a clone volume We can provide a datasource as snapshot name to create a clone volume ```yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: zfspv-clone spec: storageClassName: openebs-zfspv dataSource: name: zfspv-snap kind: VolumeSnapshot apiGroup: snapshot.storage.k8s.io accessModes: - ReadWriteOnce resources: requests: storage: 4Gi ``` It will create a ZFS clone volume from the mentioned snapshot and create the PV on the same node where original volume is there. Here, As resize is not supported yet, the clone PVC size should match the size of the snapshot. Also, all the properties from the storageclass will not be considered for the clone case, it will take the properties from the snapshot and create the clone volume. One thing to note here is that, the storageclass in clone PVC should have the same poolname as that of the original volume as across the pool, clone is not supported. Signed-off-by: Pawan <pawan@mayadata.io>
2020-02-13 13:31:17 +05:30
- apiGroups: ["snapshot.storage.k8s.io"]
resources: ["volumesnapshotcontents/status"]
verbs: ["update"]
- apiGroups: ["snapshot.storage.k8s.io"]
resources: ["volumesnapshots/status"]
verbs: ["update"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- apiGroups: ["apiextensions.k8s.io"]
resources: ["customresourcedefinitions"]
verbs: ["create", "list", "watch", "delete"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-snapshotter-binding
subjects:
- kind: ServiceAccount
name: openebs-zfs-controller-sa
namespace: kube-system
roleRef:
kind: ClusterRole
name: openebs-zfs-snapshotter-role
apiGroup: rbac.authorization.k8s.io
---
########################################
########### ############
########### Node plugin ############
########### ############
########################################
apiVersion: v1
kind: ServiceAccount
metadata:
name: openebs-zfs-node-sa
namespace: kube-system
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-driver-registrar-role
rules:
- apiGroups: [""]
resources: ["events"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
resources: ["persistentvolumes", "nodes", "services"]
verbs: ["get", "list"]
- apiGroups: ["*"]
feat(zfspv): adding backup and restore support (#162) This commit adds support for Backup and Restore controller, which will be watching for the events. The velero plugin will create a Backup CR to create a backup with the remote location information, the controller will send the data to that remote location. In the same way, the velero plugin will create a Restore CR to restore the volume from the the remote location and the restore controller will restore the data. Steps to use velero plugin for ZFS-LocalPV are : 1. install velero 2. add openebs plugin velero plugin add openebs/velero-plugin:latest 3. Create the volumesnapshot location : for full backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` for incremental backup :- ```yaml apiVersion: velero.io/v1 kind: VolumeSnapshotLocation metadata: name: default namespace: velero spec: provider: openebs.io/zfspv-blockstore config: bucket: velero prefix: zfs backup: incremental namespace: openebs provider: aws region: minio s3ForcePathStyle: "true" s3Url: http://minio.velero.svc:9000 ``` 4. Create backup velero backup create my-backup --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-cloud-default --storage-location=default 5. Create Schedule velero create schedule newschedule --schedule="*/1 * * * *" --snapshot-volumes --include-namespaces=velero-ns --volume-snapshot-locations=aws-local-default --storage-location=default 6. Restore from backup velero restore create --from-backup my-backup --restore-volumes=true --namespace-mappings velero-ns:ns1 Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-08 13:44:39 +05:30
resources: ["zfsvolumes", "zfssnapshots", "zfsbackups", "zfsrestores"]
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: openebs-zfs-driver-registrar-binding
subjects:
- kind: ServiceAccount
name: openebs-zfs-node-sa
namespace: kube-system
roleRef:
kind: ClusterRole
name: openebs-zfs-driver-registrar-role
apiGroup: rbac.authorization.k8s.io
---
feat(zfspv): mounting the root filesystem to remove the dependency on the Operating system (#204) * feat(zfspv): mounting the root filesystem to remove the dependency on the OS We are mounting the individual library to run the zfs binary inside the ZFS-LocalPV daemonset. The problem with this is each OS has different sets of libraries. We need to have different Operator yamls for different OS versions. Here we are mounting the root directory inside the ZFS-LocalPV daemonset Pod which does chroot to this path and run the command. As all the libraries will be available which are present on the host inside the Pod, so we don't need to mount each library here and also it will work for all the Operating systems. To be on the safe side, we are mounting the host's root directory as Readonly filesystem. Signed-off-by: Pawan <pawan@mayadata.io> * adding comment for namespace Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-07 21:12:31 +05:30
kind: ConfigMap
apiVersion: v1
metadata:
name: openebs-zfspv-bin
namespace: kube-system # should be the same namespace where it is getting mounted
data:
zfs: |
#!/bin/sh
if [ -x /host/sbin/zfs ]; then
chroot /host /sbin/zfs "$@"
elif [ -x /host/usr/sbin/zfs ]; then
chroot /host /usr/sbin/zfs "$@"
else
chroot /host zfs "$@"
fi
---
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
kind: DaemonSet
adding topology support for zfspv (#7) This PR adds support to allow the CSI driver to pick up a node matching the topology specified in the storage class. Admin can specify allowedTopologies in the StorageClass to specify the nodes where the zfs pools are setup ```yaml apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" poolname: "zfspv-pool" provisioner: zfs-localpv volumeBindingMode: WaitForFirstConsumer allowedTopologies: - matchLabelExpressions: - key: kubernetes.io/hostname values: - gke-zfspv-pawan-default-pool-c8929518-cgd4 - gke-zfspv-pawan-default-pool-c8929518-dxzc ``` Note: This PR picks up the first node from the list of nodes available. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-01 06:46:04 +05:30
apiVersion: apps/v1
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
metadata:
name: openebs-zfs-node
namespace: kube-system
feat(upgrade): support parallel/faster upgrades for node daemonset For ZFSPV, all the node daemonset pods can go into the terminating state at the same time since it does not need any minimum availability of those pods. Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset pods parallelly. Signed-off-by: Pawan <pawan@mayadata.io>
2020-10-20 13:55:34 +05:30
labels:
openebs.io/component-name: openebs-zfs-node
openebs.io/version: ci
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
spec:
selector:
matchLabels:
app: openebs-zfs-node
feat(upgrade): support parallel/faster upgrades for node daemonset For ZFSPV, all the node daemonset pods can go into the terminating state at the same time since it does not need any minimum availability of those pods. Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset pods parallelly. Signed-off-by: Pawan <pawan@mayadata.io>
2020-10-20 13:55:34 +05:30
updateStrategy:
rollingUpdate:
maxUnavailable: 100%
type: RollingUpdate
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
template:
metadata:
labels:
app: openebs-zfs-node
role: openebs-zfs
feat(upgrade): support parallel/faster upgrades for node daemonset For ZFSPV, all the node daemonset pods can go into the terminating state at the same time since it does not need any minimum availability of those pods. Changing maxUnavailable to 100% so that K8s can upgrade all the daemonset pods parallelly. Signed-off-by: Pawan <pawan@mayadata.io>
2020-10-20 13:55:34 +05:30
openebs.io/component-name: openebs-zfs-node
openebs.io/version: ci
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
spec:
priorityClassName: system-node-critical
serviceAccount: openebs-zfs-node-sa
hostNetwork: true
containers:
- name: csi-node-driver-registrar
chore(operator): bump k8s csi to latest stable container images (#271) Signed-off-by: shubham <shubham.bajpai@mayadata.io>
2021-01-05 23:42:20 +05:30
image: quay.io/k8scsi/csi-node-driver-registrar:v2.1.0
fix(zfspv): changing image pull policy to IfNotPresent Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-20 19:29:09 +05:30
imagePullPolicy: IfNotPresent
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
args:
- "--v=5"
- "--csi-address=$(ADDRESS)"
- "--kubelet-registration-path=$(DRIVER_REG_SOCK_PATH)"
lifecycle:
preStop:
exec:
command: ["/bin/sh", "-c", "rm -rf /registration/zfs-localpv /registration/zfs-localpv-reg.sock"]
env:
- name: ADDRESS
value: /plugin/csi.sock
- name: DRIVER_REG_SOCK_PATH
value: /var/lib/kubelet/plugins/zfs-localpv/csi.sock
- name: KUBE_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: NODE_DRIVER
value: openebs-zfs
volumeMounts:
- name: plugin-dir
mountPath: /plugin
- name: registration-dir
mountPath: /registration
- name: openebs-zfs-plugin
securityContext:
privileged: true
allowPrivilegeEscalation: true
chore(yaml): changing the zfs-driver images to multi-arch docker hub images (#237) Signed-off-by: Aman Gupta <aman.gupta@mayadata.io>
2020-11-14 12:44:38 +05:30
image: openebs/zfs-driver:ci
fix(zfspv): changing image pull policy to IfNotPresent to make it not pull the image all the time. Also, it needed so that while doing integration test, it uses the local image we just build, instead of fetching the image from the dockerhub or quay so that we can run ci on the locally built image. Signed-off-by: Pawan <pawan@mayadata.io>
2019-11-28 15:52:49 +05:30
imagePullPolicy: IfNotPresent
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
args:
- "--nodeid=$(OPENEBS_NODE_ID)"
- "--endpoint=$(OPENEBS_CSI_ENDPOINT)"
- "--plugin=$(OPENEBS_NODE_DRIVER)"
env:
- name: OPENEBS_NODE_ID
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: OPENEBS_CSI_ENDPOINT
value: unix:///plugin/csi.sock
- name: OPENEBS_NODE_DRIVER
value: agent
- name: OPENEBS_NAMESPACE
value: openebs
volumeMounts:
- name: plugin-dir
mountPath: /plugin
- name: device-dir
mountPath: /dev
feat(ZFSPV): adding encryption in ZFSVolume CR (#6) Adding support for enabling encryption using a custom key. Also, adding support to inherit the properties from ZPOOL which are not listed in the storage class, ZFS driver will not pass default values while creating the volume. Those properties will be inherited from the ZPOOL. we can use the encryption option in storage class ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" encryption: "on" keyformat: "raw" keylocation: "file:///home/keys/key" poolname: "zfspv-pool" provisioner: openebs.io/zfs ``` Just a note, the key file should be mounted inside the node-agent container so that we can use that file while provisioning the volume. keyformat can be raw, hex or passphrase. Signed-off-by: Pawan <pawan@mayadata.io>
2019-10-15 22:51:48 +05:30
- name: encr-keys
mountPath: /home/keys
feat(zfspv): mounting the root filesystem to remove the dependency on the Operating system (#204) * feat(zfspv): mounting the root filesystem to remove the dependency on the OS We are mounting the individual library to run the zfs binary inside the ZFS-LocalPV daemonset. The problem with this is each OS has different sets of libraries. We need to have different Operator yamls for different OS versions. Here we are mounting the root directory inside the ZFS-LocalPV daemonset Pod which does chroot to this path and run the command. As all the libraries will be available which are present on the host inside the Pod, so we don't need to mount each library here and also it will work for all the Operating systems. To be on the safe side, we are mounting the host's root directory as Readonly filesystem. Signed-off-by: Pawan <pawan@mayadata.io> * adding comment for namespace Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-07 21:12:31 +05:30
- name: chroot-zfs
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
mountPath: /sbin/zfs
feat(zfspv): mounting the root filesystem to remove the dependency on the Operating system (#204) * feat(zfspv): mounting the root filesystem to remove the dependency on the OS We are mounting the individual library to run the zfs binary inside the ZFS-LocalPV daemonset. The problem with this is each OS has different sets of libraries. We need to have different Operator yamls for different OS versions. Here we are mounting the root directory inside the ZFS-LocalPV daemonset Pod which does chroot to this path and run the command. As all the libraries will be available which are present on the host inside the Pod, so we don't need to mount each library here and also it will work for all the Operating systems. To be on the safe side, we are mounting the host's root directory as Readonly filesystem. Signed-off-by: Pawan <pawan@mayadata.io> * adding comment for namespace Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-07 21:12:31 +05:30
subPath: zfs
- name: host-root
mountPath: /host
mountPropagation: "HostToContainer"
readOnly: true
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- name: pods-mount-dir
feat(block): adding block volume support for ZFSPV (#102) This commit adds the support for creating a Raw Block Volume request using volumemode as block in PVC :- ``` kind: PersistentVolumeClaim apiVersion: v1 metadata: name: block-claim spec: volumeMode: Block storageClassName: zfspv-block accessModes: - ReadWriteOnce resources: requests: storage: 5Gi ``` The driver will create a zvol for this volume and bind mount the block device at the given path. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-05 12:28:46 +05:30
mountPath: /var/lib/kubelet/
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
# needed so that any mounts setup inside this container are
# propagated back to the host machine.
mountPropagation: "Bidirectional"
volumes:
- name: device-dir
hostPath:
path: /dev
type: Directory
feat(ZFSPV): adding encryption in ZFSVolume CR (#6) Adding support for enabling encryption using a custom key. Also, adding support to inherit the properties from ZPOOL which are not listed in the storage class, ZFS driver will not pass default values while creating the volume. Those properties will be inherited from the ZPOOL. we can use the encryption option in storage class ``` apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: openebs-zfspv allowVolumeExpansion: true parameters: blocksize: "4k" compression: "on" dedup: "on" thinprovision: "yes" encryption: "on" keyformat: "raw" keylocation: "file:///home/keys/key" poolname: "zfspv-pool" provisioner: openebs.io/zfs ``` Just a note, the key file should be mounted inside the node-agent container so that we can use that file while provisioning the volume. keyformat can be raw, hex or passphrase. Signed-off-by: Pawan <pawan@mayadata.io>
2019-10-15 22:51:48 +05:30
- name: encr-keys
hostPath:
path: /home/keys
type: DirectoryOrCreate
feat(zfspv): mounting the root filesystem to remove the dependency on the Operating system (#204) * feat(zfspv): mounting the root filesystem to remove the dependency on the OS We are mounting the individual library to run the zfs binary inside the ZFS-LocalPV daemonset. The problem with this is each OS has different sets of libraries. We need to have different Operator yamls for different OS versions. Here we are mounting the root directory inside the ZFS-LocalPV daemonset Pod which does chroot to this path and run the command. As all the libraries will be available which are present on the host inside the Pod, so we don't need to mount each library here and also it will work for all the Operating systems. To be on the safe side, we are mounting the host's root directory as Readonly filesystem. Signed-off-by: Pawan <pawan@mayadata.io> * adding comment for namespace Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-07 21:12:31 +05:30
- name: chroot-zfs
configMap:
defaultMode: 0555
name: openebs-zfspv-bin
- name: host-root
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
hostPath:
feat(zfspv): mounting the root filesystem to remove the dependency on the Operating system (#204) * feat(zfspv): mounting the root filesystem to remove the dependency on the OS We are mounting the individual library to run the zfs binary inside the ZFS-LocalPV daemonset. The problem with this is each OS has different sets of libraries. We need to have different Operator yamls for different OS versions. Here we are mounting the root directory inside the ZFS-LocalPV daemonset Pod which does chroot to this path and run the command. As all the libraries will be available which are present on the host inside the Pod, so we don't need to mount each library here and also it will work for all the Operating systems. To be on the safe side, we are mounting the host's root directory as Readonly filesystem. Signed-off-by: Pawan <pawan@mayadata.io> * adding comment for namespace Signed-off-by: Pawan <pawan@mayadata.io>
2020-09-07 21:12:31 +05:30
path: /
type: Directory
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
- name: registration-dir
hostPath:
path: /var/lib/kubelet/plugins_registry/
type: DirectoryOrCreate
- name: plugin-dir
hostPath:
path: /var/lib/kubelet/plugins/zfs-localpv/
type: DirectoryOrCreate
- name: pods-mount-dir
hostPath:
feat(block): adding block volume support for ZFSPV (#102) This commit adds the support for creating a Raw Block Volume request using volumemode as block in PVC :- ``` kind: PersistentVolumeClaim apiVersion: v1 metadata: name: block-claim spec: volumeMode: Block storageClassName: zfspv-block accessModes: - ReadWriteOnce resources: requests: storage: 5Gi ``` The driver will create a zvol for this volume and bind mount the block device at the given path. Signed-off-by: Pawan <pawan@mayadata.io>
2020-05-05 12:28:46 +05:30
path: /var/lib/kubelet/
feat(zfs-localpv): initial commit provisioning and deprovisioning of the volumes on the node where zfs pool has already been setup. Pool name and the volume parameters has to be given in storage class which will be used to provision the volume. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-12 12:32:17 +05:30
type: Directory
---
Reference in a new issue Copy permalink