Merge branch 'master' into e2e-debugging

longhorn · Feb 24, 2024 · abf9ffe · abf9ffe
2 parents af84fc3 + d4fcafd
commit abf9ffe
Show file tree

Hide file tree

Showing 181 changed files with 4,104 additions and 1,179 deletions.
diff --git a/.drone.yml b/.drone.yml
@@ -23,7 +23,6 @@ steps:
   image: rancher/dapper:v0.5.3
   commands:
   - dapper
-  privileged: true
   volumes:
   - name: socket
     path: /var/run/docker.sock
@@ -92,7 +91,6 @@ steps:
   image: rancher/dapper:v0.5.3
   commands:
   - dapper
-  privileged: true
   volumes:
   - name: socket
     path: /var/run/docker.sock

diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
@@ -0,0 +1,11 @@
+#### Which issue(s) this PR fixes:
+<!--
+Use `Issue #<issue number>` or `Issue longhorn/longhorn#<issue number>` or `Issue (paste link of issue)`. DON'T use `Fixes #<issue number>` or `Fixes (paste link of issue)`, as it will automatically close the linked issue when the PR is merged.
+-->
+Issue #
+
+#### What this PR does / why we need it:
+
+#### Special notes for your reviewer:
+
+#### Additional documentation or context
diff --git a/.github/mergify.yml b/.github/mergify.yml
@@ -5,9 +5,8 @@ pull_request_rules:
   - check-success=DCO
   - check-success=CodeFactor
   - check-success=codespell
-  - "#approved-reviews-by>=1"
+  - "#approved-reviews-by>=2"
   - approved-reviews-by=@longhorn/maintainer
-  - label=ready-to-merge
   actions:
     merge:
       method: rebase
@@ -17,18 +16,4 @@ pull_request_rules:
   - conflict
   actions:
     comment:
-      message: This pull request is now in conflicts. Could you fix it @{{author}}? 🙏
-
-# Comment on the PR to trigger backport. ex: @Mergifyio copy stable/3.1 stable/4.0
-- name: backport patches to stable branch
-  conditions:
-  - base=master
-  actions:
-    backport:
-      title: "[BACKPORT][{{ destination_branch }}] {{ title }}"
-      body: |
-        This is an automatic backport of pull request #{{number}}.
-        
-        {{cherry_pick_error}}
-      assignees:
-      - "{{ author }}"
+      message: This pull request is now in conflict. Could you fix it @{{author}}? 🙏
diff --git a/.github/workflows/codespell.yml b/.github/workflows/codespell.yml
@@ -0,0 +1,23 @@
+name: Codespell
+
+on:
+  pull_request:
+    branches:
+    - master
+    - main
+    - "v*.*.*"
+
+jobs:
+  codespell:
+    runs-on: ubuntu-latest
+    steps:
+    - name: Checkout
+      uses: actions/checkout@v4
+      with:
+        fetch-depth: 1
+    - name: Check code spell
+      uses: codespell-project/actions-codespell@v2
+      with:
+        check_filenames: true
+        skip: "*/**.yaml,*/**.yml,./scripts,./vendor,MAINTAINERS,LICENSE,go.mod,go.sum"
+        ignore_words_list: aks
diff --git a/.github/workflows/publish.yaml b/.github/workflows/publish.yaml
@@ -7,7 +7,7 @@ on:
 
 jobs:
   publish:
-    runs-on: [self-hosted, python3.8]
+    runs-on: ubuntu-latest
     steps:
       - name: Checkout
         uses: actions/checkout@v2

diff --git a/build_engine_test_images/Dockerfile.setup b/build_engine_test_images/Dockerfile.setup
@@ -15,7 +15,7 @@ RUN wget -q https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraf
     wget -q "https://github.com/mikefarah/yq/releases/download/${YQ_VERSION}/yq_linux_amd64" && \
     mv yq_linux_amd64 /usr/local/bin/yq && \
     chmod +x /usr/local/bin/yq && \
-    apk add openssh-client ca-certificates git rsync bash curl jq docker && \
+    apk add openssh-client ca-certificates git rsync bash curl jq && \
     ssh-keygen -t rsa -b 4096 -N "" -f ~/.ssh/id_rsa
 
 COPY [".", "$WORKSPACE"]
