Since buildpackages runs before target provisioning, it is possible that
the desired image does not yet exist on a newly provisionned tenant (or
region).
http://tracker.ceph.com/issues/13910Fixes: #13910
Signed-off-by: Loic Dachary <loic@dachary.org>
Similar to what the teuthology install.py task does, add --force-yes to
the apt-get install so that unsigned packages are successfully
installed. It is needed when the buildpackages task is used to create
packages on the fly.
There is no need to do the same for rpm packages because the
verification is controlled from the ceph-release package instead of from
the command line.
http://tracker.ceph.com/issues/13899Fixes: #13899
Signed-off-by: Loic Dachary <loic@dachary.org>
So that it can be used as follows:
teuthology-openstack ... --suite mysuite ... debug/openstack-15G.yaml
Signed-off-by: Loic Dachary <loic@dachary.org>
When the quotas are low, it matters to block until the build machine is
actually deleted. Otherwise target provisionning may fail because the
they exceed the quota. For instance the default on OVH is to have 32
cores and the build machine uses 16. The packages-repository machine
uses two, the teuthology cluster uses one and that leaves only 13 cores
for the targets which may be too low when running jobs that require
large instances.
Signed-off-by: Loic Dachary <loic@dachary.org>
So that it can be used as follows:
teuthology-openstack ... --suite mysuite ... debug/openstack-30G.yaml
Signed-off-by: Loic Dachary <loic@dachary.org>
Use named error codes instead of numbers, and
use the helper fn for getting inode number
instead of doing it by hand.
Signed-off-by: John Spray <john.spray@redhat.com>
The thrasher and qemu need disk attached to run against xfs or btrfs,
otherwise it will use the local file system which is always ext4. It
will succeed but this is a kind of false positive since no xfs or btrfs
related tests were run.
http://tracker.ceph.com/issues/13270 Refs: #13270
Signed-off-by: Loic Dachary <loic@dachary.org>
The ceph pg scrub ... command isn't really guarranteed to
start a scrub, keep reissuing it until the scrub actually
happens.
Related: #12746
Signed-off-by: Samuel Just <sjust@redhat.com>
Most of the flavor, sha1, tag etc. selection logic as implemented in the
packaging module of teuthology relies on remote hosts. This is complex
to tests and inconvenient because hosts must be provisionned even before
trying to figure out which packages need to be installed.
Using remote hosts is necessary when bare metal targets are used because
teuthology must adapt to the operating system already installed. The
selection logic in the context of dynamically provisionned targets is
simpler because it is defined by the job being run.
The buildpackages is refactored to use only the job configuration to
figure out which packages must be built. It makes it specific to targets
that are dynamically provisionned. It would have to be modified to query
the remote host in the case of bare metal targets.
Signed-off-by: Loic Dachary <loic@dachary.org>
