[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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@xxxxxxxxxxxxx>
 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 
 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
@@ -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@xxxxxxxxxxx $flight
+    $ ./mg-execute-flight -Bplay -Eemail@xxxxxxxxxxx $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:
-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>
 # 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.
-./cs-job-create $flight $job adhoc-xen-boot-x5 \
+./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 \
@@ -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@xxxxxxxxxxx $flight
+./mg-execute-flight -Bplay -Eme@xxxxxxxxxxx $flight

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.