Skip to content

Latest commit

 

History

History
106 lines (98 loc) · 6.09 KB

SIDECAR_RELEASE_PROCESS.md

File metadata and controls

106 lines (98 loc) · 6.09 KB
Raw

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 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

Updating CI Jobs

Whenever a new Kubernetes minor version is released, our kubernetes-csi CI jobs must be updated.

Our CI jobs 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.
  2. "-on-master" jobs are the closest reflection to the new Kubernetes version.
  3. Fixes to our prow.sh CI script can be tested in the CSI hostpath repo by modifying prow.sh along with any overrides in .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.
  4. Changes can then be updated in all the sidecar repos and hostpath driver repo by following the update instructions.
  5. New pull and CI jobs are configured by adding new K8s versions to the top of gen-jobs.sh. New pull jobs that have been unverified should be initially made optional by setting the new K8s version as experimental.
  6. 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.
  2. Download v2.8+ K8s release notes generator
  3. Generate release notes for the release. Replace arguments with the relevant information.
    • Clean up old cached information (also needed if you are generating release notes for multiple repos) 
      rm -rf /tmp/k8s-repo
    • For new minor releases on master: 
      GITHUB_TOKEN=<token> release-notes --discover=mergebase-to-latest
--github-org=kubernetes-csi --github-repo=external-provisioner
--required-author="" --output out.md
    • For new patch releases on a release branch: 
      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
  4. Compare the generated output to the new commits for the release to check if any notable change missed a release note.
  5. Reword release notes as needed. Make sure to check notes for breaking changes and deprecations.
  6. 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.
  7. Submit a PR for the CHANGELOG changes.
  8. Submit a PR for README changes, in particular, Compatibility, Feature status, and any other sections that may need updating.
  9. Check that all canary CI jobs are passing, and that test coverage is adequate for the changes that are going into the release.
  10. Make sure that no new PRs have merged in the meantime, and no PRs are in flight and soon to be merged.
  11. 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
  12. If release was a new major/minor version, create a new release-<minor> branch at that commit.
  13. Check image build status.
  14. Promote images from k8s-staging-sig-storage to k8s.gcr.io/sig-storage. From the k8s image repo, run ./generate.sh > images.yaml, and send a PR with the updated images. Once merged, the image promoter will copy the images from staging to prod.
  15. Update kubernetes-csi/docs sidecar and feature pages with the new released version.
  16. After all the sidecars have been released, update CSI hostpath driver with the new sidecars in the CSI repo and k/k in-tree