This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
tasks:ceph-release-faq [2023/11/15 22:54] ljflores |
tasks:ceph-release-faq [2023/11/21 18:14] (current) ljflores |
||
---|---|---|---|
Line 2: | Line 2: | ||
The full release process is defined here: https://docs.ceph.com/en/latest/dev/release-process/ | The full release process is defined here: https://docs.ceph.com/en/latest/dev/release-process/ | ||
+ | |||
The following FAQ is based on questions that arose when we previously followed the release process. | The following FAQ is based on questions that arose when we previously followed the release process. | ||
+ | |||
+ | See [[https://www.youtube.com/watch?v=skb-3tI2Ato|Walkthrough: Ceph Release Process]] for a live explanation of this document. | ||
- What if something went wrong with the ceph-tag job and a version commit PR was not created? | - What if something went wrong with the ceph-tag job and a version commit PR was not created? | ||
Line 19: | Line 22: | ||
- Yes. The “ceph-release” rpm is needed for every new major release. If we define a new major release as “X.Y.Z”, the “ceph-release-rpm” step should be followed for every new “X” release (regardless of Y or Z). In other words, if the first major release is 18.1.0, we should complete the “ceph-release-rpm” step. If we had instead started by releasing 18.2.0, the same would be true. However, if we release 18.1.0 and do the “ceph-release-rpm” step, we would not need to follow this step again for 18.2.0. | - Yes. The “ceph-release” rpm is needed for every new major release. If we define a new major release as “X.Y.Z”, the “ceph-release-rpm” step should be followed for every new “X” release (regardless of Y or Z). In other words, if the first major release is 18.1.0, we should complete the “ceph-release-rpm” step. If we had instead started by releasing 18.2.0, the same would be true. However, if we release 18.1.0 and do the “ceph-release-rpm” step, we would not need to follow this step again for 18.2.0. | ||
- The only reason you’d want to do this step more than once for a release is to update /etc/yum.repos.d/ceph.repo. But occurrences of this are rare. | - The only reason you’d want to do this step more than once for a release is to update /etc/yum.repos.d/ceph.repo. But occurrences of this are rare. | ||
- | - What happens if a last minute change needs to be added to a release after the build process has begun? | + | - What happens if a last minute PR needs to be added to a release after the build process has begun? |
- | - If we are at the stage where all distros have been built, and files are signed and are on the signer machine, but we have not yet done sync-push or built containers, the workflow is: | + | - As long as all build artifacts are in the staging area and are not officially released, we can follow this procedure: |
- Delete the tag on https://github.com/ceph/ceph/tags and https://github.com/ceph/ceph-releases/tags | - Delete the tag on https://github.com/ceph/ceph/tags and https://github.com/ceph/ceph-releases/tags | ||
- | - Close the tag PR | + | - Close the tag PR in https://github.com/ceph/ceph/pulls |
- Redo the build step of the release process (https://docs.ceph.com/en/latest/dev/release-process/#starting-the-build) as normal, with `TAG` checked. | - Redo the build step of the release process (https://docs.ceph.com/en/latest/dev/release-process/#starting-the-build) as normal, with `TAG` checked. | ||
+ | - If we need to add a new distro, we need to update it like in this PR: https://github.com/ceph/chacra/pull/307/files |