Ceph » Stable releases

h3. HOWTO backport

Based on what would be done for the Giant branch

[[HOWTO update the inventory]]

[[HOWTO summarize test results]]

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

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

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

h3. Synchronized repositories

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

<pre>

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

</pre>

When a Ceph pull request (for instance "rgw acl response should start with <?xml version=1.0 ?>":https://github.com/ceph/ceph/pull/4082) 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":https://github.com/ceph/ceph-qa-suite/pull/370), dedicated branches must be created in the Ceph and ceph-qa-suite repositories. For instance:

<pre>

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

</pre>

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":https://github.com/ceph/ceph-qa-suite/tree/wip-rgw-acl-giant branch must have a "s3-test wip-rgw-acl-giant":https://github.com/ceph/s3-tests/tree/wip-rgw-acl-giant counterpart.