test driver config

deploy/kubernetes-1.15/deploy.sh

@@ -0,0 +1 @@
+../util/deploy-hostpath.sh

deploy/kubernetes-1.15/test-driver.yaml

@@ -0,0 +1,16 @@
+# This file describes how to test this deployment of the CSI hostpath driver
+# using the Kubernetes 1.15 E2E test suite. For details see:
+# https://github.com/kubernetes/kubernetes/tree/v1.15.0/test/e2e/storage/external
+
+StorageClass:
+  FromName: true
+SnapshotClass:
+  FromName: true
+DriverInfo:
+  Name: hostpath.csi.k8s.io
+  Capabilities:
+    block: true
+    exec: true
+    dataSource: true
+    multipods: true
+    persistence: true

deploy/kubernetes-1.16/deploy.sh

@@ -0,0 +1 @@
+../util/deploy-hostpath.sh

deploy/kubernetes-1.16/test-driver.yaml

@@ -0,0 +1,18 @@
+# This file describes how to test this deployment of the CSI hostpath driver
+# using the Kubernetes 1.16 E2E test suite. For details see:
+# https://github.com/kubernetes/kubernetes/tree/v1.16.0/test/e2e/storage/external
+
+StorageClass:
+  FromName: true
+SnapshotClass:
+  FromName: true
+DriverInfo:
+  Name: hostpath.csi.k8s.io
+  Capabilities:
+    block: true
+    controllerExpansion: true
+    exec: true
+    multipods: true
+    nodeExpansion: true
+    persistence: true
+    snapshotDataSource: true

deploy/kubernetes-1.17/deploy.sh

@@ -0,0 +1 @@
+../util/deploy-hostpath.sh

deploy/kubernetes-1.17/test-driver.yaml

@@ -0,0 +1,20 @@
+# This file describes how to test this deployment of the CSI hostpath driver
+# using the Kubernetes 1.17 E2E test suite. For details see:
+# https://github.com/kubernetes/kubernetes/tree/v1.17.0/test/e2e/storage/external
+
+StorageClass:
+  FromName: true
+SnapshotClass:
+  FromName: true
+DriverInfo:
+  Name: hostpath.csi.k8s.io
+  Capabilities:
+    block: true
+    controllerExpansion: true
+    exec: true
+    multipods: true
+    nodeExpansion: true
+    persistence: true
+    singleNodeVolume: true
+    snapshotDataSource: true
+    topology: true

deploy/util/deploy-hostpath.sh

@@ -225,3 +225,9 @@ driver_version="$(basename "${BASE_DIR}")"
 if version_gt "$driver_version" "1.16"; then
     kubectl apply -f "https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/${snapshotter_version}/examples/kubernetes/snapshotclass.yaml" 
 fi
+
+# Create a test driver configuration in the place where the prow job
+# expects it?
+if [ "${CSI_PROW_TEST_DRIVER}" ]; then
+    cp "${BASE_DIR}/test-driver.yaml" "${CSI_PROW_TEST_DRIVER}"
+fi

release-tools/README.md

@@ -81,7 +81,7 @@ on what is enabled in Prow, see
 https://github.com/kubernetes/test-infra/tree/master/config/jobs/kubernetes-csi
 
 Test results for periodic jobs are visible in
-https://testgrid.k8s.io/sig-storage-csi
+https://testgrid.k8s.io/sig-storage-csi-ci
 
 It is possible to reproduce the Prow testing locally on a suitable machine:
 - Linux host
@@ -141,17 +141,6 @@ The `vendor` directory is optional. It is still present in projects
 because it avoids downloading sources during CI builds. If this is no
 longer deemed necessary, then a project can also remove the directory.
 
