installer: add a test to ensure that CSI is working as expected prior to installing Gitpod

[jenting]

Is your feature request related to a problem? Please describe

Add a test to ensure that the CSI is working as expected prior to installing Gitpod

Describe the behaviour you'd like

Have a pre-installed/preflight test to ensure that the CSI is working as expected prior to installing Gitpod
The required CSI criteria are similar to #10201, here are the test criteria:

• Have a storage class with Delete policy? 🤔
• Have a volume snapshot class with Delete policy? 🤔
• Support CSI snapshot backup/restore without a problem.
  • Create Pod csi-test-pod with PVC csi-test-pvc, and write some data to the PVC csi-test-pvc.

    ---
    apiVersion: v1
    kind: Pod
    metadata:
      name: csi-test-pod
    spec:
      containers:
        - name: web-server
          image: nginx
          volumeMounts:
            - name: pvc
              mountPath: /var/lib/www/html
      volumes:
        - name: pvc
          persistentVolumeClaim:
            claimName: csi-test-pvc
            readOnly: false
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: csi-test-pvc
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi
      storageClassName: <name-from-config-storageClass>

  • Create VolumeSnapshot csi-test-vs for the PVC csi-test-pvc, it can back up the snapshot success, and the VolumeSnapshotContent be created.

    ---
    # 1.17 <= K8s <= v1.19
    # apiVersion: snapshot.storage.k8s.io/v1beta1
    # K8s >= v1.20
    apiVersion: snapshot.storage.k8s.io/v1
    kind: VolumeSnapshot
    metadata:
      name: csi-test-vs
    spec:
      volumeSnapshotClassName: <name-from-config-snapshotClass>
      source:
        persistentVolumeClaimName: csi-test-pvc

  • Delete Pod csi-test-pod and PVC csi-test-pvc.

    kubectl delete pvc csi-test-pvc
    kubectl delete pod csi-test-pod

  • Create another Pod csi-test-pod-restore and PVC csi-test-pvc-restore with data source as VolumeSnapshot csi-test-vs, and check the PVC csi-test-pvc-restore with correct data content.

    ---
    apiVersion: v1
    kind: Pod
    metadata:
     name: csi-test-pod-restore
    spec:
     containers:
       - name: web-server
         image: nginx
         volumeMounts:
           - name: pvc
             mountPath: /var/lib/www/html
     volumes:
       - name: pvc
         persistentVolumeClaim:
           claimName: csi-test-pvc-restore
           readOnly: false
    ---
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: csi-test-pvc-restore
    spec:
      storageClassName: <name-from-config-storageClass>
      dataSource:
        name: csi-test-vs
        kind: VolumeSnapshot
        apiGroup: snapshot.storage.k8s.io
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

• Add CSI driver requirement to the Notion's Product Compatibility Matrix

Describe alternatives you've considered

N/A

Additional context

#10201
#7901

[jenting]

The PVC feature currently is an experimental/beta feature in the SaaS solution. Probably the self-hosted customer would never enable this PVC feature in the end until all our code by default ships to use PVC in the end.

I'm considering that this issue could be implemented after we ship to use PVC by default.
Or we could check the CSI is working as expected once the user's installer config configures the storageClass and snapshotClass.

WDYT? @kylos101

[kylos101]

Hi @jenting ,

May I ask a favor? Could you brainstorm this with @Pothulapati to see what pattern might make sense to do cluster validation for CSI? I ask because I know the installer does some prechecks, but so does KOTS/replicated, and I'm not sure what makes the most sense. For example, can we do in one spot (installer), and have it work in both (kots too), or does it need to be coded separately for both?

Either way, yes, I think this could be implemented later, closer to when we are thinking about making PVC default. To be honest though, I think that is far away (probably 3-6 months). For example, we're not sure how fast CSI is in AWS or Azure, and would need months to update those drivers (potentially) if they are slow.

[Pothulapati]

👋🏼

Just had a closer look at the issue. Recently, Any kind of tests that we want to surface to the user have been buil in kots, as they are surfaced in a much more user friendly way! We already have a check for the default storage class.

The tests that are added in the installer should also be surfaced through the kots install but not in a user friendly way, and the user has to figure out on their own on what went wrong.

Either way, yes, I think this could be implemented later, closer to when we are thinking about making PVC default

Totally agree, and in kots we also have a way to warn users. So, We could even start warning users ahead before it becomes the default.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.