ReferencePlatforms/Test/Foopy: Difference between revisions

ReferencePlatforms/Test/Foopy (view source)

Revision as of 00:07, 15 December 2011

1,268 bytes added , 15 December 2011

→‎helper scripts to populate /builds

Hwine

Confirmed users

1,364

edits

@@ Line 92: / Line 92: @@
 == helper scripts to populate /builds ==
-Locate the tools/buildfarm/mobile/ directory '''on your laptop''' and run:
+Locate the tools/buildfarm/mobile/ directory '''on your laptop''' and follow these directions to complete the setup of the foopy.
-[[User:Hwine|Hwine]] several key files used in setting up ssh are not checked in. Should they be, or where are the authoritative copies found (foopy_authorized_keys, id_rsa, id_rsa.pub, possibly others)
-* [[User:Bear|Bear]] the ssh files I did not want checked-in (not for any good reason TBH) - they will eventually become part of the puppet setup but foopy's don't exist in the realm of puppet yet
+*Preparation - several key files used in setting up ssh are not checked in. Grab these from a known good production foopy:
+  FOOP=foopyXX # know good foopy
+  scp ctlbld@$FOOP:.ssh/{id_rsa{,.pub},authorized_keys} .
+  mv -i authorized_keys foopy-authorized_keys
+*If your ssh key isn't already in the distributed authorized_keys, do
+  cat ~/.ssh/id_rsa.pub >> foopy-authorized_keys
+*One time ssh environment setup (where XX is the foopy number):
   ./foopies.sh ssh ##
+*At this point, you may want to [[#test basic foopy functionality]]
+*If the final <tt>tegras.json</tt> is ready
   ./foopies.sh ##
-where ## is the foopy number.  The ssh step can only be run once, so run it seperately from the others.
 After the above has been run, it's time to setup the cronjobs:
 '''Note''': most likely the scp commands will not have set +x for any /builds/*.sh scripts
-[[User:Hwine|Hwine]] where does this occur? on new foopy or from "master"
+On the new foopy:
-* [[User:Bear|Bear]] on the foopy as the cltbld user
   cd /builds
@@ Line 113: / Line 116: @@
 Running tegra_stats.sh manually once allow you to check that it is working :), but more importantly it also allows you to answer "yes" to the ssh question about connecting to the remote host.
+===test basic foopy functionality===
+If you want to test basic foopy sanity prior to full tegra deployment, here's the process:
+# borrow a tegra from staging
+#* ''convention'' take one from foopy05 that looks idle
+#* run <tt>cd /builds; ./stop_cp.sh tegra-XXX</tt> for the one you're stealing
+# tweak your local laptop copy of foopies.sh to configure only the borrowed tegra
+# finalize configuration using <tt>./foopies.sh ##</tt>
+# start your tegra
+#* on foopy, run <tt>cd /builds; ./start_cp.sh</tt>
+# verify right number of processes running
+#* <tt>ps awx | grep tegra-XXX</tt>
+#* should be at least 1 twistd & 2 clientproxies
+# verify contents of <tt>/builds/tegra-XXX</tt> directory
+#* should be log files, buildbot.tac, clientproxy.py
+# verify tegra shows on [http://dev-master01.build.scl1.mozilla.com:8160/buildslaves?no_builders=1|staging buildbot master]
+# verify tegra online
+#* <tt>telnet tegra-XXX 20701</tt>
+# stop your borrowed tegra
+#* <tt>cd /builds; ./stop_cp.sh</tt>
+# return the tegra to staging
+#* log into its real foopy (likely foopy05)
+#* run <tt> cd /builds ; ./start_cp tegra-XXX</tt>
+# remove the test configration on your new foopy
+#* <tt>cd /builds ; ls -d tegra-*</tt>
+#* you should '''only''' see the one borrowed tegra
+#* <tt>rm -rf *</tt>
 = Future reference =