Ian Jackson [Fri, 4 Sep 2015 10:46:37 +0000 (11:46 +0100)]
cs-bisection-step: Properly handle external job refs in template
cs-bisection-step has had, for a long time, code which is supposed to
handle the situation where the template flight contains build job
references to other flights.
However:
- The regexp to spot these other-flight job reference runvars would
never match because it said \s where \S was probably intended (and
. would be better);
- If it were to match, the flight and job arguments to the recursive
preparejob invocation were the wrong way round. preparejob takes
the job name first.
Fix these two bugs. Now it does seem to work properly.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 4 Sep 2015 10:38:35 +0000 (11:38 +0100)]
cs-bisection-step: Print our command line at the start
The usual approach for debugging the cs-bisection-step is to repro the
problem (with --max-flight), which is most easily done by copying the
command line provided during a run which did the wrong thing.
Print the command line at startup, so that it appears in the report.
This will save us grobbling through the logs and cron mail.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Find all the places where adhoc-revtuple-generator runs subprograms
and have it add set -x (either by adding $OSSTEST_AHRTG_SETX to an
existing set -e, or using $setx which is either : or `set -x').
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 3 Sep 2015 10:39:37 +0000 (11:39 +0100)]
cr-daily-branch: Make sg-report-flight ignore bisections
sg-report-flight when testing X' (with a baseline of X) can justify a
failure of T(X',Y,Z) with a bisection failure of T(X,Y'',Z).
If Y'' breaks T then this makes it look to sg-report-flight like T was
already broken in X; cr-daily-branch could then push X' even though it
is actually broken.
This happened rarely, because cr-daily-branch's sg-report-flight would
only look at flights on the right branch, so only a bisection of T on
that branch can cause this, but nevertheless this can produce bad
pushes.
So: have cr-daily-branch pass a --blessings option to cr-daily-branch,
so that it only looks at (usually) `real' rather than the default of
`real' and also `real-bisect'.
An alternative, more complicated, approach would be for
sg-report-flight to compare versions of Y, Z, et al, when looking for
justifications, but I'm not sure this is desirable because it would
effectively reset the heisenbug compensator each time any other tree
changed.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 28 Aug 2015 11:28:26 +0000 (11:28 +0000)]
Other-revision-jobs: Update cs-bisection-step
This is rather more subtle. We want to be able to bisect over all the
relevant inputs.
What we actually want to do if one of the *prev* tests fail is to
treat the "previous Xen branch" as a separate "tree" when bisecting,
so each revision tuple has both "current" and "old" Xen versions.
That way if the stable-4.x branch has broken forward migration, we
will report it properly.
Indeed, this needs to be extended not just to the Xen revision, but
all the inputs to the *prev* build.
We achieve this with new concept `other-revision job suffix',
introduced in the previous patch. The bisector now works internally
always with tree names which are `<tree>[ <suffix>]' (delimited by a
space). (Henceforth, we'll call `[ <suffix>]' the `othrev'.)
That is, all the revisions specified in prev build jobs are treated as
revisions of different trees to the revisions of apparently-same trees
in non-prev jobs.
The specific changes needed to cs-bisection-step are very small. We
only need to adjust the code which reads and writes the database:
* When we do the cross join on urls and revisions which generates the
rev tuple for a particular flight, also have the database compute
the othrev for each tree. Then, print the othrev in the debug
output, and append it to the tree name.
That resulting name is used everywhere:
It affects `mixed revision' detection, so we consider build-*-prev
jobs with differing revisions to problematic, or main-revision build
jobs with differing revisions, but we treat each category of build
job separately so the fact that the prev and main build jobs have
different revisions is fine.
The name is used for the key that is returned from flight_rmap.
Thence it is used for the Name in @treeinfos, and therefore the
results from flight_rtuple will be terms of this decorated tree
namespace.
* When we are preparing a new job to go, we need to (effectively) undo
this transformation. The query which finds the `tree_' variables
for a particular tree name is arranged to take an additional
parameter, which is the othrev. If the othrev does not match the
job, the name is not returned in the results.
Actually, because both the job and the othrev are query parameters,
what happens is either that they match (ie, the othrev in the tree
name from @treeinfos is indeed the othrev for the job we are
constructing) in which case we process the variable as before; or
they don't match, in which case the query contains contradictory
conditions in its AND clauses, and returns no rows.
So the ultimate effect is that we process each Name from @treeinfos
only if it is for the this kind of job. This slightly convoluted
implementation arises from the fact that the job-to-othrev mapping
is implemented as SQL, so we need to ask the database.
There is no need to change any of the output processing and reporting,
because "<tree> prev" is a perfectly good thing to print in all the
relevant contexts.
And there is no need to change how we drive adhoc-revtuple-generator,
because we do not pass it tree names at all, only urls.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Fri, 28 Aug 2015 14:17:09 +0000 (15:17 +0100)]
Other-revision-jobs: Provide other_revision_job_suffix
This is a string, a function of the job name, that identifies the
class of `other revisions'. It is empty for main-revision jobs
and currently there is only `<delimiter>prev' for build-*-prev.
We are going to use this in the bisector.
Reimplement main_revision_job_cond in terms of this. No functional
change, except that the SQL optimiser may have more work to do.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Fri, 28 Aug 2015 11:16:40 +0000 (11:16 +0000)]
Other-revision-jobs: Provide central test
Since 75fbbc19 "Arrange to test migration from the previous Xen
version", some flights have contained additional jobs build-*-prev,
which build a different revision of xen.git.
However, this violates an existing assumption in several of the
automatic archaeologists, namely that a flight should contain only
runvars referring to a single revision of a tree.
We will need to adjust all the places where this assumption is baked
in. The question arises, as to how the code in general is supposed to
know. There are many possible schemes, but almost all of them would
involve some kind of schema change and/or would be violated by
now-recorded history.
For now we adopt the following rule: the job name tells you. That is,
revision runvars in jobs with certain job names are disregarded. We
call non-disregarded jobs `main-revision jobs', since they use the
`main' revisions of everything, and others `other-revision jobs'.
We provide a single function in Osstest.pm which takes as argument a
SQL expression string representing a job name, and returns a SQL
expression string evaluating to a boolean, specifying whether the job
is a main revision job. This can be used in queries.
In subsequent patches I will go through all plausibly-relevant output
from
git-grep 'revision_\|revision\\\\_'
and update each piece in turn.
There are obviously-irrelevant hits in TestSupport (build_clone and
store_vcs_revision) and in BuildSupport.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Wei Liu [Tue, 11 Aug 2015 20:25:09 +0000 (21:25 +0100)]
Toolstack/libvirt: use URI in migration command
Virsh migrate expects an URI, not a host. We don't actually care what
kind of transport it uses, the main objective is to test migration, so
use xen+ssh for the time being.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- added --live and factored out $duri ]
Ian Campbell [Tue, 11 Aug 2015 16:25:10 +0000 (17:25 +0100)]
Arrange to test migration from the previous Xen version
There are several steps to this:
- Identify $prevxenbranch, that is the branch which precedes
$xenbranch.
- Create appropriate build jobs.
- Add support in ts-xen-install for overriding {xen,}buildjob on a
per-ident basis
- Add a new receipt test-pair-oneway which only migrates from
src_host to dst_host and not the reverse
- Create appropriate test jobs, overridding the default builds for
src_host.
Currently we only do this for xen* branches and using xl, but in the
future we may wish to add to the libvirt branch too.
In make-flight if REVISION_PREVXEN is not supplied (e.g. called from
standalone-reset or by hand etc) then we create the build-$arch-prev jobs
with no revision_xen, same as build-$arch
It would be nice to try and reuse the builds from the last flight
which tested the $prevxenbranch baseline. I've not dont that here.
Ian Campbell [Wed, 5 Aug 2015 12:48:27 +0000 (13:48 +0100)]
libvirt: Pass correct arguments to virsh migrate
$dst is a host hash/object, resulting in:
2015-08-04 22:35:25 Z executing ssh ... root@172.16.144.34 virsh
migrate debian.guest.osstest HASH(0x28f4310)
bash: -c: line 0: syntax error near unexpected token `('
bash: -c: line 0: `virsh migrate debian.guest.osstest HASH(0x28f4310)'
Switch to using the same pattern as xl.pm, which is to call the
argument (containing the host hash) $dho and for $dst to be a local
variable containing $dho->{Name}.
Also s/$ho/$sho/ to match xl.pm, since I think that is clearer about
what role everything has.
Fix the prototype too while editing this function.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Wei Liu <wei.liu2@citrix.com>
Ian Campbell [Mon, 27 Jul 2015 12:51:27 +0000 (13:51 +0100)]
ts-debian-hvm-install: Use xargs -0 to avoid massive filelist in logs.
The current arrangement is a bit odd, I'm not sure why it would be
that way and it results in a huge list of files in the middle of the
log which is rather boring to scroll through.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Mon, 27 Jul 2015 12:51:26 +0000 (13:51 +0100)]
ts-debian-hvm-install: use di_installcmdline_core
This is primarily to get DEBIAN_FRONTEND=text, for easier to read
logging.
Previously the command line consisted of the console and
preseed/file=/preseed.cfg. After this it is more complex.
The preseed file uses file= which is an alias for preseed/file. Extra
options are given including DEBIAN_FRONTEND and DEBCONF_DEBUG and the
following are preseeded via the command line:
Previous implied were "auto=true preseed" which are now explicit.
In addition the following harmless (in this context) options are
added:
hw-detect/load_firmware=
hostname=
netcfg/dhcp_timeout=
netcfg/choose_interface=
The caller could also cause debconf/priority to be set, but doesn't
here.
ts-debian-di-install in the distro test series also uses
di_installcmdline_core for guest uses.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Mon, 27 Jul 2015 12:51:25 +0000 (13:51 +0100)]
ts-debian-hvm-install: Remove VGA console runes.
I don't think there is any point in these since c60b6d20b0fd
"ts-debian-hvm-install: Arrange for installed guest to use a serial
console" and they represent an unexplained difference between the
islinux and grub cases.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Wed, 5 Aug 2015 10:42:10 +0000 (11:42 +0100)]
Executive: Support host_check_allocated outside a job.
When called outside a job there are no hostflags, so get_hostflags
cannot be used. Instead assume a new pseudo-flag "OUTSIDE-JOB" when
there is no $job.
Otherwise uses of select_host such as "mg-hosts mkpxedir" fail.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- wrong commit message ]
Wei Liu [Sun, 12 Jul 2015 11:29:02 +0000 (12:29 +0100)]
TestSupport: don't put kernel= in HVM config when using xl and libvirt
Setting kernel to hvmloader is ignored in xl but not in libvirt. Libvirt
config converter will translate that then pass it to QEMU. QEMU
complains there is no kernel called hvmloader and exits.
Remove this option for xl and libvirt. Xl is not affected and libvirt
will be able to create HVM guest. Xend might still need it.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- use toolstack($ho) not $ho->{Toolstack} ]
Wei Liu [Sun, 8 Feb 2015 16:05:16 +0000 (16:05 +0000)]
ts-debian-hvm-install: stub out libvirt + ovmf / rombios
Libvirt's configuration converter doesn't know how to deal with BIOS
selection. The end result is it always use the default one (seabios).
Stub out ovmf and rombios to avoid false positive results.
This restriction will be removed once libvirt's converter knows how to
deal with BIOS selection.
Note that we don't expect to see such configurations any time soon.
These configurations will be filtered in make-flight. The changes here
are more of an extra level of safety check.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Wei Liu [Sun, 8 Feb 2015 15:44:31 +0000 (15:44 +0000)]
sg-run-job: remove save/restore dependency on local migration support
Since we've introduced different checks for save / restore and local
migration, it's possible to run save / restore tests without running
local migration tests.
Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Tue, 16 Dec 2014 12:12:44 +0000 (12:12 +0000)]
osstest migrate support check catch -> variables
The goal here is to skip the following test steps if the check fails.
Instead of using catch to turn an exception into value, we can just
use spawn-ts and reap-ts to do that. This pattern is useful when we add
in extra check for save / restore check later.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ wei: write commit message ] Signed-off-by: Wei Liu <wei.liu2@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Campbell [Thu, 30 Jul 2015 14:18:20 +0000 (15:18 +0100)]
crontab-cambridge: Add a commented out adhoc bisect line
This is handy to have, editing it in locally just means one cannot
simply use "crontab contab-cambridge" to load a new one without
remembering the content of the line for next time.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Thu, 23 Jul 2015 08:26:31 +0000 (09:26 +0100)]
cambridge: Adjust configuration for move to xs.citrite.net subnet
The Cambridge osstest instance is moving from the .cam.xci-test.com
infrastructure to the xs.citrite.net infrastructure. Adjust the
configuration accordingly.
- The database has been moved from osstestdb.db.cam.xci-test.com to a
new dedicate pgres server at osstestdb.xs.citrite.net. The data has
been transfered. (README.dev is updated to use the production
instance's name instead)
- DHCP leases now come from dns1.uk.xensource.com:5556
- PXE has switched to /usr/groups/netboot. Also switch the templates
to use %name%/pxelinux.cfg with a symlink from
pxelinux.cfg/%ipaddrhex%, which will make it easier to find relevant
files.
- osstser1 is not in the .xs.citrite.net domain
- Logs mount point is now /home/osstest not /home/xc_osstest.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 16:31:52 +0000 (17:31 +0100)]
cs-bisection-step: Fix memoisation of search_compute_length_at
There was a half-implemented memoisation. Memoisation is necessary
because otherwise the algorithm is exponential in the commit history
depth (with base equal to the commit parent fanout).
Sort this out:
* Break out the actual computation into a new
search_compute_length_at_intern
* Deleting the individual memo assignments, which incidentally
means we no longer miss an (unimportant) one.
* Actually having the new memoising function search_compute_length_at
check $n->{LengthAt} (this is the bugfix).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
To reproduce a recent bisection problem I needed to exclude not just
all flights after a certain number, but also one earlier flight. So I
invented this option (and associated yaks).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 17:32:16 +0000 (18:32 +0100)]
Flight restriction: Change implementation of --max-flight
Abolish $maxflight. All the users outside Osstest::Executive have
been eliminated, so this is fine. Replace it with
$restrictflight_cond, which can accumulate multiple conditions.
There is a minor functional change: when multiple --max-flight options
are specified, _all_ of them take effect (effectively using the lowest
value). That option is not used in production, and I don't expect
people elsewhere to be passing multiple different such options.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 16:54:53 +0000 (17:54 +0100)]
Flight restriction: Make report_blessingscond use implicit $maxflight
We have $maxflight in Osstest::Executive now, set appropriately.
Use that in report_blessingscond and all its callers including
report_find_push_age_info and hence in mg-all-branch-statuses and
sg-report-flight and sg-report-job-history.
No functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 17:01:22 +0000 (18:01 +0100)]
Flight restriction: Update cs-bisection-step
Use restrictflight_arg and restrictflight_cond.
This entails replacing $maxflight_cond (which is empty or contains a
series of texts each starting with AND) with $restrictflight_cond
(which is actually an expression, and might be just "TRUE").
No functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 16:38:27 +0000 (17:38 +0100)]
Flight restriction: Introduce restrictflight_arg and restrictflight_cond
Provide the new functions which we will eventually use everywhere.
* Introduce restrictflight_arg which can be used in an argument loop.
* Introduce restrictflight_cond which generates a SQL condition.
* Have restrictflight_cond's value include surrounding ( ) for safety.
* Use the above in sg-report-host-history, renaming $maxflightcond.
No overall functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 23 Jul 2015 17:20:33 +0000 (18:20 +0100)]
Flight restriction: Move $maxflight to Osstest::Executive
We are going to move the interpretation of --max-flight into
Osstest::Executive. Start this by making $maxflight shared between
Executive and the main program. Later, we will make it no longer
exported.
There are a number of places in Executive where a `my' variable
$maxflight shadows the newly moved global. These will be got rid of
later, too.
No functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:31:02 +0000 (13:31 +0100)]
make-distros-flight: Use ftp.debian.org directly
The local proxy seems to serve stale packages for Jessie etc, I blame
the intercepting cache on the way out of our network, similar to b5f15136900d "mg-debian-installer-update: workaround caching proxies",
except it is between the apt-cache and the world not the osstest vm
and the world.
Since the netboot kernel+initrd are reasonably small, these flights
are infrequent and they are intended to test the current upstream
version I think this is tollerable.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:31:01 +0000 (13:31 +0100)]
Add testing of file backed disk formats
xen-create-image makes this tricky to do since it is rather LVM
centric. Now that we have the ability to install from d-i it's
possible to arrange fairly easily that they use something other than
a phy backend over a bare LVM device.
Here we add support to the test script and infra and create a bunch of
new jobs testing the cross product of {xl,libvirt} x {raw,qcow2,vhd}.
A disk format of "raw" means a raw backing file, where as "none" (the
default) means to continue to use the base LVM device.
The test scripts are modified such that when constructing a domain
with a diskfmt runvar specifeies a file backed disk format (i.e. not
"none"):
- the LVM device is slightly enlarged to account for file format
headers (1M should be plenty).
- the LVM device will have an ext3 filesystem created on it instead
of being used as a phy device for the guest. Reusing the LVM volume
in this way means we don't need to do more storage management in
dom0 (i.e. arranging for / to be large enough, or managing a
special "images" LV)
- the relevant type of container is created within the filesystem
using the appropriate tool.
- New properties Disk{fmt,spec} are added to all $gho, containing
the format used for the root disk and the xl diskspec to load it.
- lvm backed guests use a xend/xm compatible spec, everything
else uses the improved xl syntax which libvirt also supports.
We won't test non-LVM on xend.
- New properties Disk{mnt,img} are added to $gho which are not using
LVM. These contain the mount point to use (configurable via
OSSTEST_CONFIG and runvars) and the full path (including mount
point) to the image itself.
- When starting or stopping a guest we arrange for the filesystem to
be (u)mounted.
- The prepearation when starting a guest copes gracefully with
the disk already being prepared.
- Hooks are called from guest_create() and guest_destroy() to
manipulate the disk as needed.
Using standalong-generate-dump-flight-runvars a representative set of
runvars is:
+test-amd64-amd64-xl-qcow2 all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
+test-amd64-amd64-xl-qcow2 arch amd64
+test-amd64-amd64-xl-qcow2 buildjob build-amd64
+test-amd64-amd64-xl-qcow2 debian_arch amd64
+test-amd64-amd64-xl-qcow2 debian_bootloader pygrub
+test-amd64-amd64-xl-qcow2 debian_diskfmt qcow2
+test-amd64-amd64-xl-qcow2 debian_kernkind pvops
+test-amd64-amd64-xl-qcow2 debian_method netboot
+test-amd64-amd64-xl-qcow2 debian_suite wheezy
+test-amd64-amd64-xl-qcow2 kernbuildjob build-amd64-pvops
+test-amd64-amd64-xl-qcow2 kernkind pvops
+test-amd64-amd64-xl-qcow2 toolstack xl
+test-amd64-amd64-xl-qcow2 xenbuildjob build-amd64
Compared to test-amd64-amd64-pygrub (which is the most similar job) and
normalising the test name the difference is:
test-amd64-amd64-SUFFIX all_hostflags arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test
test-amd64-amd64-SUFFIX arch amd64
test-amd64-amd64-SUFFIX buildjob build-amd64
test-amd64-amd64-SUFFIX debian_arch amd64
test-amd64-amd64-SUFFIX debian_bootloader pygrub
+test-amd64-amd64-SUFFIX debian_diskfmt qcow2
+test-amd64-amd64-SUFFIX debian_kernkind pvops
test-amd64-amd64-SUFFIX debian_method netboot
test-amd64-amd64-SUFFIX debian_suite wheezy
test-amd64-amd64-SUFFIX kernbuildjob build-amd64-pvops
test-amd64-amd64-SUFFIX kernkind pvops
test-amd64-amd64-SUFFIX toolstack xl
test-amd64-amd64-SUFFIX xenbuildjob build-amd64
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:30:58 +0000 (13:30 +0100)]
Debian: Handle lack of bootloader support in d-i on ARM.
Debian doesn't currently know what bootloader to install in a Xen
guest on ARM. We install pv-grub-menu above which actually does what
we need, but the installer doesn't treat that as a "bootloader".
Most ARM platforms end up installing a u-boot boot.scr, based on a
platform whitelist. This doesn't seem appropriate for us. Grub is not
available for arm32. For arm64 we will eventually end up with in-guest
UEFI and therefore grub-efi and things will work normally. I'm not
sure what the answer is going to be for arm32.
This patch enables the workaround for Wheezy, Jessie and Sid,
post-Jessie should be enabled as we add them. (Pre-wheezy does not
support running as a Xen guest on ARM so we don't test them at all).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:30:57 +0000 (13:30 +0100)]
distros: Run one suite per day on a weekly basis
Once a week should be sufficient for these tests. Perhaps in the
future we will want to increase the frequency for the suites under
active development (testing, unstable)
For now run this on the Citrix Cambridge instance until the XenProject
instance has sufficient capacity.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:30:55 +0000 (13:30 +0100)]
distros: add branch infrastructure
Since the distro nightlies are not version controlled we cannot use
the usual mechanisms for detecting regressions. Special case things
appropriately. We use an OLD_REVISION of "flight-NNN" to signify that
the old revision is another flight and not a tree revision.
A grep over $NEW_REVISION needed adjusting since NEW_REVISION is empty
in this mode, leading to "grep <filename>" which hangs waiting for
stdin.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 8 Jul 2015 12:30:54 +0000 (13:30 +0100)]
Test pygrub and pvgrub on the regular flights
Since we now have the ability to test these drop one of each of
pygrub, pvgrub-32 and pvgrub-64 into the standard flights. Omitting
the {Guest}_diver runvar causes ts-debian-di-install to use the d-i
images in the location configured via TftpDiVersion, so they are
Version Controlled along with the d-i version used for the host.
Ian Campbell [Wed, 8 Jul 2015 12:30:53 +0000 (13:30 +0100)]
distros: Support pvgrub for Wheezy too.
This requires us to install pv-grub-menu from backports, which we do
using a late_command.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
[ ijc -- dropped unnecessary quoting of comment in heredoc ]
Ian Campbell [Wed, 8 Jul 2015 12:30:51 +0000 (13:30 +0100)]
distros: add support for installing Debian PV guests via d-i, flight and jobs
This patch introduces ts-debian-di-install which can install Debian
from a netboot (PXE) debian installer image. By default it installs
from the d-i image used by osstest (using the special Xen PV guest
enabled flavour where necessary) but it can also fetch the kernel and
ramdisk from URLs specified in runvars. The resulting guests boot the
distro kernel using pygrub (pvgrub will follow).
The distros flights differ substantially from the existing flights.
Introduce make-distros-flight using the functionality previously
refactored into mfi-common. The new flight tests all versions of
Debian from Squeeze onward as an amd64, i386 and armhf guests (armhf
from Jessie onwards only) using the usual smoke tests.
Test names are suffixed -pygrub pending the addition of pvgrub
variants in a future commit.
Add the new cases to sg-run-job
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Thu, 16 Jul 2015 14:53:43 +0000 (15:53 +0100)]
cri-bisect: Provide --html-dir= option introducer
Since 0caf39e6 "Reporting: Make HTML reports for bisection flights too"
we have been running
./sg-report-flight /home/logs/logs/59620/ 59620
which is no good.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Campbell [Mon, 13 Jul 2015 08:13:06 +0000 (09:13 +0100)]
mg-list-all-branches: Sort branches according to any embedded version
Many of our branches include a version number, this change results in
e.g. linux-3.0 < linux-3.4 < linux-3.10 rather than linux-3.0 <
linux-3.10 < linux-3.4, which is more natural for uses such as
./mg-all-branch-statuses.
Ian Campbell [Mon, 13 Jul 2015 08:12:29 +0000 (09:12 +0100)]
INSTALL.production: Start writing some stuff down
I wrote this ages ago while migrating the Cambridge instance to a new
VM and then forgot about it. It's incomplete and I'm not sure where I
was planning to go next, but better than nothing maybe?
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Thu, 16 Jul 2015 10:29:00 +0000 (11:29 +0100)]
ts-windows-install: Bump RAM from 512M to 1536M
Sadly we lack a proper infrastructure for handing guest memory size
and fitting it into the host. We don't currently even have in our
database the amount of RAM the host has.
The recommended minimum for Windows is 2Gby. But we have (in the
Cambridge instance) some hosts which only have 4Gby. We allow 512 for
dom0. We need to leave some spare for Xen and other overheads. So
set this to 1536 (1.5Gby) which should fit even during localhost
migration.
Later we may want to do something more sophisticated, like adjusting
this to 2048 if the host has enough, or only running the test on
bigger hosts, or something.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> CC: Wei Liu <wei.liu2@citrix.com> CC: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: 1536 not 1700.
Mention migration in the commit message.
Ian Campbell [Thu, 9 Jul 2015 14:30:36 +0000 (15:30 +0100)]
mg-all-branch-statuses: Show how up to date each branch is
Using report_find_push_age_info allows us to provide counts of
attempts since the last baseline on current tip as well as the first
attempt of each of those.
Since everything serialises on the repo lock I didn't bother trying to
parallelise anything.
It's a little terse to keep it in 80 chars.
cron infrastructure is added to run this in a new
$HOME/for-maintjobs.git on a daily basis and push the output to the
location given in the Publish config variable, if it is set (it is set
in production but not for cambridge).
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Thu, 9 Jul 2015 08:45:29 +0000 (09:45 +0100)]
Allow rumpkernel xenstorels.test failures for all but rumpuserxen branch
This test has a long standing heisenbug which even doing 150
iterations is not reliable at detecting. It is unlikely to be fixed
until the long-standing rumpkernel build rework is completed.
So lets mark it as an allowable failure for now, except in the
rumpuserxen branch tests themselves.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 3 Jul 2015 18:30:45 +0000 (19:30 +0100)]
Reporting: Make HTML reports for bisection flights too
Provide an appropriate --html-dir option to sg-report-flight.
(Bisection flights still do not run sg-report-host-history and
sg-report-job-history, which are fairly expensive.)
Make references to jobs from sg-report-job-history and
sg-report-host-history go to the /info.html page, not the webserver
directory listing. (sg-report-flight's references already do.)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Wed, 1 Jul 2015 14:49:35 +0000 (15:49 +0100)]
Email reports: Sort out recipients and Reply-to
No longer send reports, or copies, to named individuals. Instead,
send all output to 1. appropriate development mailing lists 2. the new
osstest-admin@xenproject administrator alias, and 3. Bcc the new
osstest-output list.
Bisection progress emails go only to osstest-output. In this case we
provide a Reply-To.
After this patch goes live, people interested in bisection progress
emails will find them in osstest-output. (There are a lot of these.)
Such people can also subscribe to osstest-output and get copies of
only the main test reports and then use recipient-side filtering to
see the ones they find interesting.
(Configurations for `adhoc' and `play' runs remain unchanged and still
have a tendency to refer to my personal address @citrix.)
Deployment notes:
Keir and Stefano will no longer receive automatic CCs of certain
reports, and should subscribe to the osstest-output list, with
appropriate filtering, if they care.
The new osstest-output list has (I think) been configured to accept
the BCCs.
My personal chiark mail-to-news gateway has already been subscribed to
osstest-output.
One substantial change is that the osstest admin now gets copies of
each final bisection failure.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> CC: keir@xen.org CC: stefano.stabellini@eu.citrix.com CC: Lars Kurth <lars.kurth@citrix.com>
Ian Campbell [Thu, 2 Jul 2015 12:44:32 +0000 (13:44 +0100)]
ap-fetch-version: Arrange for osstest merges from upstream to be stable
If a downstream osstest instance has nothing to test it its local
pretest then it will attempt to merge from the upstream instance. If
this fails then it will try again and again generating a new merge
commit each time, even if upstream has not moved.
It is desirable that these merges instead be stable i.e. the same if
the inputs have not changed. This is good for potential bisection
attempts, history reporting/mining as well as just being sensible.
Here we arrange for this by recording the last merge "epoch" (being
the first merge of the current input branches) in a new branch
"merge-epoch" in the local testing.git and comparing our fresh merge
against it.
If the tree and parents are the same then the merge is effectively
identical (it may/will differ in the date) and we reuse the epoch
merge.
If they new merge does not match then something has changed (i.e.
upstream has moved on) and so we take the new merge and establish a
new epoch.
Add a couple of ">&2" to some fetches to prevent anything other than
the desired SHA1 leaking onto stdout.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 3 Jul 2015 11:22:52 +0000 (12:22 +0100)]
ts-logs-capture: Explicitly set xenctx capture filename
Now that the command contains PATH, the autogenerated filename is very
ugly.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch in this version of the series.
Ian Jackson [Thu, 2 Jul 2015 17:05:25 +0000 (18:05 +0100)]
ts-logs-capture: Run xenctx earlier
Break fetch_xenctx_guest out into its own function, and run it before
serial_fetch_logs.
This is relevant because serial_fetch_logs sends the Xen debug keys,
which might dislodge a stuck guest - and, if it does, we would like to
have captured the stuck state with xenctx, rather than the unstuck
one.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 3 Jul 2015 10:06:40 +0000 (11:06 +0100)]
sg-report-flight: Fix --include (broken by 3d56a191)
In 3d56a191 "sg-report-flight: Make bodyprint[f] defer the output" it
became wrong for anything in the main printout part of
sg-report-flight to write directly to STDOUT. However, the two (very
similar) bits of code for handling the two kinds of --include still
used cat.
The result is emails looking like this:
From: osstest service owner <osstest-admin@xenproject.org>
To: <xen-devel@lists.xensource.com>, <rumpkernel-builds@freelists.org> CC: <ian.jackson@eu.citrix.com>
Subject: [rumpuserxen test] People who touched revisions under test:
Alice Bob <alice@example.com>
Ian Jackson <Ian.Jackson@eu.citrix.com>
Carol David <carol@example.com>
Date: Fri, 3 Jul 2015 06:50:53 +0000
flight 59037 rumpuserxen real [real]
Fix this by replacing those two near-identical bits of code with calls
to a single function which slurps the required include file into the
body text accumulation variable.
(There is no need to provide a facility for header includes, since
there is no need for a caller to pass headers through
sg-report-flight: they can simply be written into the output file
before running sg-report-flight, as indeed the string `Subject: ' is.
Despite the fact that --include-begin is used only by cr-daily-branch
which passes it a file `heading', the text is intended for the start
of the body, not the email headers.)
(b) The output after this patch differs from the output produced by 1f0c168d (the previous osstest production commit) only in addition of
the `Last test of basis' and `Testing same since' information, in the
appropriate place.
Deployment note: Because this patch changes only sg-report-flight, it
is safe to deploy under the feet of a running flight. I intend to do
this for all the production branches in the colo.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Dario Faggioli [Tue, 30 Jun 2015 17:36:59 +0000 (19:36 +0200)]
make-flight etc.: stop testing SEDF at all
SEDF has been broken and unmaintained at least until Xen 4.2, and most
likely even before! Tests are failing without anyonce caring, and yet
we're keeping using test resources for them.
Let's stop doing this!
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Tue, 30 Jun 2015 13:31:28 +0000 (14:31 +0100)]
Emails: Provide X-Osstest-Failures
Specifically:
* $cat now contains SORTLETTER BLOCKSTATUS DESCRIPTION...
* Rewrap the lines setting $cat
* Add $notsucceeds{$cat}[][2] containing one line for the new header
* Generate the new header
* Document the new header
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Tue, 30 Jun 2015 13:29:21 +0000 (14:29 +0100)]
Emails: Provide X-Osstest-Versions-This and That headers
Specifically:
* Provide headerprint() in sg-report-flight
* Use it to add X-Osstest-Versions headers based on %specver
* Cause cr-daily-branch to always enable the feature
* Document this in README.email
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Document This and That