diff --git a/build_engine_test_images/Jenkinsfile b/build_engine_test_images/Jenkinsfile
@@ -15,12 +15,11 @@ node {
     usernamePassword(credentialsId: 'DOCKER_CREDS', passwordVariable: 'DOCKER_PASSWORD', usernameVariable: 'DOCKER_USERNAME'),
     usernamePassword(credentialsId: 'AWS_CREDS', passwordVariable: 'AWS_SECRET_KEY', usernameVariable: 'AWS_ACCESS_KEY')
   ]) {
-        stage('build') {
+        stage('build') {      
 
             sh "build_engine_test_images/scripts/build.sh"
 
-            sh """ docker run -itd --privileged -v /var/run/docker.sock:/var/run/docker.sock \
-                                   --name ${JOB_BASE_NAME}-${BUILD_NUMBER} \
+            sh """ docker run -itd --name ${JOB_BASE_NAME}-${BUILD_NUMBER} \
                                    --env TF_VAR_build_engine_aws_access_key=${AWS_ACCESS_KEY} \
                                    --env TF_VAR_build_engine_aws_secret_key=${AWS_SECRET_KEY} \
                                    --env TF_VAR_docker_id=${DOCKER_USERNAME} \

diff --git a/build_engine_test_images/run.sh b/build_engine_test_images/run.sh
@@ -26,30 +26,6 @@ if [[ -z "$TF_VAR_docker_repo" ]]; then
     exit 1
 fi
 
-# if commit_id is empty, we can directly check longhorn-engine:master-head's api version
-if [[ -z "${TF_VAR_commit_id}" ]]; then
-
-  docker login -u="${TF_VAR_docker_id}" -p="${TF_VAR_docker_password}"
-  docker pull longhornio/longhorn-engine:master-head
-  version=`docker run longhornio/longhorn-engine:master-head longhorn version --client-only`
-  CLIAPIVersion=`echo $version | jq -r ".clientVersion.cliAPIVersion"`
-  CLIAPIMinVersion=`echo $version | jq -r ".clientVersion.cliAPIMinVersion"`
-  ControllerAPIVersion=`echo $version | jq -r ".clientVersion.controllerAPIVersion"`
-  ControllerAPIMinVersion=`echo $version | jq -r ".clientVersion.controllerAPIMinVersion"`
-  DataFormatVersion=`echo $version | jq -r ".clientVersion.dataFormatVersion"`
-  DataFormatMinVersion=`echo $version | jq -r ".clientVersion.dataFormatMinVersion"`
-  echo "latest engine version: ${version}"
-
-  upgrade_image="${TF_VAR_docker_repo}:upgrade-test.$CLIAPIVersion-$CLIAPIMinVersion"\
-".$ControllerAPIVersion-$ControllerAPIMinVersion"\
-".$DataFormatVersion-$DataFormatMinVersion"
-
-  if [[ $(docker manifest inspect "${upgrade_image}") != "" ]]; then
-    echo "latest engine test images have already published"
-    exit 0
-  fi
-fi
-
 trap ./scripts/cleanup.sh EXIT
 
 # Build amd64 images

diff --git a/build_engine_test_images/terraform/aws/ubuntu/main.tf b/build_engine_test_images/terraform/aws/ubuntu/main.tf
@@ -99,7 +99,7 @@ resource "aws_route_table" "build_engine_aws_public_rt" {
   }
 }
 
-# Assciate public subnet to public route table
+# Associate public subnet to public route table
 resource "aws_route_table_association" "build_engine_aws_public_subnet_rt_association" {
   depends_on = [
     aws_subnet.build_engine_aws_public_subnet,

diff --git a/build_engine_test_images/terraform/aws/ubuntu/variables.tf b/build_engine_test_images/terraform/aws/ubuntu/variables.tf
@@ -56,7 +56,7 @@ variable "build_engine_aws_instance_name" {
 
 variable "build_engine_aws_instance_type" {
   type        = string
-  description = "Recommended instance types t2.xlarge for amd64 & a1.xlarge  for arm64"
+  description = "Recommended instance types t3.xlarge for amd64 & t4g.xlarge  for arm64"
   default     = ""
 }
 

diff --git a/docs/content/manual/functional-test-cases/backup.md b/docs/content/manual/functional-test-cases/backup.md
@@ -28,7 +28,7 @@ Backup create operations test cases
 |-----| --- | --- | --- |
 | 1   | Create backup from existing snapshot | **Prerequisite:**<br><br>*   Backup target is set to NFS server, or S3 compatible target.<br><br>1.  Create a workload using Longhorn volume<br>2.  Write data to volume, compute it’s checksum (checksum#1)<br>3.  Create a snapshot (snapshot#1)<br>4.  Create a backup from (snapshot#1)<br>5.  Restore backup to a different volume<br>6.  Attach volume to a node and check it’s data, and compute it’s checksum | *   Backup should be created<br>*   Restored volume data checksum should match (checksum#1) |
 | 2   | Create volume backup for a volume attached to a node | **Prerequisite:**<br><br>*   Backup target is set to NFS server, or S3 compatible target.<br><br>1.  Create a volume, attach it to a node<br>2.  Format volume using ext4/xfs filesystem and mount it to a directory on the node<br>3.  Write data to volume, compute it’s checksum (checksum#1)<br>4.  Create a backup<br>5.  Restore backup to a different volume<br>6.  Attach volume to a node and check it’s data, and compute it’s checksum<br>7.  Check volume backup labels | *   Backup should be created<br>*   Restored volume data checksum should match (checksum#1)<br>*   backup should have no backup labels |
-| 3   | Create volume backup used by Kubernetes workload | **Prerequisite:**<br><br>*   Backup target is set to NFS server, or S3 compatible target.<br><br>1.  Create a deployment workload with `nReplicas = 1` using Longhorn volume<br>2.  Write data to volume, compute it’s checksum (checksum#1)<br>3.  Create a backup<br>4.  Check backup labels<br>5.  Scale down deployment `nReplicas = 0`<br>6.  Delete Longhorn volume<br>7.  Restore backup to a volume with the same deleted volume name<br>8.  Scale back deployment `nReplicas = 1`<br>9.  Check volume data checksum | *   Backup labels should contain the following informations about workload that was using the volume at time of backup.<br>    *   Namespace<br>        <br>    *   PV Name<br>        <br>    *   PVC Name<br>        <br>    *   PV Status<br>        <br>    *   Workloads Status<br>        <br>        *   Pod Name  <br>            Workload Name  <br>            Workload Type  <br>            Pod Status<br>            <br>*   After volume restore, data checksum should match (checksum#1) |
+| 3   | Create volume backup used by Kubernetes workload | **Prerequisite:**<br><br>*   Backup target is set to NFS server, or S3 compatible target.<br><br>1.  Create a deployment workload with `nReplicas = 1` using Longhorn volume<br>2.  Write data to volume, compute it’s checksum (checksum#1)<br>3.  Create a backup<br>4.  Check backup labels<br>5.  Scale down deployment `nReplicas = 0`<br>6.  Delete Longhorn volume<br>7.  Restore backup to a volume with the same deleted volume name<br>8.  Scale back deployment `nReplicas = 1`<br>9.  Check volume data checksum | *   Backup labels should contain the following information about workload that was using the volume at time of backup.<br>    *   Namespace<br>        <br>    *   PV Name<br>        <br>    *   PVC Name<br>        <br>    *   PV Status<br>        <br>    *   Workloads Status<br>        <br>        *   Pod Name  <br>            Workload Name  <br>            Workload Type  <br>            Pod Status<br>            <br>*   After volume restore, data checksum should match (checksum#1) |
 | 4   | Create volume backup with customized labels | **Prerequisite:**<br><br>*   Backup target is set to NFS server, or S3 compatible target.<br><br>1.  Create a volume, attach it to a node<br>2.  Create a backup, add customized labels  <br>    key: `K1` value: `V1`<br>3.  Check volume backup labels | *   Backup should be created with customized labels |
 | 5   | Create recurring backups | 1.  Create a deployment workload with `nReplicas = 1` using Longhorn volume<br>2.  Write data to volume , compute it’s checksum (checksum#1)<br>3.  Create a recurring backup `every 5 minutes`. and set retain count to `5`<br>4.  add customized labels key: `K1` value: `V1`<br>5.  Wait for recurring backup to triggered (backup#1, backup#2 )<br>6.  Scale down deployment `nReplicas = 0`<br>7.  Delete the volume.<br>8.  Restore backup to a volume with the same deleted volume name<br>9.  Scale back deployment `nReplicas = 1`<br>10.  Check volume data checksum | *   backups should be created with Kubernetes status labels and customized labels<br>*   After volume restore, data checksum should match (checksum#1)<br>*   after restoring the backup recurring backups should continue to be created |
 | 6   | Backup created using Longhorn behind proxy | **Prerequisite:**<br><br>*   Setup a Proxy on an instance (Optional: use squid)<br>*   Create a single node cluster in EC2<br>*   Deploy Longhorn<br><br>1.  Block outgoing traffic except for the proxy instance.<br>2.  Create AWS secret in longhorn.<br>3.  In UI Settings page, set backupstore target and backupstore credential secret<br>4.  Create a volume, attach it to a node, format the volume, and mount it to a directory.<br>5.  Write some data to the volume, and create a backup. | *   Ensure backup is created |
@@ -99,7 +99,7 @@ Disaster Recovery test cases
 | DR volume across the cluster #5 | Cluster A:<br><br>*   Create volume Y<br>*   Attach the volume Y<br>*   Create a backup of Y<br><br>Cluster B:<br><br>*   Backup Volume list page, click \`Create Disaster Recovery Volume\` from volume dropdown<br>*   Create two DR volumes Ydr1 and Ydr2.<br>*   Attach the volume Y to any node<br>*   Mount the volume Y on the node<br>*   Write a file of 10Mb into it, use \`/dev/urandom\` to generate the file<br>*   Calculate the checksum of the file<br>*   Make a Backup<br>*   Attach Ydr1 and Ydr2 to any nodes | *   DR volume's last backup should be updated automatically, after settings.BackupPollInterval passed.<br>*   DR volume.LastBackup should be different from DR volume's controller\[0\].LastRestoredBackup temporarily (it's restoring the last backup)<br>*   During the restoration, DR volume cannot be activated.<br>*   Eventually, DR volume.LastBackup should equal to controller\[0\].LastRestoredBackup. |
 | DR volume across the cluster #6 | \[follow #5\]  <br>Cluster A:<br><br>*   In the directory mounted volume Y, write a new file of 100Mb.<br>*   Record the checksum of the file<br>*   Create a backup of volume Y<br><br>Cluster B:<br><br>*   Wait for restoration of volume Ydr1 and Ydr2 to complete<br>*   Activate Ydr1<br>*   Attach it to one node and verify the content | *   DR volume's last backup should be updated automatically, after settings.BackupPollInterval passed.<br>*   Eventually, DR volume.LastBackup should equal to controller\[0\].LastRestoredBackup.<br>*   Ydr1 should have the same file checksum of volume Y |
 | DR volume across the cluster #7 | \[follow #6\]  <br>Cluster A<br><br>*   In the directory mounted volume Y, remove all the files. Write a file of 50Mb<br>*   Record the checksum of the file<br><br>Cluster B<br><br>*   Change setting.BackupPollInterval to longer e.g. 1h<br><br>Cluster A<br><br>*   Create a backup of volume Y<br><br>Cluster B  <br>\[DO NOT CLICK BACKUP PAGE, which will update last backup as a side effect\]<br><br>*   Before Ydr2's last backup updated, activate Ydr2 | *   YBdr2's last backup should be immediately updated to the last backup of volume Y<br>*   Activate should fail due to restoration is in progress | When user clicks on “activate DRV”, restoration happens<br><br>And the volume goes into detached state |
-| DR volume across the cluster #8 | Cluster A<br><br>*   Create volume Z<br>*   Attach the volume Z<br>*   Create a backup of Z<br><br>Cluster B<br><br>*   Backup Volume list page, click \`Create Disaster Recovery Volume\` from volume dropdown<br>*   Create DR volumes Zdr1, Zdr2 and Zdr3<br>*   Attach the volume Zdr1, Zdr2 and Zdr3 to any node<br>*   Change setting.BackupPollInterval to approriate interval for multiple backups e.g. 15min<br>*   Make sure LastBackup of Zdr is consistent with that of Z<br><br>Cluster A<br><br>*   Create multiple backups for volume Z before Zdr's last backup updated. For each backup, write or modify at least one file then record the cheksum.<br><br>Cluster B<br><br>*   Wait for restoration of volume Zdr1 to complete<br>*   Activate Zdr1<br>*   Attach it to one node and verify the content | *   Zdr1's last backup should be updated after settings.BackupPollInterval passed.<br>*   Zdr1 should have the same files with the the same checksums of volume Z |
+| DR volume across the cluster #8 | Cluster A<br><br>*   Create volume Z<br>*   Attach the volume Z<br>*   Create a backup of Z<br><br>Cluster B<br><br>*   Backup Volume list page, click \`Create Disaster Recovery Volume\` from volume dropdown<br>*   Create DR volumes Zdr1, Zdr2 and Zdr3<br>*   Attach the volume Zdr1, Zdr2 and Zdr3 to any node<br>*   Change setting.BackupPollInterval to appropriate interval for multiple backups e.g. 15min<br>*   Make sure LastBackup of Zdr is consistent with that of Z<br><br>Cluster A<br><br>*   Create multiple backups for volume Z before Zdr's last backup updated. For each backup, write or modify at least one file then record the checksum.<br><br>Cluster B<br><br>*   Wait for restoration of volume Zdr1 to complete<br>*   Activate Zdr1<br>*   Attach it to one node and verify the content | *   Zdr1's last backup should be updated after settings.BackupPollInterval passed.<br>*   Zdr1 should have the same files with the the same checksums of volume Z |
 | DR volume across the cluster #9 | \[follow #8\]  <br>Cluster A<br><br>*   Delete the latest backup of Volume Z | *   Last backup of Zdr2 and Zdr3 should be empty after settings.BackupPollInterval passed. Field controller\[0\].LastRestoredBackup and controller\[0\].RequestedBackupRestore should retain. |
 | DR volume across the cluster #10 | \[follow #9\]  <br>Cluster B<br><br>*   Activate Zdr2<br>*   Attach it to one node and verify the content | *   Zdr2 should have the same files with the the same checksums of volume Z |     |
 | DR volume across the cluster #11 | \[follow #10\]  <br>Cluster A<br><br>*   Create one more backup with at least one file modified.<br><br>Cluster B<br><br>*   Wait for restoration of volume Zdr3 to complete<br>*   Activate Zdr3<br>*   Attach it to one node and verify the content | *   Zdr3 should have the same files with the the same checksums of volume Z |
@@ -150,7 +150,7 @@ The setup requirements:
 | 4   | Delete the backup with `DeletionPolicy` as delete | 1.  Repeat the steps from test scenario 1.<br>2.  Delete the `VolumeSnapshot` using `kubectl delete volumesnapshots test-snapshot-pvc` | 1.  The `VolumeSnapshot` should be deleted.<br>2.  By default the `DeletionPolicy` is delete, so the `VolumeSnapshotContent` should be deleted.<br>3.  Verify in the backup store, the backup should be deleted. |
 | 5   | Delete the backup with `DeletionPolicy` as retain | 1.  Create a `VolumeSnapshotClass` class with `deletionPolicy` as Retain<br><pre>kind: VolumeSnapshotClass<br>apiVersion: snapshot.storage.k8s.io/v1beta1<br>metadata:<br>  name: longhorn<br>driver: driver.longhorn.io<br>deletionPolicy: Retain</pre>2.  Repeat the steps from test scenario 1.<br>3.  Delete the `VolumeSnapshot` using `kubectl delete volumesnapshots test-snapshot-pvc` | 1.  The `VolumeSnapshot` should be deleted.<br>2.  `VolumeSnapshotContent` should NOT be deleted.<br>3.  Verify in the backup store, the backup should NOT be deleted. |
 | 6   | Take a backup from longhorn of a snapshot created by csi snapshotter. | 1.  Create a volume test-vol and write into it.<br>    1.  Compute the md5sum<br>        <br>2.  Create the below `VolumeSnapshot` object<br><pre>apiVersion: snapshot.storage.k8s.io/v1beta1<br>kind: VolumeSnapshot<br>metadata:<br>  name: test-snapshot-pvc<br>spec:<br>  volumeSnapshotClassName: longhorn<br>  source:<br>    persistentVolumeClaimName: test-vol</pre>3.  Go to longhorn UI and click on the snapshot created and take another backup | 1.  On creating a `VolumeSnapshot`, a backup should be created in the backup store.<br>2.  On creating another backup from longhorn UI, one more backup should be created in backup store. |
-| 7   | Delete the `csi plugin` while a backup is in progress. | 1.  Create a volume and write into it.  <br>    Compute the md5sum of the data.<br>2.  Create the below `VolumeSnapshot` object<br><pre>apiVersion: snapshot.storage.k8s.io/v1beta1<br>kind: VolumeSnapshot<br>metadata:<br> <br>name: test-snapshot-pvc<br>spec:<br>  volumeSnapshotClassName: longhorn<br>  source:<br>    persistentVolumeClaimName: test-vol</pre>3.  While the backup is in progress, delete the `csi plugin` | On deleting `csi plugin` , a new pod of `csi plugin` should get created and the bacup should continue to complete. |
+| 7   | Delete the `csi plugin` while a backup is in progress. | 1.  Create a volume and write into it.  <br>    Compute the md5sum of the data.<br>2.  Create the below `VolumeSnapshot` object<br><pre>apiVersion: snapshot.storage.k8s.io/v1beta1<br>kind: VolumeSnapshot<br>metadata:<br> <br>name: test-snapshot-pvc<br>spec:<br>  volumeSnapshotClassName: longhorn<br>  source:<br>    persistentVolumeClaimName: test-vol</pre>3.  While the backup is in progress, delete the `csi plugin` | On deleting `csi plugin` , a new pod of `csi plugin` should get created and the backup should continue to complete. |
 | 8   | Take a backup using csi snapshotter with backup store as NFS server. |     |     |
 | 9   | Restore from NFS backup store. |     |     |
 | 10  | Delete from NFS backup store. |     |     |