Test PowerFlex CSI Driver

This section provides multiple methods to test driver functionality in your environment.

Note: To run the test for CSI Driver for Dell EMC PowerFlex, install Helm 3.

Test deploying a simple pod with PowerFlex storage

Test the deployment workflow of a simple pod on PowerFlex storage.

Prerequisites

In the source code, there is a directory that contains examples of how you can use the driver. To use these examples, you must create a helmtest-vxflexos namespace, using kubectl create namespace helmtest-vxflexos, before you can start testing. HELM 3 must be installed to perform the tests.

The starttest.sh script is located in the csi-vxflexos/test/helm directory. This script is used in the following procedure to deploy helm charts that test the deployment of a simple pod.

Steps

  1. Navigate to the test/helm directory, which contains the starttest.sh and the 2vols directories. This directory contains a simple Helm chart that will deploy a pod that uses two PowerFlex volumes. NOTE: Helm tests are designed assuming users are using the storageclass names (vxflexos and vxflexos-xfs). If your storageclass names differ from these values, please update the templates in 2vols accordingly (located in test/helm/2vols/templates directory). You can use kubectl get sc to check for the storageclass names.
  2. Run sh starttest.sh 2vols to deploy the pod. You should see the following:
Normal Pulled  38s kubelet, k8s113a-10-247-102-215.lss.emc.com Successfully pulled image "docker.io/centos:latest"
Normal Created 38s kubelet, k8s113a-10-247-102-215.lss.emc.com Created container
Normal Started 38s kubelet, k8s113a-10-247-102-215.lss.emc.com Started container
/dev/scinib 8125880 36852 7653216 1% /data
/dev/scinia 16766976 32944 16734032 1% /data
/dev/scinib on /data0 type ext4 (rw,relatime,data=ordered)
/dev/scinia on /data1 type xfs (rw,relatime,attr2,inode64,noquota)
  1. To stop the test, run sh stoptest.sh 2vols. This script deletes the pods and the volumes depending on the retention setting you have configured.

Results

An outline of this workflow is described below:

  1. The 2vols helm chart contains two PersistentVolumeClaim definitions, one in pvc0.yaml , and the other in pvc1.yaml. They are referenced by the test.yaml which creates the pod. The contents of the Pvc0.yaml file are described below:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pvol
  namespace: helmtest-vxflexos
spec:
  accessModes:
  - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: vxflexos
  1. The volumeMode: Filesystem requires a mounted file system, and the resources.requests.storage of 8Gi requires an 8 GB file. In this case, the storageClassName: vxflexos directs the system to use a storage class named vxflexos. This step yields a mounted ext4 file system. You can create the vxflexos and vxflexos-xfs storage classes by using the yamls located in helm/samples/storageclass.
  2. If you compare pvol0.yaml and pvol1.yaml, you will find that the latter uses a different storage class; vxflexos-xfs. This class gives you an xfs file system.
  3. To see the volumes you created, run kubectl get persistentvolumeclaim –n helmtest-vxflexos and kubectl describe persistentvolumeclaim –n helmtest-vxflexos. NOTE: For more information about Kubernetes objects like StatefulSet and PersistentVolumeClaim see Kubernetes documentation: Concepts.

Test creating snapshots

Test the workflow for snapshot creation.

Steps

  1. Start the 2vols container and leave it running.
    • Helm tests are designed assuming users are using the storageclass names (vxflexos and vxflexos-xfs). If your storageclass names differ from these values, update the templates in 2vols accordingly (located in test/helm/2vols/templates directory). You can use kubectl get sc to check for the storageclass names.
    • Helm tests are designed assuming users are using the snapshotclass name: vxflexos-snapclass If your snapshotclass name differs from the default values, update betasnap1.yaml and betasnap2.yaml accordingly.
  2. Run sh snaptest.sh to start the test.

This will create a snapshot of each of the volumes in the container using VolumeSnapshot objects defined in betasnap1.yaml and betasnap2.yaml. The following are the contents of betasnap1.yaml:

apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
  name: pvol0-snap1
  namespace: helmtest-vxflexos
spec:
  volumeSnapshotClassName: vxflexos-snapclass
  source:
    persistentVolumeClaimName: pvol0

NOTE: apiVersion in both betasnap yamls must match apiVersion in your VolumeSnapshotClass, if version in VolumeSnapshotClass is v1, adjust apiVersion like so: apiVersion: snapshot.storage.k8s.io/v1 in betasnap1.yaml and betasnap2.yaml

Results

The snaptest.sh script will create a snapshot using the definitions in the betasnap1.yaml file. The spec.source section contains the volume that will be snapped. For example, if the volume to be snapped is pvol0, then the created snapshot is named pvol0-snap1.

NOTE: The snaptest.sh shell script creates the snapshots, describes them, and then deletes them. You can see your snapshots using kubectl get volumesnapshot -n helmtest-vxflexos.

Notice that this VolumeSnapshot class has a reference to a snapshotClassName: vxflexos-snapclass. The CSI Driver for Dell EMC PowerFlex installation does not create this class. You will need to create instance of VolumeSnapshotClass from one of default samples in `helm/samples/volumesnapshotclass’ directory.

Test restoring from a snapshot

Test the restore operation workflow to restore from a snapshot.

Prerequisites

Ensure that you have stopped any previous test instance before performing this procedure.

Steps

NOTE: apiVersion in both betasnap yamls must match apiVersion in your VolumeSnapshotClass, if version in vxflexos-snapclass is v1, adjust apiVersion like so: apiVersion: snapshot.storage.k8s.io/v1

  1. Run sh snaprestoretest.sh to start the test.

This script deploys the 2vols example, creates a snap of pvol0, and then updates the deployed helm chart from the updated directory 2vols+restore. This then adds an additional volume that is created from the snapshot.

NOTE:

  • Helm tests are designed assuming users are using the storageclass names (vxflexos and vxflexos-xfs). If your storageclass names differ from these values, update the templates for snap restore tests accordingly (located in test/helm/2vols+restore/template directory). You can use kubectl get sc to check for the storageclass names.
  • Helm tests are designed assuming users are using the snapshotclass name: vxflexos-snapclass If your snapshotclass name differs from the default values, update betasnap1.yaml and betasnap2.yaml accordingly.

Results

An outline of this workflow is described below:

  1. The snapshot is taken using betasnap1.yaml.
  2. Helm is called to upgrade the deployment with a new definition, which is found in the 2vols+restore directory. The csi-vxflexos/test/helm/2vols+restore/templates directory contains the newly created createFromSnap.yaml file. The script then creates a PersistentVolumeClaim, which is a volume that is dynamically created from the snapshot. Then the helm deployment is upgraded to contain the newly created third volume. In other words, when the snaprestoretest.sh creates a new volume with data from the snapshot, the restore operation is tested. The contents of the createFromSnap.yaml are described below:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restorepvc
  namespace: helmtest-vxflexos
spec:
  storageClassName: vxflexos
  dataSource:
    name: pvol0-snap1
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

NOTE: The spec.dataSource clause, specifies a source VolumeSnapshot named pvol0-snap1 which matches the snapshot’s name in betasnap1.yaml.