Merge commit '440e4cf7ddc75a5c64e5397b8907916adb1d00a5' into prow-update-master

release-tools/KUBERNETES_CSI_OWNERS_ALIASES

@@ -31,15 +31,7 @@ aliases:
 
 # This documents who previously contributed to Kubernetes-CSI
 # as approver.
-emeritus_approver:
+emeritus_approvers:
 - lpabon
 - sbezverk
 - vladimirvivien
-
-# This documents who previously contributed to Kubernetes-CSI
-# as reviewer.
-emeritus_reviewer:
-- lpabon
-- saad-ali
-- sbezverk
-- vladimirvivien

release-tools/SIDECAR_RELEASE_PROCESS.md

@@ -46,10 +46,13 @@ naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`.
 ## Release Process
 1. Identify all issues and ongoing PRs that should go into the release, and
   drive them to resolution.
-1. Download v2.8+ [K8s release notes
+1. Download the latest version of the
-  generator](https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes)
+   [K8s release notes generator](https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes)
+1. Create a
+   [Github personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)
+   with `repo:public_repo` access
 1. Generate release notes for the release. Replace arguments with the relevant
-  information.
+   information.
     * Clean up old cached information (also needed if you are generating release
       notes for multiple repos)
       ```bash
@@ -57,15 +60,24 @@ naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`.
       ```
     * For new minor releases on master:
         ```bash
-        GITHUB_TOKEN=<token> release-notes --discover=mergebase-to-latest
+        GITHUB_TOKEN=<token> release-notes \
-        --github-org=kubernetes-csi --github-repo=external-provisioner
+          --discover=mergebase-to-latest \
-        --required-author="" --output out.md
+          --org=kubernetes-csi \
+          --repo=external-provisioner \
+          --required-author="" \
+          --markdown-links \
+          --output out.md
         ```
     * For new patch releases on a release branch:
         ```bash
-        GITHUB_TOKEN=<token> release-notes --discover=patch-to-latest --branch=release-1.1
+        GITHUB_TOKEN=<token> release-notes \
-        --github-org=kubernetes-csi --github-repo=external-provisioner
+          --discover=patch-to-latest \
-        --required-author="" --output out.md
+          --branch=release-1.1 \
+          --org=kubernetes-csi \
+          --repo=external-provisioner \
+          --required-author="" \
+          --markdown-links \
+          --output out.md
         ```
 1. Compare the generated output to the new commits for the release to check if
    any notable change missed a release note.
@@ -100,6 +112,29 @@ naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`.
    and [k/k
    in-tree](https://github.com/kubernetes/kubernetes/tree/HEAD/test/e2e/testing-manifests/storage-csi/hostpath/hostpath)
 
+### Troubleshooting
+
+#### Image build jobs
+
+The following jobs are triggered after tagging to produce the corresponding
+image(s):
+https://k8s-testgrid.appspot.com/sig-storage-image-build
+
+Clicking on a failed build job opens that job in https://prow.k8s.io. Next to
+the job title is a rerun icon (circle with arrow). Clicking it opens a popup
+with a "rerun" button that maintainers with enough permissions can use. If in
+doubt, ask someone on #sig-release to rerun the job.
+
+Another way to rerun a job is to search for it in https://prow.k8s.io and click
+the rerun icon in the resulting job list:
+https://prow.k8s.io/?job=canary-csi-test-push-images
+
+#### Verify images
+
+Canary and staged images can be viewed at https://console.cloud.google.com/gcr/images/k8s-staging-sig-storage
+
+Promoted images can be viewed at https://console.cloud.google.com/gcr/images/k8s-artifacts-prod/us/sig-storage
+
 ## Adding support for a new Kubernetes release
 
 1. Add the new release to `k8s_versions` in

release-tools/prow.sh

@@ -78,7 +78,7 @@ version_to_git () {
 # the list of windows versions was matched from:
 # - https://hub.docker.com/_/microsoft-windows-nanoserver
 # - https://hub.docker.com/_/microsoft-windows-servercore
-configvar CSI_PROW_BUILD_PLATFORMS "linux amd64 amd64; linux ppc64le ppc64le -ppc64le; linux s390x s390x -s390x; linux arm arm -arm; linux arm64 arm64 -arm64; linux arm arm/v7 -armv7; windows amd64 amd64 .exe nanoserver:1809 servercore:ltsc2019; windows amd64 amd64 .exe nanoserver:1909 servercore:1909; windows amd64 amd64 .exe nanoserver:2004 servercore:2004; windows amd64 amd64 .exe nanoserver:20H2 servercore:20H2; windows amd64 amd64 .exe nanoserver:ltsc2022 servercore:ltsc2022" "Go target platforms (= GOOS + GOARCH) and file suffix of the resulting binaries"
+configvar CSI_PROW_BUILD_PLATFORMS "linux amd64 amd64; linux ppc64le ppc64le -ppc64le; linux s390x s390x -s390x; linux arm arm -arm; linux arm64 arm64 -arm64; linux arm arm/v7 -armv7; windows amd64 amd64 .exe nanoserver:1809 servercore:ltsc2019; windows amd64 amd64 .exe nanoserver:20H2 servercore:20H2; windows amd64 amd64 .exe nanoserver:ltsc2022 servercore:ltsc2022" "Go target platforms (= GOOS + GOARCH) and file suffix of the resulting binaries"
 
 # If we have a vendor directory, then use it. We must be careful to only
 # use this for "make" invocations inside the project's repo itself because
@@ -737,7 +737,7 @@ install_csi_driver () {
     fi
 }
 
-# Installs all nessesary snapshotter CRDs
+# Installs all necessary snapshotter CRDs
 install_snapshot_crds() {
   # Wait until volumesnapshot CRDs are in place.
   CRD_BASE_DIR="https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${CSI_SNAPSHOTTER_VERSION}/client/config/crd"

vendor/github.com/kubernetes-csi/external-snapshotter/client/v4/apis/volumesnapshot/v1/types.go

@@ -179,7 +179,7 @@ type VolumeSnapshotStatus struct {
 	// 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.
-	// The snapshot controller will keep retrying when an error occurrs during the
+	// The snapshot controller will keep retrying when an error occurs during the
 	// snapshot creation. Upon success, this error field will be cleared.
 	// +optional
 	Error *VolumeSnapshotError `json:"error,omitempty" protobuf:"bytes,5,opt,name=error,casttype=VolumeSnapshotError"`