Merge commit '440e4cf7ddc75a5c64e5397b8907916adb1d00a5' into prow-update-master
This commit is contained in:
@@ -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
|
||||
|
@@ -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
|
||||
generator](https://github.com/kubernetes/release/tree/HEAD/cmd/release-notes)
|
||||
1. Download the latest version of the
|
||||
[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-org=kubernetes-csi --github-repo=external-provisioner
|
||||
--required-author="" --output out.md
|
||||
GITHUB_TOKEN=<token> release-notes \
|
||||
--discover=mergebase-to-latest \
|
||||
--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-org=kubernetes-csi --github-repo=external-provisioner
|
||||
--required-author="" --output out.md
|
||||
GITHUB_TOKEN=<token> release-notes \
|
||||
--discover=patch-to-latest \
|
||||
--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
|
||||
|
@@ -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"
|
||||
|
@@ -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"`
|
||||
|
Reference in New Issue
Block a user