Differences

This shows you the differences between two versions of the page.

--- devplayground [2023/10/17 17:59] – [Playing Nice] pdonnell
+++ devplayground [2026/09/14 14:23] (current) – djgalloway
@@ Line 7: / Line 7: @@
 ===== Machines ====
-^ Name ^ Notes ^
+^ Name                                             ^ Notes            ^
-| [[hardware:senta|senta01.front.sepia.ceph.com]]  | General purpose |
+| [[hardware:vossi|vossi01.front.sepia.ceph.com]]  | General purpose  |
-| [[hardware:senta|senta02.front.sepia.ceph.com]]  | General purpose |
+| [[hardware:vossi|vossi04.front.sepia.ceph.com]]  | CephFS Team      |
-| [[hardware:senta|senta03.front.sepia.ceph.com]]  | General purpose |
+| [[hardware:vossi|vossi06.front.sepia.ceph.com]]  | RADOS Team       |
-| [[hardware:vossi|vossi01.front.sepia.ceph.com]]  | General purpose |
+| [[hardware:folio|folio02.front.sepia.ceph.com]]  | General purpose  |
-| [[hardware:vossi|vossi04.front.sepia.ceph.com]]  | CephFS Team     |
+| [[hardware:folio|folio13.front.sepia.ceph.com]]  | General purpose  |
-| [[hardware:vossi|vossi04.front.sepia.ceph.com]]  | RADOS Team      |
-| [[hardware:folio|folio02.front.sepia.ceph.com]]  | General purpose |
 ==== Playing Nice ====
-Developer playgrounds should be able to build the ''main'' branch. It is okay to use ''./install-deps.sh'' top-level scrip from the ceph source tree to update dependencies. Do not run that script from an older release of Ceph as it may break other developer's work. If you need to build an older release, lock a throwaway node like [[hardware:smithi]] and build there. Or, use a container to do the build/testing!
+Developer playgrounds should be able to build the ''main'' branch. It is okay to use ''./install-deps.sh'' top-level script from the ceph source tree to update dependencies. Do not run that script from an older release of Ceph as it may break other developer's work. If you need to build an older release, lock a throwaway node like [[hardware:smithi]] and build there. Or, use a container to do the build/testing!
 Using the developer machines to look at teuthology QA artifacts is encouraged. Try to avoid using a text editor to look at large (1GB+) debug logs as this can be RAM intensive/disruptive. Instead, prefer ''less'' or use ''tail -c xM | $EDITOR -'' to look at portions of the log in a text editor.
 Many of the developer playground nodes have extra disks for testing Ceph. It's okay to use these for ''vstart'' clusters but it may be more flexible to build LVM volumes on top of these devices so others may use them too.
+==== MOTD ====
+Please use this MOTD for these playground machines:
+<code>
+*******************************************************************************
+                                Welcome!
+      This machine is a Ceph Developer Playground for shared use.  Please
+          see the following wiki document for guidelines and a list of
+                              available machines.
+             https://wiki.sepia.ceph.com/doku.php?id=devplayground
+                           Create support tickets at:
+                     https://tracker.ceph.com/projects/lab
+                                    Thanks!
+*******************************************************************************
+</code>
+==== Configuring CephFS Mounts ====
+The following ansible playbook can be run to setup CephFS mounts on a new developer playground machines: https://wiki.sepia.ceph.com/doku.php?id=services:cephfs
+==== Teuthology scheduling ====
+Configure the dev playground node to schedule jobs:
+<code>
+sudo tee /etc/teuthology.yaml <<EOF
+default_machine_type: smithi
+queue_host: teuthology.front.sepia.ceph.com
+queue_port: 11300
+active_machine_types:
+  - smithi
+  - trial
+  - gibba
+EOF
+</code>
+Note: killing a run is (generally) still necessary on [[services:teuthology|teuthology host]]. This is because teuthology-kill requires killing the test processes running there.
+==== Configuring LVM volumes using spare disks ====
+When setting up a fresh Developer Playground machine, configure an LVM VolumeGroup for use by users. Volumes can be provisioned for a build directory, OSD block device, or anything else needed.
+Note: no redundancy is configured below (i.e. RAID). If a disk is lost, all volumes will be affected.
+<code>
+sudo pvcreate /dev/$DISK
+</code>
+Do this for every disk. This is an ad-hoc process because all nodes are different. Also, some disks may have been used in the past so they will need wiped first:
+<code>
+sudo wipefs -a /dev/$DISK
+</code>
+Once all disks are added as physical volumes, it's then possible to add to a VolumeGroup:
+<code>
+sudo vgcreate DevPlayground $DISKS
+</code>
+Finally make a volume for yourself:
+<code>
+sudo lvcreate -L 256G DevPlayground -n $(whoami)-build
+sudo mkfs.xfs /dev/DevPlayground/$(whoami)-build
+mkdir $HOME/build
+chmod 000 $HOME/build
+sudo chattr +i $HOME/build
+echo "/dev/DevPlayground/$(whoami)-build $HOME/build xfs defaults 1 1" | sudo tee -a /etc/fstab
+sudo systemctl daemon-reload
+sudo mount $HOME/build
+</code>
+and some OSD block devices:
+<code>
+for i in `seq 0 8`; do sudo lvcreate -L 16G DevPlayground -n $(whoami)-osd.$i ; done
+</code>
+Make those OSDs owned by you:
+<code>
+printf 'ENV{DM_VG_NAME}=="DevPlayground" ENV{DM_LV_NAME}=="%s-*" OWNER="%s" GROUP="users"\n' $(whoami) $(whoami) | sudo tee -a /etc/udev/rules.d/99-lvmowner.rules
+sudo udevadm control --reload-rules
+sudo udevadm trigger
+</code>
+Then you can use those devices with vstart.sh:
+<code>
+wipefs -a /dev/DevPlayground/$(whoami)-osd.*
+shred -v -n 0 -z -s 16M /dev/DevPlayground/$(whoami)-osd.*
+env OSD=8 ~/ceph/src/vstart.sh \
+    --bluestore-devs $(echo /dev/DevPlayground/$(whoami)-osd.* | tr ' ' ',')
+</code>
+Feel free to make any other volumes that you require.