Ceph » Stable releases

HOWTO backport¶

Based on what would be done for the Giant branch

HOWTO update the inventory

Major release (e.g. first hammer release) QA suites results, open issues summarization process¶

• all planned features were committed to the branch
• ceph QA suites are being executed by "nightlies" (crontab teuthology@theuthology in Sepia lab)
• a new section is added to the http://tracker.ceph.com/rb/master_backlog/ceph-releases# , as for example for "hammer v0.94.1" with version number
• all suites listed as tasks and results summaries + related tickets are listed there
• as suite passed, and all issues resolved, the task is marked a resolved and thus indicates readiness for the final release cut

Backport issues¶

The helper snippet at http://workbench.dachary.org/dachary/ceph-workbench/issues/3 can be used to semi automate the process below

• For each entry at http://workbench.dachary.org/ceph/ceph-backports/wikis/giant#issues-that-need-backporting
• git cherry-pick -x the commits from the pull request that was targettig master (not from the pull requests targeting stable branches)
• create a pull request with the backport with a reference to the issue and set the milestone to giant
• add a reference to the pull request in the issue
• if the make check bot finds a problem, fix it

Collect pending pull requests into an integration branch¶

The snippet at http://workbench.dachary.org/dachary/ceph-workbench/issues/4 can help

• create a giant-backport branch
• fetch all pull requests from github
• git merge all pull requests
• modify the pull requests individually to fix merge conflicts (i.e. they must merge cleanly, which may involving aggregating two pull requests into a single one designed to properly resolve the conflict)
• compile with ./autogen.sh ; ./configure ; make -j4
• modify the pull requests individually to fix compilation errors

Format of teuthology analysis entries¶

For instance http://tracker.ceph.com/issues/11153#rgw is structured like so:

• In chronological order
• The command line (that can be copy/pasted) used to run the suite
• A bullet point with the URL to the suite run in pulpito prefixed by
  • running if the run is not complete
  • red if the run has at least one error
  • green if the run has no error
• If the run has at least one error, the output of the fail formatter snippet (found at http://workbench.dachary.org/dachary/ceph-workbench/issues/2 is appened to it) is added and edited when the errors are analyzed
• When an error is analyzed, the link to the error is prefixed with
  • environmental noise if it must be run again because it failed for reasons unrelated to the test itself (DNS error etc.)
  • known bug and a URL to the bug (not just the number of the bug)
  • new bug and a URL to the newly created bug if it was discovered during the analysis of this error: it is likely to be a regression

Synchronized repositories¶

When running teuthology tests for a given branch (say giant), the ceph-qa-suite branch must match. In the simplest case it is enough to write:

teuthology-suite --suite-branch giant ... --ceph giant ...

When a Ceph pull request (for instance rgw acl response should start with ) needs to be synchronized with a ceph-qa-suite pull request (for instance create a new get_acl helper to ensure proper xml is compared), dedicated branches must be created in the Ceph and ceph-qa-suite repositories. For instance:

teuthology-suite --suite-branch wip-rgw-acl-giant ... --ceph giant-backports ...

Note that it is not possible to specify a branch that is outside of the Ceph or ceph-qa-suite repositories: write access to these repositories is necessary.

For S3 tests an additional repository must be synchronized in a similar way https://github.com/ceph/s3-tests: there must exist a branch with the same name as the branch specified with --suite-branch. For instance the ceph-qa-suite wip-rgw-acl-giant branch must have a s3-test wip-rgw-acl-giant counterpart.