HOWTO » History » Revision 92
« Previous |
Revision 92/187
(diff)
| Next »
Loïc Dachary, 12/14/2015 02:13 PM
Introduction¶
Backporting and the maintenance of a stable release begins when a new stable Ceph release is published. Commits from the master branch are cherry-picked to the stable branch and run through integration and upgrade tests. After a few weeks a point release is published. This repeats until the the stable release is retired. Backporting is focused on fixing bugs and development on the master branch is expected to add new features but both share the same workflow.
Overview of the backports in progress¶
- infernalis
- hammer
- firefly
Leads¶
- Ceph : Sage Weil
- rados : Samuel Just
- radosgw / rgw : Yehuda Sadeh
- CephFS / fs : Gregory Farnum
- RBD : Josh Durgin
- build/ops : Ken Dreyer
Note: It may be useful to know the leads of other projects which have a different lifecycle but depend on Ceph. For instance Gregory Meno is the lead of Calamari
Who's who¶
Members of the stable releases team are assigned the following roles as of November, 2015.
v0.80.12 | v0.94.6 | v9.2.1 | |
Abhishek Lekshmanan | backup | ||
Abhishek Varshney | backup | driver | |
Nathan Cutler | backup | driver | |
Loic Dachary | driver | ||
Robin Hugh Johnson | mentee | ||
M Ranga Swami Reddy | mentee |
- Mentee: during the course of a release the driver is available to help understand the stable releaes workflow
- Driver: responsible for making sure the release is moving forward
- Backup: helps the driver and replaces her/him when she/he is not available
- Sage Weil, Samuel Just, Yehuda Sadeh, Gregory Farnum, Josh Durgin, Ken Dreyer : leads
HOWTO¶
The following describes in detail and in chronological order, the steps to follow for backporting and maintaining stable releases.
Add a new stable release¶
Add a new point release¶
Prepare a new point release¶
- HOWTO monitor the automated tests AKA nightlies
- HOWTO schedule an issue for backporting
- HOWTO document user visible changes
- HOWTO backport commits
- HOWTO populate the integration branch
- HOWTO run integration and upgrade tests
- HOWTO forensic analysis of integration and upgrade tests
- HOWTO describe a test result inline or HOWTO summarize test results in a separate issue
- HOWTO merge commits from the integration branch
- HOWTO synchronize pull requests from different repositories
- HOWTO resolve issues that are Pending Backport
- HOWTO get the Ceph lead to decide if it is time for a point release
- HOWTO get the leads to sign-off on a release
- HOWTO write the release notes
Publish a stable release¶
- Study https://github.com/ceph/ceph-build/ and http://jenkins.ceph.com/ to figure out how it is used to update http://ceph.com/debian-hammer/ and http://ceph.com/rpm-hammer/
- The jenkins job is http://jenkins.ceph.com/job/ceph/ and requires some setup
- The ceph-jenkins-build ansible setup does a bunch of things like changing version numbers, creating a tag and pushing to the Jenkins GIT repository
- once that tag is created that can be used to trigger a build in the jenkins ui when the build is completed you are required to run a bunch of scripts in the jenkins server they sign and re-index the repositories and then synchronize them with ceph/(rpm|debian)-$release. Those scripts need to be edited by hand depending on the type of release and where you are pushing them to (e.g. testing vs firefly vs hammer)
- for hammer a new repository was created by hand and it is documented as a script
Retire a stable release¶
Recurring duties expected from backporters¶
- HOWTO triage incoming backport pull requests
- HOWTO triage incoming Pending backport issues
- fill in the missing releases
Organize the stable releases and backports team¶
Updated by Loïc Dachary over 8 years ago · 92 revisions