Dario Faggioli [Fri, 2 Oct 2015 23:58:28 +0000 (01:58 +0200)]
ts-logs-capture: include some cpupools info in the captured logs.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
--- Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Juergen Gross <jgross@suse.com>
---
Changes from v2:
* new patch, the introduction of which was suggested
during review.
Dario Faggioli [Fri, 2 Oct 2015 10:12:45 +0000 (12:12 +0200)]
Testing cpupools: recipe for it and job definition
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
--- Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Juergen Gross <jgross@suse.com>
---
Changes from v2:
* restrict test generation to xl only.
Changes from v1:
* added invocation to ts-guest-stop in the recipe to kill
leak-check complaints (which went unnoticed during v1
testing, sorry)
* moved the test before the "ARM cutoff", and remove the
per-arch filtering, so that the test can run on ARM
hardware too
Dario Faggioli [Fri, 2 Oct 2015 10:12:36 +0000 (12:12 +0200)]
ts-cpupools: new test script
for smoke testing cpupools a bit. It tries to partition
a live host in two cpupools, trying out the following 3
schedulers for the new cpupool (one after the other):
credit, credit2 and RTDS.
It also tries to migrating a domain to the new cpupool
and then back to Pool-0.
Signed-off-by: Dario Faggioli <dario.faggioli@citrix.com>
--- Cc: Ian Jackson <ian.jackson@eu.citrix.com> Cc: Ian Campbell <ian.campbell@citrix.com> Cc: Juergen Gross <jgross@suse.com>
---
Changes from v2:
* reorganized internal subroutines;
* avoid failing (just don't run the test) if we find
only 1 pCPU on the host;
* use 'map' and 'grep' in place of foreach loops, as
suggested during review;
* fix the check for the default cpupool configuration
to be in place when starting the test, as identified
during review;
* fix quoting for the name of the cpupool, as idenfied
during review;
* use target_cmd_root(), instead of target_cmd_output_root(),
as requested during review;
* check for the toolstack to be xl and only xl, as
requested during review.
Ian Jackson [Mon, 28 Sep 2015 15:29:33 +0000 (16:29 +0100)]
TestSupport: Honour $stdin fh argument to cmd, tcmd and tcmdex
These are internal functions, so the change is entirely within
TestSupport. All the call sites are adjusted to pass undef so there
is no functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
(See the comment in the new file for the explanation.)
This change affects all our Debian installs (both hosts and guests)
which are done with preseeding, because preseed_base() arranges to
install overlay/.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 24 Sep 2015 17:03:00 +0000 (18:03 +0100)]
Shell fixup: Use bash in posix mode
When bash is started as /bin/sh it run in posix compatibility mode.
But when invoked as /bin/bash it does some things ... differently.
Most notably:
Subshells spawned to execute command substitutions inherit the
value of the -e option from the parent shell. When not in posix
mode, bash clears the -e option in such subshells.
It is a mystery why anyone thought the `non-posix' behaviour was
desirable. One effect in practice is that osstest's cr-daily-branch
can blunder on if one of its version fetches fails.
AFAICT the only documented way to get rid of this anomalous behaviour
is to switch bash to posix mode. I have read through the wheezy
bash(1) manpage and searched for posix, and the following behavioural
differences are described:
* Differences in interative startup (not relevant to us).
* Minor (irrelevant) differences in which startup files are read
during noninteractive startup. (Eg, BASH_ENV not honoured.)
* Differences to the parsing of invocations of `time'
* `test a == b' may be unsupported (but it's wrong and we say `=')
* -e not inherited by some subshells (this is what I am trying to fix)
* `.' and `source' do not search the cwd.
* `set' with no arguments does not print shell functions etc.
So I think, with the previous patch, that these changes are all
desirable or at least harmless.
I have not added `set -o posix' to shell script fragments invoked by
various scripts (eg Perl and Tcl scripts). Those scripts might be
processed by bash if /bin/sh is bash, but when is invoked as sh it
runs in posix mode anyway.
I have done some ad-hoc testing but it seems like much of this is
difficult to test. I suggest we push it at a time when we can keep a
close eye on the behaviour.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Jackson [Thu, 24 Sep 2015 15:46:44 +0000 (16:46 +0100)]
Shell fixup: Make all invocations of `.' (`source') use ./
In POSIX, `.' (the shell builtin) respects PATH, and does not search
`.' (the current directory).
Change all the invocations which refer to files which are part of
osstest to say `. ./foo' instead of simply `. foo'.
I have checked the results of
git-grep '^[ \t]*\. [^./]'
after this patch and the remaining five hits are of no concern.
As a double-check of my hand-editing, I have also done this
perl -i~ -pe 's#^(\s*\. )\./#$1#' *
and verified that the resulting tree is almost identical to that
before this commit. There is one difference, where the original
code already said `. ./job'.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Ian Campbell [Fri, 25 Sep 2015 10:21:08 +0000 (11:21 +0100)]
Do not run baseline tests on osstest branch.
If an osstest instance is running flights with
OSSTEST_BASELINES_ONLY=y (e.g. on a secondary site, like the Citrix
Cambridge instance) then it will also be running a regular osstest
flight to merge from the upstream osstest and does not want to also do
baseline testing.
I expect this will be the normal configuration in all sites other than
the master colo production instance, so arrange for it via
branch-settings.osstest rather than some site local configuration file.
In the colo production instance we never set OSSTEST_BASELINES_ONLY=y,
so this has no effect. If we did set that option I think suppressing it
for the osstest branch would still be correct.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Wed, 23 Sep 2015 15:48:36 +0000 (16:48 +0100)]
Debian: Wait for udev devices to settle in erase-other-disks
Otherwise we, apparently, have a race between the "test -b" + dd
against the sda1 device node being removed and end up creating a file
called /dev/sda1 containing 32K of zeroes, which will later render
mke2fs very confused.
For some reason we seem to reliably loose the race on Jessie i386 host
installs, but not on Wheezy or other arches on Jessie.
This was tricky to diagnose because the Debian installer main-menu
process appears to buffer the output of things it runs before logging
them to /var/log/syslog, which means the output of "set -x" and the
actual affect of the commands (e.g. in the kernel messages) can be
presented in very confusing orders. Hence this patch also adds
extensive use of logger(1) to record what it is actually doing at the
time it does it. These logs include the pid of the command too since
main-menu only logs its own pid, not that of the subcommand which
gneerated the output.
Lastly this patch adds an explicit test that each device it touches is
actually still a block device afterwards.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Mon, 21 Sep 2015 15:14:33 +0000 (16:14 +0100)]
Debian: handle move of ip(8) to /sbin in Jessie
Unfortunately udev treats non-absolute commands as relative to
/lib/udev rather than consulting $PATH, so we have to figure out the
path based on the suite.
Without this the force-mac-address workaround (needed on Arndale)
doesn't work.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 25 Sep 2015 11:09:09 +0000 (12:09 +0100)]
Host install: Break out target_core_dump_setup
We are going to want to do this for nested HVM L1s too.
No functional change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
v14: Split this nfc patch out from other changes
Drop changes to whitespace usage
Rename new function from `core_dump_setup'
Drop introduction of an unnecessary mkdir -p
Robert Ho [Mon, 17 Aug 2015 05:48:04 +0000 (13:48 +0800)]
Debian HVM guests: Honour guest disk and ram size runvars
Allow runvars to specify guest disk and ram size, turning previous
values into defaults:
The default disk size for the guest is `10000M' which is not going to
be sufficient for nested HVM tests. We are going to want to use a
larger disk size for the nested L1. The appropriate disk_size will be
defined in make-flight, in forthcoming changes.
Also, also allow ram size to be defined by runvar. The runvar takes
precedence over the default (which is calculated based on host RAM
etc.)
No functional change with current sets of runvars.
Signed-off-by: Robert Ho <robert.hu@intel.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Robert Ho [Mon, 17 Aug 2015 05:52:35 +0000 (13:52 +0800)]
Debian HVM guests: Comment out CDROM entry in HVM guest VM
Comment out the CDROM entry in the installed system's sources.list.
The installation ISO is not generally present in the virtual CDROM
while the guest is running, so this entry is nonfunctional.
Removing it causes the L1 HVM guest VM to use the http entry instead.
The result is that now `apt-get' works in the guest.
Signed-off-by: Robert Ho <robert.hu@intel.com> Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Robert Ho [Mon, 17 Aug 2015 03:34:04 +0000 (11:34 +0800)]
Debian grub2: Optimize and re-format submenu parsing
* space between ')' and '{'; and after '='
* omit unnecessary 'define' and '!defined' usage
* break long '{}' into several lines
Signed-off-by: Robert Ho <robert.hu@intel.com> Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
---
v14: Drop removal of MenuEntryPath setting in grub2 submenu parse
Ian Jackson [Mon, 21 Sep 2015 16:49:48 +0000 (17:49 +0100)]
Executive: Delay releasing build host shares by 90s
When a build job finishes, the same flight may well want to do a
subsequent build that depended on the first. When this happens, we
have a race:
One the one hand, we have the flight: after sg-run-job exits,
sg-execute-flight needs to double-check the job status, and search the
flight for more jobs to run; it will spawn ts-allocate-hosts-Executive
for the new job, which needs to get its head together, parse its
arguments, become a client of the queue daemon, and ask to be put in
the queue.
On the other hand, we have the planning system: currently, as soon as
sg-run-job exits, the connection to the ownerdaemon closes. The
ownerdaemon tells the queue daemon, and the planning queue is
restarted. It might even happen that coincidentally the planning
queue is about to start.
If the planning system wins the race, another job will pick up the
newly-freed resource. Often this will mean unsharing the build host,
which is very wasteful if the releasing flight hasn't finished its
builds for that architecture: it means that the next build job needs
to regroove a host for builds.
Add a bodge to try to make the race go the other way: after a build
job completes successfuly, do not give up the share for a further 90
seconds. (We have to use setsid because sg-execute-flight kills the
process group to clean up stray processes, which this sleep definitely
is.)
A better solution would be to move the wait-for-referenced-job logic
from sg-execute-flight to ts-hosts-allocate-*. But that would be much
more complicated.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: New patch
The Debian i386 image boots a 32-bit non-PAE kernel which therefore
cannot have any PV drivers on our 64-bit hypervisors. This makes it a
bit slow: in my test on a machine under my desk it took 1400s out of
the allowed 2000s.
With this change the timeout is 3000s instead.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
We look up a guest runvar GUEST_CONTEXT_timeoutfactor (according to
the usual rules for guest runvars).
Here CONTEXT can currently be `general' or `install'. (`install'
applies when the guest is being installed.) If the runvar exists, all
timeouts relating to that guest in that context are increased by the
specified factor.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 18 Sep 2015 16:23:39 +0000 (17:23 +0100)]
Timeouts: Introduce target_adjust_timeout
This function is now called for almost every timeout.
Specifically, it is called in the cases in TestSupport where a guest-
or host-related timeout is passed from code which has a $ho or $gho,
to code which does not: all callers of poll_loop, and tcmd.
Currently the function is a no-op. Its existence and use will allow
us to introduce various provocations for adjusting timeouts, of which
I have one planned.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 18 Sep 2015 15:24:24 +0000 (16:24 +0100)]
ts-debian-hvm-install: Use /dev/sda for i386, not /dev/xvda
The device shows up as /dev/sda in the installer. This is because the
i386 installer image (in wheezy and jessie, at least) is not PAE, and
therefore does not load PVHVM drivers and therefore does not switch
from the emulated device (which shows up as /dev/sda) to blockfront
(/dev/xvda).
There are ways it might be possible to provide an i386 install image
with PVHVM drivers (for example, the Xen-enabled i386 kernel on the
multi-arch ISO). However it is useful to have a test job which tests
both emulated devices and PVHVM ones, within a single job, and even on
my ancient under-desk test box (bedbug) the whole test takes only 28
minutes, which seems fine even as part of the fast smoke test.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 18 Sep 2015 15:21:45 +0000 (16:21 +0100)]
ts-debian-hvm-install: Do not create EFI partition if EFI not in use
If we are booting our install ISO using a non-EFI executable, don't
try to provide an EFI for the installed system either.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: Fix regexp to match efi.img (!)
Rebased, fixed code motion conflict.
Ian Jackson [Fri, 18 Sep 2015 14:35:47 +0000 (15:35 +0100)]
ts-debian-hvm-install: Set $gsuite after $gho
$gsuite was set from guest_var, but before $gho was set, leading to an
undefined value warning from Perl.
This would ignore any guest-specific suite runvars. AFAICT these are
set by some of the jobs in make-distros-flight. I think the effect of
this change is to apply workarounds for the intended suite, rather
than for wheezy.
(Although there is another assignment to $gho later in
ts-debian-hvm-install, for stage 2, the stage 2 code does some trivial
TestSupport calls and does not need $gsuite. So there is no need to
make arrangements to assign to $gsuite - or, for that matter, $kernel
or $ramdisk, in that path.)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 18 Sep 2015 14:30:57 +0000 (15:30 +0100)]
ts-debian-hvm-install: Cope with images containing only isolinux
debian-7.2.0-i386-CD-1.iso contains no grub, only isolinux.
If the specified EFI grub file does not exist, fall back to isolinux.
This requires a -c option as well, according to
https://wiki.debian.org/DebianInstaller/Modify/CD
Only try to set up a grub config if we are booting grub. (The i386
image in question does not contain a [debian]/boot/grub directory.)
If boot/grub/efi.img _does_ exist (ie, for other existing tests), the
only difference in behaviour is to reorder slightly the options to
genisoimage: `-b boot/grub/efi.img' now occurs after `-no-emul-boot
-r' rather than before.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: Log $bootfile value.
Preseed generation now happens later due to previous patch;
so $bootfile setting now also deferred. Context change only.
Ian Jackson [Mon, 21 Sep 2015 14:13:23 +0000 (15:13 +0100)]
ts-debian-hvm-install: Defer preseed generation
Defer preseed file generation until after we have fetched and looked
inside the install image, because we are going to want to make changes
to the preseed file based on the image contents.
No overall functional change, although some things happen in a
different order now, and the ISO manipulation takes place in two calls
to target_cmd_root rather than one.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: New patch. Needed because otherwise the test for the grub install
image (to be introduced in the next patch) happens before the ISO
is unpacked, and we would then always fall back to isolinux.
Ian Jackson [Fri, 18 Sep 2015 13:57:47 +0000 (14:57 +0100)]
ts-debian-hvm-install, etc.: Do not hardcode in-iso path
ts-debian-hvm-install hardcoded `install.amd' as the directory in the
.iso in which to find the kernel and initrd. This is wrong for
architectures other than amd64.
Instead, pass this information in runvars (as is done for the netinst
installs in make-distros-flight), and honour it in
ts-debian-hvm-install.
If the runvars are not set, default to the previous hardcoded values.
(This arranges that clones of old flights still work with new osstest,
eg for bisection.)
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Wed, 8 Jul 2015 15:21:05 +0000 (16:21 +0100)]
ap-*: Be able to fetch and push xen.git#smoke
The branches and push gates are now:
xen.git#staging -[xen-unstable-smoke]-> #smoke -[xen-unstable]-> #master
Deployment note: When this passes the osstest self-push-gate, the main
xen-unstable flight will start using smoke as an input. Therefore,
until the new cronjob is installed to run the xen-unstable-smoke
tests, an automatic process should keep xen.git#smoke up to date with
xen.git#staging. Eg, running in screen in xen@xenbits:~/git/xen.git:
while sleep 1800; do git fetch . staging:smoke; done
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: `xen.git#smoked' branch name changed to `#smoke'
Ian Jackson [Thu, 17 Sep 2015 15:17:25 +0000 (16:17 +0100)]
cr-daily-branch: Use mg-adjust-flight-makexrefs to have smoke tests reuse builds
The smoke tests are for testing xen-unstable. We want to avoid
building anything else. So arrange to reuse previous builds by
calling mg-adjust-flight-makexrefs.
We rebuild libvirt too. This is necessary because libvirt is built
against xen.git, and uses ABI-unstable APIs, so we need a libvirt
built against the right xen.git. This means, for the smoke tests, we
need to build libvirt ourselves. Currently this build seems to take
416 sends (from host allocation, which we - perhaps naively - hope
will be able to reuse the host from the just-finished build job).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: Keep build-amd64-libvirt too.
v3: Add a comment about the --blessings=real
v2: New patch
Ian Jackson [Fri, 3 Jul 2015 18:56:45 +0000 (19:56 +0100)]
Provide xen-unstable-smoke branch
Introduce support for branch=qemu-xen-unstable-smoke which has
xenbranch=xen-unstable-smoke.
In make-flight, this contains a very limited set of jobs
test-amd64-amd64-libvirt
test-amd64-amd64-xl-qemuu-debianhvm-i386
test-armhf-armhf-xl
and the builds they depend on.
The debianhvm job exists only in this flight, and is generated by
having branch_debianhvm_arch return i386 instead of amd64. This is so
that this branch contains a 32-bit x86 guest as well as a 64-bit one.
We override host allocator parameters to make this flight not care
about host stickiness: it just takes whatever comes to hand. These
runvars are marked `synth' so that cs-bisection-step and
cs-adjust-flight do not copy them, as discussed in previous patches.
Later we will arrange to reuse previous builds for the build artefacts
which aren't intended subjects of the smoke test.
(Deployment note: This needs images/debian-7.2.0-i386-CD-1.iso which I
have already placed in the Cambridge and Xen Project instances.)
In ap-common we need to arrange to use the same qemu trees as for
xen-unstable, rather than looking for special smoke ones.
In select_xenbranch xen-unstable-smoke is mostly like xen-unstable.
There are only two places in osstest where xenbranch `xen-unstable' is
treated specially and only one of them needs adjusting to match
xen-unstable-smoke too.
The new branch `xen-unstable-smoke' has a `prev' branch of
`xen-unstable' according to cri-getprevxenbranch, which is technically
wrong, but this is not important because xen-unstable-smoke has no
prev tests.
We are going to sort out the push gate ref plumbing in xen.git in the
next osstest patch.
Also, use a branch-settings file to set the new branch's resource
priority to -20 to make it run ahead of anything else automatic.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: Introduce xenbranch_forqemu into ap-common.
Combine patches for make-flight and cr-*. make-flight includes
cri-common and ap-common (which is arguably a layering violation,
but there we are).
Dropped ack from Ian Campbell.
Set `qemuubranch' correctly in select_xenbranch.
v2: Generate all the jobs that this flight's tests use, and add
note about this to the commit message.
Mention `synth'-ness of hostalloc runvars in commit message.
Image is in Xen Project test colo too.
Ian Jackson [Fri, 3 Jul 2015 18:55:32 +0000 (19:55 +0100)]
make-flight: Run job_create_test_filter_callback on true job name
job_create_test would pass $job to job_create_test_filter_callback but
then later maybe append -xsm to it. Fix this.
No functional change for existing in-tree code because all existing
tests of the $job end in *.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Fix textual conflict after dropping "make-flight: Allow separate
specification of pre-built Xen vs others"
Ian Jackson [Thu, 17 Sep 2015 12:43:17 +0000 (13:43 +0100)]
cs-adjust-flight: Provide `jobs-del' operation
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v3: Document the new operation
v2: New patch
Ian Jackson [Wed, 16 Sep 2015 15:48:05 +0000 (16:48 +0100)]
sg-check-tested: New --pass-job= option
Specifies that returned information should relate to a flight in which
a particular job existed and passed. The option can be repeated if
desired (to specify flights in which _all_ those jobs passed).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: New patch
Ian Jackson [Mon, 21 Sep 2015 13:35:15 +0000 (13:35 +0000)]
sg-report-flight: Better searching for used revisions
The old algorithm used for determining which flight might be a
suitable test of a particular revision was rather crude, in two ways:
* It would look at _all_ jobs in a flight referred to from the flight
of interest, not just at the relevant jobs;
* It would only look at the direct referents of the flight in
question. So for example, if a flight of interest contained
test-amd64-i386-libvirt, it would find a referenced
build-i386-libvirt in another flight, but that build refers to
build-i386, and it would not look at that (unless it happened to be
in the same flight).
Fix this by redoing the revision archaeology, with some $why tracking
to explain how we found a particular revision.
cs-bisection-step and sg-check-tested arguably ought to do do it this
way too. But I am leaving centralising this new logic, and using it
in those other programs, for another day.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v4: New patch
Ian Jackson [Thu, 2 Jul 2015 17:27:28 +0000 (18:27 +0100)]
ts-host-alloc-Executive: Honour various hostalloc_* runvars
We honour
hostalloc_maxbonus_variation
hostalloc_bonus_previousfail
hostalloc_bonus_sharereuse
and make them default to their previous values.
These should be set as `synth' runvars during flight construction, so
that they are not copied into flights generated by cs-bisection-step
or cs-adjust-flight. cs-bisection-step makes its own arrangements for
host specification. So should the caller of cs-adjust-flight (perhaps
via the blessing system).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Incorporate note about `synth'-ness in commit message.
Ian Jackson [Wed, 16 Sep 2015 12:14:47 +0000 (13:14 +0100)]
standalone-generate-dump-flight-runvars: Show synth runvars
Pass -a to mg-show-flight-runvars. That way when we use the new
cs-job-create feature to set synth runvars during creation, we will
see them in the dump.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Wed, 16 Sep 2015 12:09:01 +0000 (13:09 +0100)]
mg-show-flight-runvars: Decorate synth runvar names with ~
Make mg-show-flight-runvars -a append ~ to the names of synth runvars.
(This is consistent with the new syntax in cs-job-create.)
We do this by editing $row[1] (and $colws[1]) so we can avoid
disturbing the general column format calculation and printing.
We switch to fetchrow_array rather than fetchrow_arrayref. This is
clearer and also avoids having to copy $row (because the value in the
DB $row from fetchrow_hashref would be readonly).
We have to check for $synth eq 'f' as well as $synth being boolean
false, because SQLite's typeless nature (or, to put it another way,
DBD::SQLite's failure to look at the schema) means that a boolean
field's value of 'f' or 't' is simply returned as a string to Perl.
But of course "f" is trueish in Perl.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Use fetchrow_array instead.
Do not mistakenly drop the $synthcond assignment (!)
Ian Jackson [Thu, 2 Jul 2015 17:33:19 +0000 (18:33 +0100)]
cs-job-create: Permit creation of `synth' runvars
This will be useful for some hostalloc_* runvars which we are going to
introduce shortly.
This is going to be the way to set a runvar which is not copied by
cs-bisection-step or cs-adjust-flight. Using `synth' for this is
arguably slightly wrong but it does the right thing in all existing
cases. The alternative would be a schema change.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Defer some of the discussion to later commit messages.
Ian Campbell [Wed, 16 Sep 2015 11:47:43 +0000 (12:47 +0100)]
Add support for selecting resources based on their properties.
In particular for allocating hosts based on host properties.
To do this we extend the hostflags syntax with "condition:arg1:arg2".
This specifies that the candidate host must pass the condition given
the arguments.
Each "condition" is a new module in the Osstest::ResourceCondition
namespace. For each condition an object is constructed using the given
arguments (split on ':') and stored in $hid.
When allocating for each candidate host the object's ->check method is
called giving $restype and $resname and will return true or false
depending on whether the given host meets the condition.
Only a single condition is implemented here "PropMinVer" which
requires that a given property on the resource has at least the given
value when compared as a version string. Enforce that the database and
the resource property both use the canonical CamelCase naming through
the use of the newly added here propname_check function. Lack of the
property being compared is taken a "no restriction" and hence is
allowed.
Osstest::cfgvar_re is exported for use in the new propname_check
function.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Jackson [Fri, 3 Jul 2015 16:54:28 +0000 (17:54 +0100)]
cr-ensure-disk-space: Take the flights db lock
This eliminates the race with cs-bisection-step (and other
flight-construction tools which might reuse previous flights, provided
that they also do not pass previous flight numbers from hand to hand
with the db unlocked).
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 3 Jul 2015 16:39:41 +0000 (17:39 +0100)]
cr-ensure-disk-space: Look at referring flights
Previously the flight to delete was simply the one with the lowest
flight number. Now we sort flights not by their own flight number,
but by the highest flight number of any referencing flight.
This means that flights whose builds are being reused are kept as long
as the reusing flights.
This almost-entirely fixes a largely-theoretical race in the way
cs-bisection-step works (where the flight's logs and build outputs
might be deleted between the setup and execution of the referring
flight).
A smaller race still exists because the stash check in
cs-bisection-step occurs before the being-created flight is visible to
other db clients. We will have to fix this by taking the flights
lock.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Thu, 27 Aug 2015 15:37:17 +0000 (16:37 +0100)]
ap-push: Use refs/heads/ for destinations
When the destination is a branch, specify refs/heads/ explicitly.
This makes ap-push work even if the ref does not yet exist on the
destination.
There is no functional change for an existing installation pushing to
an existing branch. But for a hypothetical new installation, this
would be necessary.
And, more relevantly, when new "branches" are invented, the use of an
existing ap-push case as a template will generate a new case which
creates the branch as is necessary.
I leave the more complex osstest case alone. It's not clear to me
whether the destination ref not existing is an installation problem of
such severity that indeed ap-push should fail.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Also you can say AP_FETCH_MEMO_KEEP=1 to make it reuse old
information, which is useful for making comparisons.
For a further speed improvement, one can use `eatmydata'. This is not
the default because it risks corruption of `standalone.db' which is
used for other purposes too. Add a comment about possibly improving
this.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Fri, 28 Aug 2015 18:09:27 +0000 (19:09 +0100)]
memoise: New utility
Give this a GPLv2+ licence so that we can move it into some other
FLOSS package later.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
---
v2: Do not use FSF street address in copyright notice.
Ship a copy of GPL-3.
Ian Jackson [Tue, 15 Sep 2015 17:24:17 +0000 (18:24 +0100)]
standalone: Set very long SQLite3 busy timeout in Perl
Without this, big standalone-generate-dump-flight-runvars jobs may
trying to serialise so much work that SQLite3 times out. And we are
about to introduce an optimisation which makes this much more likely.
In standalone mode we probably don't care much about this timeout at
all. (It might even be that the user is using sqlite(3) and has
effectively locked the database interactively for an extended period.)
We would prefer to rely on the user to stop anything that seems to
have become stuck. So set the timeout to 10ks.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Wed, 16 Sep 2015 12:34:28 +0000 (13:34 +0100)]
standalone: Do not blunder on after errors
./standalone's with_logging function would _log_ errors, but it
wouldn't exit immediately. As a result, the script would blunder on.
Normally it wouldn't do very much more since most of the with_logging
calls are the last thing it does - but the exit status would be wrong
(0, from echo).
As a result, for example, standalone-generate-dump-flight-runvars
would never properly report make-flight failures.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Jackson [Mon, 14 Sep 2015 10:55:08 +0000 (11:55 +0100)]
Executive: Abolish use of the `configdb'
This was a database used by networking infrastructure on the
now-obsolete XenClient network in the Citrix Cambridge office (which
used some management tools developed by Mythic Beasts).
The production database in Cambridge no longer has the configdb, and
both instances have `HostDB_Executive_NoConfigDB 1' in the
configuration. We think it very unlikely that anyone has as similar
arrangement.
Remove all the code for accessing this database. We leave the config
settings `NoConfigDB' for now, for the benefit of ad-hoc trees which
are not immediately updated but which use their site's official
production-config. They can be deleted later.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
But cs-bisection step foolishly assumed that the --graph-out argument
did not contain any shell metacharacters. Fix this.
Specifically:
* Change invocations of perl's open to use the 3-argument form
* Change invocations of system to pass individual arguments rather
than constructing a shell script fragment and relying on the shell
to split it up.
* In particular, in the png processing pipeline, use the "sh -ec
<script> x <arg>..." technique to pass the input and output
filenames in a way that does not expose them to the shell's parser.
To avoid making this code more tangled than it already is, also
break out the construction of what is now $scriptlet.
* Escape metacharacters in the URIs we put in the html output.
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
Ian Campbell [Mon, 14 Sep 2015 10:20:06 +0000 (11:20 +0100)]
crontab-cambridge: Change the days when we run a given distro-debian suite
The weekly CD images which are used by the snapshot flight are
generated Sunday-Monday, so running that on a Saturday as we have been
doing ensures that it will take at least two iterations/weeks to get
any issues fixed.
Also the current ordering of the existing releases made it hard to
decide where to insert a new release (e.g. Stretch).
So reorder as:
- Run the Sid daily run on a Monday
- Run the Snapshot run on a Tuesday (to pick up the weekly builds
from Monday)
- Run Squeeze on Wednesday and continue with newer releases
chronologically from there.
New releases can then be added at the end (wrapping the days).
Also add some blank lines to aid clarity.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Fri, 11 Sep 2015 10:07:03 +0000 (11:07 +0100)]
ts-xen-build: Do not set QEMU_REMOTE unless $r{tree_qemu} is set
4.4 and earlier do not check if QEMU_REMOTE is empty before using it.
From 4.5 onwards if QEMU_REMOTE is empty then default is used.
This should fix the build-*-prev job for 4.5 and earlier. In this job
we deliberately don't specify tree_qemu since we want whatever
that branch gives us.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Mon, 7 Sep 2015 12:58:29 +0000 (13:58 +0100)]
ts-xen-install: Rewrite /etc/hosts to comment out 127.0.1.1 entry
Debian creates an entry such as:
127.0.1.1 lace-bug.xs.citrite.net lace-bug
This causes local lookups of the FQDN to get 127.0.1.1, which is
unhelpful if you are looking for an address to bind to and were hoping
to get the public IP address, as libvirt does on the target host for
migration.
Here we remove (actually, comment) any 127.0.1.1 line in /etc/hosts.
This means that lookups of a hosts own name (fqdn or just dn) now rely
on DNS, which may not be ideal. However for a host which uses DHCP I'm
not aware of a way to keep /etc/hosts up to date with the actual IP
address the machine has. In our infra the test host IP addresses are
all static, but I don't think we want to rely on at any more that we
already do.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Thu, 13 Aug 2015 15:18:37 +0000 (16:18 +0100)]
cambridge: arrange to test each new baseline
Provide a new cr-daily-branch setting OSSTEST_BASELINES_ONLY which
causes it to only attempt to test the current baseline (if it is
untested) and never the tip version. Such tests will not result in any
push.
Each new baseline is tested exactly once (i.e. we aren't repeating
hoping for a pass), hence the correct revision is just the one tested
by the last run on the branch.
Add a cronjob to Cambridge which runs in this manner, ensuring that
there will usually be some sort of reasonably up to date baseline for
any given branch which can be used for comparisons in adhoc testing or
bisections.
This will also give us some data on the success of various branches on
the set of machines in Cambridge, which can be useful/interesting.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Ian Campbell [Fri, 31 Jul 2015 10:58:48 +0000 (11:58 +0100)]
Osstest/TestSupport: Hide $ho->{Toolstack} from casual use
This should only be accessed via toolstack($ho), which is responsible
for caching the value. Rename the field to _Toolstack to deter code
from using it.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Anthony PERARD [Thu, 6 Aug 2015 17:03:28 +0000 (18:03 +0100)]
ts-xen-install: Add dom0_mem runvar to control dom0 memory
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
projects / people / dariof / osstest.git / log