cc @ChanYiLin

PR: longhorn/longhorn-manager#3334

PR: longhorn/longhorn-manager#3334

Hi @COLDTURNIP,

Move the status of Longhorn Sprint to Review to make the bot create Pre Ready-For-Testing Checklist and update the list.
Then you could move the status to Ready for Testing.
Thanks.

Pre Ready-For-Testing Checklist

• Where is the reproduce steps/test steps documented?
  The reproduce steps/test steps are at: [IMPROVEMENT] Reject strict-local + RWX volume creation #6735 (comment)

• Is there a workaround for the issue? If so, where is it documented?
  This is not a workaround.

• Does the PR include the explanation for the fix or the feature?
  Yes, see feat(webhook): reject strict-local RWX volume creation longhorn-manager#3334

• Does the PR include deployment change (YAML/Chart)? If so, where are the PRs for both YAML file and Chart?
  There's no deployment change.

• Have the backend code been merged (Manager, Engine, Instance Manager, BackupStore etc) (including backport-needed/*)?
  The PR is at feat(webhook): reject strict-local RWX volume creation longhorn-manager#3334

• Which areas/issues this PR might have potential impacts on?
  No impact.

• If labeled: require/LEP Has the Longhorn Enhancement Proposal PR submitted?
  No LEP.

• If labeled: area/ui Has the UI issue filed or ready to be merged (including backport-needed/*)?
  No UI change.

• If labeled: require/doc Has the necessary document PR submitted or merged (including backport-needed/*)?
  The documentation issue/PR is at

• If labeled: require/automation-e2e Has the end-to-end test plan been merged? Have QAs agreed on the automation test case? If only test case skeleton w/o implementation, have you created an implementation issue (including backport-needed/*)
  The automation skeleton PR is at
  The automation test case PR is at
  The issue of automation test case implementation is at (please create by the template)

• If labeled: require/automation-engine Has the engine integration test been merged (including backport-needed/*)?
  No engine automation PR.

• If labeled: require/manual-test-plan Has the manual test plan been documented?
  The updated manual test plan is at [IMPROVEMENT] Reject strict-local + RWX volume creation #6735 (comment)

• If the fix introduces the code for backward compatibility Has a separate issue been filed with the label release/obsolete-compatibility?
  No compatibility issue.

Test Steps

• Step 1. a Longhorn-ready cluster
• Step 2. create a storage class (see attached example)
  • provisioner: driver.longhorn.io
  • parameters.dataLocality: strict-local
  • parameters.migratable: false
• Step 3. create a workload, with a PVC that claim a ReadWriteMany volume of given above class
• Step 4. verify the cluster
  • the pods of the workload must stick as pending because of PV
  • check the status of created PVC, it must be pending, and one of the event indicates that access mode rwx (migratable: false) is incompatible with data locality strict-local mode

The following example resources can be created/cleanup by kubectl apply -f example.yaml and kubectl delete -f example.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-6735-strict-local-rwx
provisioner: driver.longhorn.io
parameters:
  dataEngine: v1
  numberOfReplicas: "1"
  dataLocality: strict-local
  migratable: "false"
  staleReplicaTimeout: "30"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: 6735-strict-local-rwx
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Mi
  storageClassName: longhorn-6735-strict-local-rwx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: 6735-strict-local-rwx-verify
  labels:
    app: 6735-strict-local-rwx-verify
spec:
  replicas: 1
  selector:
    matchLabels:
      app: 6735-strict-local-rwx-verify
  template:
    metadata:
      labels:
        app: 6735-strict-local-rwx-verify
    spec:
      containers:
        - name: 6735-strict-local-rwx-verify
          image: busybox
          command: ['sh', '-c', 'while true ; do now=$(date +%s) ; echo $now ; for vol in share1 share2 share3 ; do echo $now >>/mnt/data/${vol}/log || echo $now >/mnt/data/${vol}/log ; done ; ls -l $(find /mnt/data -name log) ; sleep 1 ; done']
          volumeMounts:
            - mountPath: /mnt/data/share1
              name: share1
      volumes:
        - name: share1
          persistentVolumeClaim:
            claimName: 6735-strict-local-rwx

Test Steps

• Step 1. a Longhorn-ready cluster

• Step 2. create a storage class (see attached example)

  • provisioner: driver.longhorn.io
  • parameters.dataLocality: strict-local
  • parameters.migratable: false

• Step 3. create a workload, with a PVC that claim a ReadWriteMany volume of given above class

• Step 4. verify the cluster

  • the pods of the workload must stick as pending because of PV
  • check the status of created PVC, it must be pending, and one of the event indicates that access mode rwx (migratable: false) is incompatible with data locality strict-local mode

The following example resources can be created/cleanup by kubectl apply -f example.yaml and kubectl delete -f example.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn-6735-strict-local-rwx
provisioner: driver.longhorn.io
parameters:
  dataEngine: v1
  numberOfReplicas: "1"
  dataLocality: strict-local
  migratable: "false"
  staleReplicaTimeout: "30"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: 6735-strict-local-rwx
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Mi
  storageClassName: longhorn-6735-strict-local-rwx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: 6735-strict-local-rwx-verify
  labels:
    app: 6735-strict-local-rwx-verify
spec:
  replicas: 1
  selector:
    matchLabels:
      app: 6735-strict-local-rwx-verify
  template:
    metadata:
      labels:
        app: 6735-strict-local-rwx-verify
    spec:
      containers:
        - name: 6735-strict-local-rwx-verify
          image: busybox
          command: ['sh', '-c', 'while true ; do now=$(date +%s) ; echo $now ; for vol in share1 share2 share3 ; do echo $now >>/mnt/data/${vol}/log || echo $now >/mnt/data/${vol}/log ; done ; ls -l $(find /mnt/data -name log) ; sleep 1 ; done']
          volumeMounts:
            - mountPath: /mnt/data/share1
              name: share1
      volumes:
        - name: share1
          persistentVolumeClaim:
            claimName: 6735-strict-local-rwx

@COLDTURNIP This seems like a simple case to automate with a robot test. I encourage you to give implementing the test a try.

Ref https://github.com/longhorn/longhorn-tests/tree/master/e2e

cc @derekbit @longhorn/qa

Verified pass on longhorn master(longhorn/longhorn-manager@6da14ea)

• following test steps, can see creation of RWX + strict-local PVC jejected

  Warning  ProvisioningFailed    36s (x8 over 2m43s)   driver.longhorn.io_csi-provisioner-5847bdddf5-425wm_8a4fcc3e-7de1-4616-b9b4-9640c305a198  failed to provision volume with StorageClass "longhorn-6735-strict-local-rwx": rpc error: code = Internal desc = Bad response statusCode [500]. Status [500 Internal Server Error]. Body: [code=Internal Server Error, detail=, message=failed to create volume: unable to create volume pvc-865e5e1f-4c01-461b-b87f-e26cfcef2ea8: admission webhook "validator.longhorn.io" denied the request: access mode rwx (migratable: false) is incompatible with data locality strict-local mode] from [http://longhorn-backend:9500/v1/volumes]

• Create RWX volume with data locality=strict-local from UI rejected as well.