-When using packages that are part of the Kubernetes source code, the
-commands above are not enough because the [lack of semantic
-versioning](https://github.com/kubernetes/kubernetes/issues/72638)
-prevents `go mod` from finding newer releases. Importing directly from
-`kubernetes/kubernetes` also needs `replace` statements to override
-the fake `v0.0.0` versions
-(https://github.com/kubernetes/kubernetes/issues/79384). The
-`go-get-kubernetes.sh` script can be used to update all packages in
-lockstep to a different Kubernetes version. It takes a single version
-number like "1.16.0".
-
 Conversion of a repository that uses `dep` to `go mod` can be done with:
 
     GO111MODULE=on go mod init
@@ -160,3 +149,18 @@ Conversion of a repository that uses `dep` to `go mod` can be done with:
     GO111MODULE=on go mod vendor
     git rm -f Gopkg.toml Gopkg.lock
     git add go.mod go.sum vendor
+
+### Updating Kubernetes dependencies
+
+When using packages that are part of the Kubernetes source code, the
+commands above are not enough because the [lack of semantic
+versioning](https://github.com/kubernetes/kubernetes/issues/72638)
+prevents `go mod` from finding newer releases. Importing directly from
+`kubernetes/kubernetes` also needs `replace` statements to override
+the fake `v0.0.0` versions
+(https://github.com/kubernetes/kubernetes/issues/79384). The
+`go-get-kubernetes.sh` script can be used to update all packages in
+lockstep to a different Kubernetes version. Example usage:
+```
+$ ./release-tools/go-get-kubernetes.sh 1.16.4
+```

release-tools/SIDECAR_RELEASE_PROCESS.md

@@ -0,0 +1,90 @@
+# Sidecar Release Process
+
+This page describes the process for releasing a kubernetes-csi sidecar.
+
+## Prerequisites
+
+The release manager must:
+
+* Be a member of the kubernetes-csi organization. Open an
+  [issue](https://github.com/kubernetes/org/issues/new?assignees=&labels=area%2Fgithub-membership&template=membership.md&title=REQUEST%3A+New+membership+for+%3Cyour-GH-handle%3E) in
+  kubernetes/org to request membership
+* Be a top level approver for the repository. To become a top level approver,
+  the candidate must demonstrate ownership and deep knowledge of the repository
+  through active maintainence, responding to and fixing issues, reviewing PRs,
+  test triage.
+* Be part of the maintainers or admin group for the repository. admin is a
+  superset of maintainers, only maintainers level is required for cutting a
+  release.  Membership can be requested by submitting a PR to kubernetes/org.
+  [Example](https://github.com/kubernetes/org/pull/1467)
+
+## Updating CI Jobs
+Whenever a new Kubernetes minor version is released, our kubernetes-csi CI jobs
+must be updated.
+
+[Our CI jobs](https://k8s-testgrid.appspot.com/sig-storage-csi-ci) have the
+naming convention `<hostpath-deployment-version>-on-<kubernetes-version>`.
+
+1. Jobs should be actively monitored to find and fix failures in sidecars and
+   infrastructure changes early in the development cycle. Test failures are sent
+   to kubernetes-sig-storage-test-failures@googlegroups.com.
+1. "-on-master" jobs are the closest reflection to the new Kubernetes version.
+1. Fixes to our prow.sh CI script can be tested in the [CSI hostpath
+   repo](https://github.com/kubernetes-csi/csi-driver-host-path) by modifying
+   [prow.sh](https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/release-tools/prow.sh)
+   along with any overrides in
+   [.prow.sh](https://github.com/kubernetes-csi/csi-driver-host-path/blob/master/.prow.sh)
+   to mirror the failing environment. Once e2e tests are passing (verify-unit tests
+   will fail), then the prow.sh changes can be submitted to [csi-release-tools](https://github.com/kubernetes-csi/csi-release-tools).
+1. Changes can then be updated in all the sidecar repos and hostpath driver repo
+   by following the [update
+   instructions](https://github.com/kubernetes-csi/csi-release-tools/blob/master/README.md#sharing-and-updating).
+1. New pull and CI jobs are configured by
+   [gen-jobs.sh](https://github.com/kubernetes/test-infra/blob/master/config/jobs/kubernetes-csi/gen-jobs.sh).
+   New pull jobs that have been unverified should be initially made optional.
+   [Example](https://github.com/kubernetes/test-infra/pull/15055)
+1. Once new pull and CI jobs have been verified, and the new Kubernetes version
+   is released, we can make the optional jobs required, and also remove the
+   Kubernetes versions that are no longer supported.
+
+## Release Process
+1. Identify all issues and ongoing PRs that should go into the release, and
+  drive them to resolution.
+1. Download [K8s release notes
+  generator](https://github.com/kubernetes/release/tree/master/cmd/release-notes)
+1. Generate release notes for the release. Replace arguments with the relevant
+  information.
+    ```
+    GITHUB_TOKEN=<token> ./release-notes --start-sha=0ed6978fd199e3ca10326b82b4b8b8e916211c9b --end-sha=3cb3d2f18ed8cb40371c6d8886edcabd1f27e7b9 \
+    --github-org=kubernetes-csi --github-repo=external-attacher -branch=master -output out.md
+    ```
+    * `--start-sha` should point to the last release from the same branch. For
+    example:
+        * `1.X-1.0` tag when releasing `1.X.0`
+        * `1.X.Y-1` tag when releasing `1.X.Y`
+1. Compare the generated output to the new commits for the release to check if
+   any notable change missed a release note.
+1. Reword release notes as needed. Make sure to check notes for breaking
+   changes and deprecations.
+1. If release is a new major/minor version, create a new `CHANGELOG-<major>.<minor>.md`
+   file. Otherwise, add the release notes to the top of the existing CHANGELOG
+   file for that minor version.
+1. Submit a PR for the CHANGELOG changes.
+1. Submit a PR for README changes, in particular, Compatibility, Feature status,
+   and any other sections that may need updating.
+1. Check that all [canary CI
+  jobs](https://k8s-testgrid.appspot.com/sig-storage-csi-ci) are passing,
+  and that test coverage is adequate for the changes that are going into the release.
+1. Make sure that no new PRs have merged in the meantime, and no PRs are in
+   flight and soon to be merged.
+1. Create a new release following a previous release as a template. Be sure to select the correct
+   branch. This requires Github release permissions as required by the prerequisites.
+   [external-provisioner example](https://github.com/kubernetes-csi/external-provisioner/releases/new)
+1. If release was a new major/minor version, create a new `release-<minor>`
+   branch at that commit.
+1. Update [kubernetes-csi/docs](https://github.com/kubernetes-csi/docs) sidecar
+   and feature pages with the new released version.
+1. After all the sidecars have been released, update
+   CSI hostpath driver with the new sidecars in the [CSI repo](https://github.com/kubernetes-csi/csi-driver-host-path/tree/master/deploy)
+   and [k/k
+   in-tree](https://github.com/kubernetes/kubernetes/tree/master/test/e2e/testing-manifests/storage-csi/hostpath/hostpath)