]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commitdiff
doc/dev/repo-lab-access: notes
authorSage Weil <sage@inktank.com>
Sun, 28 Jul 2013 23:17:50 +0000 (16:17 -0700)
committerSage Weil <sage@inktank.com>
Sun, 28 Jul 2013 23:17:50 +0000 (16:17 -0700)
Signed-off-by: Sage Weil <sage@inktank.com>
doc/dev/repo-lab-access.rst [new file with mode: 0644]

diff --git a/doc/dev/repo-lab-access.rst b/doc/dev/repo-lab-access.rst
new file mode 100644 (file)
index 0000000..706f02e
--- /dev/null
@@ -0,0 +1,88 @@
+Notes on Ceph repositories and test lab
+=======================================
+
+Special branches
+----------------
+
+* ``master'': current tip (integration branch)
+* ``next'': pending release (feature frozen, bugfixes only)
+* ``last'': last/previous release
+* ``dumpling'', ``cuttlefish'', ``bobtail'', ``argonaut'', etc.: stable release branches
+* ``dumpling-next'': backports for stable release, pending testing
+
+Rules
+-----
+
+The source repos are all on github.
+
+* Any branch pushed to ceph.git will kick off builds that will either
+  run unit tests or generate packages for gitbuilder.ceph.com.  Try
+  not to generate unnecessary load.  For private, unreviewed work,
+  only push to branches named ``wip-*''.  This avoids colliding with
+  any special branches.
+
+* Nothing should every reach a special branch unless it has been
+  reviewed.
+
+* Preferred means of review is via github pull requests to capture any
+  review discussion.
+
+* For multi-patch series, the pull request can be merged via github,
+  and a Reviewed-by: ... line added to the merge commit.
+
+* For single- (or few-) patch merges, it is preferable to add the
+  Reviewed-by: directly to the commit so that it is also visible when
+  the patch is cherry-picked for backports.
+
+* All backports should use ``git cherry-pick -x'' to capture which
+  commit they are cherry-picking from.
+
+
+Teuthology lab hardware
+-----------------------
+
+* 96 plana: 8 core, 4 disk, 1gig and 10gig networks.  Used for nightly runs.
+
+* 64 burnupi: Dell R515s: 6 core, 8 disk, 1gig and 10gig networks, moderate CPU.  crummy SAS expanders.
+
+* 120 mira: 8 core, 8 disks, 1gig network.  older hardware, flakier disks
+
+* 8 vercoi: 24 core, RAID; VM hosts
+
+* 4 senta: 25 core: VM hosts
+
+* 36 saya: Calxeda ARM7 nodes (for testing)
+
+* 24 tala: Calxeda ARM7 nodes (gitbuilder)
+
+* ~200 vps: VMs running on mira hardware
+
+Locking machines
+----------------
+
+* All tests pull their builds from gitbuilder.ceph.com.
+
+* Anybody can lock machines with ``teuthology-lock --lock-many NUM
+  --machine-type TYPE''.
+
+* Machines are locked as ``whoami''@``hostname -s''.  --owner to
+  choose otherwise.
+
+* Automated tests current run on the ``plana''; please avoid locking
+  these for personal use.
+
+* To unlock, please use ``teuthology-nuke -t list.yaml -r -u'', which
+  will reboot and clean up any leftover test state before unlocking
+  (or fail to unlock).  It looks for a ``targets::'' section in the
+  yaml, so the regular job yaml will work.  You can get a list of all
+  locked machines with ``teuthology-lock --list-targets''.
+
+* ``teuthology-lock -a --brief'' or ``teuthology-lock --summary'' to
+  see what is locked and by whom.
+
+* Be conscientious about scheduling entire qa runs.  Coordinate
+  utilization on IRC.  Make sure you are running the latest version
+  ceph-qa-suite.git and teuthology.git.
+
+* Results for scheduled runs appear in /a/$jobname on the teuthology
+  machine.  ``ls -alt | head'' to find them.