[OSSTEST PATCH 01/24] README: Advise using `play' for playground flights

[Ian Jackson <ian.jackson@eu.citrix.com>]

Any flight eventually blessed `adhoc' is supposed to contain, in the
db, accurate information corresponding to a real clean run.  This is
not appropriate for playing about.

Using `play' usefully disables a number of safety catches, including
one which prevents post-startup flight modification.

Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
 README | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/README b/README
index 0e93f43..b45058d 100644
--- a/README
+++ b/README
@@ -619,8 +619,8 @@ ExecutiveDbOwningRoleRegexp
    changes - because, that role will end up owning the database objects.
    Defaults to `osstest'.
 
-Adhoc/Custom Flights
-====================
+Flights for by-hand testing
+===========================
 
 Normally a flight is constructed using "make-flight", either via
 "./standalone make-flight" or by calling make-flight (or another
@@ -638,14 +638,14 @@ A fresh empty flight is created by using the "cs-flight-create"
 script. It takes as arguments a "blessing" and a "branch" and on
 success prints the new flight number.
 
-The blessing should almost always be "adhoc". The branch doesn't
+The blessing should almost always be "play". The branch doesn't
 really matter, if you are testing something related to a failure on a
-given branch you may as well use that, otherwise "adhoc" or
+given branch you may as well use that, otherwise "play" or
 "xen-unstable" is a reasonably fallback.
 
 Thus the normal way to invoke cs-flight-create is:
 
-    $ flight=`./cs-flight-create adhoc adhoc`
+    $ flight=`./cs-flight-create play play`
 
 Which results in a $flight which can be used for the remainder of the
 configuration.
@@ -687,20 +687,20 @@ run-job/$recipe" which runs the required test steps. There are plenty
 of examples in sg-run-job.
 
 Once the flight is created it is run using mg-execute-flight. It is
-usual to pass -Badhoc (to set the target blessing) and -Eemail to set
+usual to pass -Bplay (to set the target blessing) and -Eemail to set
 the destination for the test report as well as giving the flight:
 
-    $ ./mg-execute-flight -Badhoc -Eemail@example.com $flight
+    $ ./mg-execute-flight -Bplay -Eemail@example.com $flight
 
 A worked example, including a custom recipe (in this case to reboot
 Xen five times on the host) and .
 
-Custom sg-run-job-adhoc, requires a single host (ident "host") and
+Custom sg-run-job-play, requires a single host (ident "host") and
 runs ts-host-reboot + a ping check 5 times:
 
 ----START-------
-proc need-hosts/adhoc-xen-boot-x5 {} { return host }
-proc run-job/adhoc-xen-boot-x5 {} {
+proc need-hosts/play-xen-boot-x5 {} { return host }
+proc run-job/play-xen-boot-x5 {} {
     repeat-ts 5 xen-boot.repeat \
                ts-host-reboot     host \; \
                ts-host-ping-check host
@@ -719,13 +719,13 @@ lnxrev=<some revision of Linux which we want to test>
 template=123456
 
 # Create the flight
-flight=`./cs-flight-create adhoc adhoc`
+flight=`./cs-flight-create play play`
 echo $flight
 
 # Create a test job from scratch, many of the runvars cribbed from a
 # random job in a real flight created by make-flight.
-job=adhoc-amd64-amd64-xen-boot
-./cs-job-create $flight $job adhoc-xen-boot-x5 \
+job=play-amd64-amd64-xen-boot
+./cs-job-create $flight $job play-xen-boot-x5 \
     all_hostflags=arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test \
     arch=amd64 toolstack=xl enable_xsm=false kernkind=pvops \
     host=$host
@@ -746,5 +746,5 @@ job=adhoc-amd64-amd64-xen-boot
 ./cs-adjust-flight $flight runvar-set $job kernbuildjob build-amd64-pvops
 
 # Now run the job.
-./mg-execute-flight -Badhoc -Eme@example.com $flight
+./mg-execute-flight -Bplay -Eme@example.com $flight
 ----END---------
-- 
2.1.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel