Ceph » Stable releases

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
  • complete
  • backport status
  • backports
  • pending issues
  • pull requests
• hammer
  • complete
  • backport status
  • backports
  • pending issues
  • pull requests

Leads¶

• Ceph : Sage Weil
• rados : Samuel Just
• radosgw / rgw : Yehuda Sadeh
• CephFS / fs : Gregory Farnum
• RBD : Jason Dillaman
• 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.

Who's who¶

Members of the stable releases team are assigned the following roles as of February, 2016.

	v0.94.7	v9.2.1	v9.2.2	v10.2.0
Abhishek Lekshmanan		backup		backup
Abhishek Varshney		driver		driver
Nathan Cutler	driver
Loic Dachary	backup	backup	backup	backup
Xiaoxi Chen	mentee
M Ranga Swami Reddy	mentee	mentee	driver
Gaurav Bafna
Wei-Chung Cheng
Martin Palma
Chris Jones

• Mentee: during the course of a release the driver is available to help understand the stable release 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¶

• HOWTO start backporting a stable release

Add a new point release¶

• HOWTO start working on a new point release

Prepare a new point release¶

1. HOWTO monitor the automated tests AKA nightlies
2. HOWTO schedule an issue for backporting
3. HOWTO document user visible changes
4. HOWTO backport commits
5. HOWTO populate the integration branch
6. HOWTO run integration and upgrade tests
7. HOWTO forensic analysis of integration and upgrade tests
8. HOWTO describe a test result
9. HOWTO merge commits from the integration branch
10. HOWTO synchronize pull requests from different repositories
11. HOWTO resolve issues that are Pending Backport
12. HOWTO get the Ceph lead to decide if it is time for a point release
13. HOWTO get the leads to sign-off on a release
14. 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
• A jenkins job does a bunch of things like changing version numbers, creating a tag and pushing to the Jenkins GIT repository
• Once that process completes the binaries are HTTP POSTed to chacra.ceph.com following the convention in the chacra docs
• Once those are there, Alfredo, ssh into signer.ceph.com pull the binaries from chacra, sign them and upload them into download.ceph.com
• The entire procedure is explained in a document that has not yet been released (Feb 2016).

Retire a stable release¶

• HOWTO 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¶

• HOWTO become a new team member
• HOWTO retire from the team