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

1675 lines
75 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 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
volumeLifecycleModes:
- Persistent
---
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:
annotations:
controller-gen.kubebuilder.io/version: (devel)
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/139"
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
#preserveUnknownFields: false # this field is supported in kubernetes 1.15+ https://v1-15.docs.kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
validation:
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/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/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
version: v1beta1
versions:
- name: v1beta1
served: true
storage: true
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
---
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:
annotations:
controller-gen.kubebuilder.io/version: (devel)
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/139"
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
subresources:
status: {}
#preserveUnknownFields: false # this field is supported in kubernetes 1.15+ https://v1-15.docs.kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
validation:
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/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
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. In dynamic snapshot creation
case, this field will be filled in with the "DeletionPolicy" field
defined in the VolumeSnapshotClass the VolumeSnapshot refers to. 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 from where a snapshot will be created.
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. 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 to which this snapshot
belongs.
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/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/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 with the "creation_time" value
returned from CSI "CreateSnapshotRequest" 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 latest observed error during snapshot creation,
if any.
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 with the "ready_to_use" value returned from CSI
"CreateSnapshotRequest" 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 with the "size_bytes" value returned from CSI "CreateSnapshotRequest"
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
version: v1beta1
versions:
- name: v1beta1
served: true
storage: true
status:
acceptedNames:
kind: ""
plural: ""
conditions: []
storedVersions: []
---
apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
annotations:
controller-gen.kubebuilder.io/version: (devel)
api-approved.kubernetes.io: "https://github.com/kubernetes-csi/external-snapshotter/pull/139"
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
subresources:
status: {}
#preserveUnknownFields: false # this field is supported in kubernetes 1.15+ https://v1-15.docs.kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
validation:
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/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
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 in the same namespace as the VolumeSnapshot
object where the snapshot should be dynamically taken from. This
field is immutable.
type: string
volumeSnapshotContentName:
description: volumeSnapshotContentName specifies the name of a pre-existing
VolumeSnapshotContent object. This field is immutable.
type: string
type: object
volumeSnapshotClassName:
description: 'volumeSnapshotClassName is the name of the VolumeSnapshotClass
requested by the VolumeSnapshot. If not specified, the default snapshot
class will be used if one exists. If not specified, and there is no
default snapshot class, dynamic snapshot creation will fail. Empty
string is not allowed for this field. TODO(xiangqian): a webhook validation
on empty string. More info: https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes'
type: string
required:
- source
type: object
status:
description: 'status represents the current information of a snapshot. NOTE:
status can be modified by sources other than system controllers, and must
not be depended upon for accuracy. Controllers should only use information
from the VolumeSnapshotContent object after verifying that the binding
is accurate and complete.'
properties:
boundVolumeSnapshotContentName:
description: 'boundVolumeSnapshotContentName represents the name of
the VolumeSnapshotContent object to which the VolumeSnapshot object
is bound. If not specified, it indicates that the VolumeSnapshot object
has not been successfully bound to a VolumeSnapshotContent object
yet. NOTE: Specified boundVolumeSnapshotContentName alone does not
mean binding is valid. Controllers MUST always verify bidirectional
binding between VolumeSnapshot and VolumeSnapshotContent to
avoid possible security issues.'
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 with the "creation_time" value
returned from CSI "CreateSnapshotRequest" 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 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.
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 with the "ready_to_use" value returned from CSI
"CreateSnapshotRequest" 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 with the "size_bytes" value returned from CSI "CreateSnapshotRequest"
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.
type: string
type: object
required:
- spec
type: object
version: v1beta1
versions:
- name: v1beta1
served: true
storage: true
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"]
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 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
resources: ["zfsvolumes", "zfssnapshots"]
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
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
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
image: quay.io/k8scsi/csi-resizer:v0.4.0
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
image: quay.io/k8scsi/csi-snapshotter:v2.0.1
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
image: quay.io/k8scsi/snapshot-controller:v2.0.1
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
feat(topology): adding support for custom topology keys (#94) This commit adds the support for use to specify custom labels to the kubernetes nodes and use them in the allowedToplogoies section of the StorageClass. Few notes: - This PR depends on the CSI driver's capability to support custom topology keys. - label on the nodes should be added first and then deploy the driver to make it aware of all the labels that node has. If labels are added after ZFS-LocalPV driver has been deployed, a restart all the node csi driver agents is required so that the driver can pick the labels and add them as supported topology keys. - if storageclass is using Immediate binding mode and topology key is not mentioned then all the nodes should be labeled using same key, that means: - same key should be present on all nodes, nodes can have different values for those keys. - If nodes are labeled with different keys i.e. some nodes are having different keys, then ZFSPV's default scheduler can not effictively do the volume count based scheduling. In this case the CSI provisioner will pick keys from any random node and then prepare the preferred topology list using the nodes which has those keys defined. And ZFSPV scheduler will schedule the PV among those nodes only. Signed-off-by: Pawan <pawan@mayadata.io>
2020-04-30 14:13:29 +05:30
image: quay.io/k8scsi/csi-provisioner:v1.6.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"
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
- "--enable-leader-election"
- "--leader-election-type=leases"
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
Revert "feat(yaml): updating v0.8.0 operator yaml to use 0.8.0 image tag" This reverts commit 2c11af5362285c034ea27d72a5abda078364291f. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-17 18:40:34 +05:30
image: quay.io/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 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
resources: ["zfsvolumes", "zfssnapshots"]
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
---
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
spec:
selector:
matchLabels:
app: openebs-zfs-node
template:
metadata:
labels:
app: openebs-zfs-node
role: openebs-zfs
spec:
priorityClassName: system-node-critical
serviceAccount: openebs-zfs-node-sa
hostNetwork: true
containers:
- name: csi-node-driver-registrar
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
image: quay.io/k8scsi/csi-node-driver-registrar:v1.2.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
capabilities:
add: ["CAP_MKNOD", "CAP_SYS_ADMIN", "SYS_ADMIN"]
allowPrivilegeEscalation: true
Revert "feat(yaml): updating v0.8.0 operator yaml to use 0.8.0 image tag" This reverts commit 2c11af5362285c034ea27d72a5abda078364291f. Signed-off-by: Pawan <pawan@mayadata.io>
2020-06-17 18:40:34 +05:30
image: quay.io/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(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: zfs-bin
mountPath: /sbin/zfs
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzpool
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: /lib/libzpool.so.2
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzfscore
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: /lib/libzfs_core.so.1
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzfs
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: /lib/libzfs.so.2
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libuutil
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: /lib/libuutil.so.1
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libnvpair
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: /lib/libnvpair.so.1
- 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(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: zfs-bin
hostPath:
path: /sbin/zfs
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
type: File
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzpool
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:
path: /lib/libzpool.so.2.0.0
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
type: File
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzfscore
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:
path: /lib/libzfs_core.so.1.0.0
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
type: File
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libzfs
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:
path: /lib/libzfs.so.2.0.0
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
type: File
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libuutil
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:
path: /lib/libuutil.so.1.0.1
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
type: File
bug(zfspv): not able to deploy on rancher with ZFS 0.8. The ZFS 0.8 has dependency on libcrypto.so.1.1 which in turn requires GLIBC_2.25 supported by the system. Changed the docker image to 18:04 as 16:04 has glibc version 2.23. Also updated the README with the supported system details. Signed-off-by: Pawan <pawan@mayadata.io>
2019-09-19 16:58:46 +05:30
- name: libnvpair
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:
path: /lib/libnvpair.so.1.0.1
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
type: File
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