Since the arm gitbuilder (even using a ton of nodes for distcc) is
much slower than x86 lets grab the sha1 from its own gitbuilder
when machine_type is saya rather than the x86 one.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Fixed some things that were being done incorrectly.
Some distro kernels have no debug so added | true when disabling
kdb. Also changed what was skipping kernels if non-ubuntu to also
schedule kernel install if a distro kernel.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Since we modify the dict, make sure it is a deep copy.
Otherwise, a sequence like:
- install.upgrade:
all:
branch: dumpling
...
- install.upgrade:
all: null
will delete the overrides keys in the first upgrade call and
then not have them at all in the second.
Signed-off-by: Sage Weil <sage@inktank.com>
up the iscsi service and logins to an rbd image using the tgt service
(either locally or remotely). The iscsi service runs some
simple tests, and then sets up the isci-image to be useable by
rbd test scripts. Later workunits can perform further testing
on the isci-image interface.
In order to add the new tasks, common_fs_utils.py was formed
from code extracted out of rbd.py. Rbd.py and iscsi.py both
call the functions in this module.
Fixes: #6433
Signed-off-by: Warren Usui <warren.usui@inktank.com>
Reviewed-by: Josh Durgin
If the upgrade task config has a branch: (or tag or sha1), do
not apply the sha1|branch|tag overrides keys. This fixes the
breakage from 280f783c2e which
made
overrides:
install:
ceph:
sha1: f88866fe9c
tasks:
...
- install.upgrade:
all:
branch: dumpling
...use the sha1 from the overrides instead of the explicitly
specified branch. The intention was to only use the overrides
when the version was not specified (whether it was sha1 or
branch or tag).
At some point we should probably make the same change for
install function in install.py, but let's fix this first to
get the upgrade tests working.
Signed-off-by: Sage Weil <sage@inktank.com>
Definitely some enhancements can be done. I think I have everything
needed but I have not been able to test this yet. If this needs to
get done before I am back feel free to work on it.
Completely untested and probably a few mistakes somewhere...
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Since the default OS version is different for each distro the
argument default is None instead of explicity set to a value
like with get_distro. Fixed some logic around that and the tests
making the arugment always take precidence.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
You can use --os-type as an argument when not running teuthology
tests but instead just using teuthology-lock. This adds the ability
to also use --os-version so you can specify the version of the
distro without having to run an actual test with a yaml like you
normally would have had to do setting os_version in the yaml.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Ubuntu's default apache uses worker instead of prefork like rpm
based distro's. If rpm use httpd.worker instead of httpd so that
the -X behavior will not be blocked by a single request.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
Ubuntu's default apache uses worker instead of prefork like rpm
based distro's. If rpm use httpd.worker instead of httpd so that
the -X behavior will not be blocked by a single request.
Signed-off-by: Sandon Van Ness <sandon@inktank.com>
This breaks on 32-bit architectures because fsx can't allocate the
in-memory buffer or hit some other limit. 500MG also seems to run out of
memory (tho it at least does not segfault).
Fixes: #6576
Signed-off-by: Sage Weil <sage@inktank.com>
This is an annoying race, we really should delay going
clean until the backfill peer has acknoledged the clean
info, but we currently don't. In order to prevent this
bug from messing up the nightlies, we'll delay killing
the peer for 20s to make it likely that the backfill
peer has gotten the clean info.
Workaround: #6116
Signed-off-by: Samuel Just <sam.just@inktank.com>
