there is chance that /var/log/ceph (and other directories) is not
created when cephadm fails, but we always try to collect /var/log/ceph
by tar the directory on the test node and transfer it back for archiving
it. when we fail to do so, an exception is thrown, and this exception is
in turn logged as the cause of the failure instead of the one which
fails the test.
in this change, `tarfile.TarError`s is caught and ignored if it is
thrown by `misc.pull_directory()`, as normally, we don't consider it a fatal
failure when `misc.pull_directory()` fails because of `tar`. the
failures for the test are.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/35062/head:
qa/tasks/cephfs/fuse_mount.py: retry when the admin socket is not ready
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
* refs/pull/34596/head:
test: add a new program for testing ino_release_cb
client: add a new inode release request callback
client: expose ceph_ll_register_callbacks via libcephfs
client: move callback typedefs and arg struct into ceph_ll_client.h
client: rename ceph_statx.h to ceph_ll_client.h
client: make client_dentry_callback_t more friendly for C
client: only override umask_cb with non-NULL values
Reviewed-by: Xiubo Li <xiubli@redhat.com>
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Zheng Yan <zyan@redhat.com>
Reviewed-by: Greg Farnum <gfarnum@redhat.com>
* refs/pull/34951/head:
qa/cephfs: run() cleanup whether FS was mounted or not
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Xiubo Li <xiubli@redhat.com>
This reverts commit 835f2f5f51.
Reverting this to narrow down recent failures seen in rados and upgrade suites.
Signed-off-by: Neha Ojha <nojha@redhat.com>
We don't really care if this is left on during the course of the mount.
These settings don't persist across tests anyway.
Fixes: https://tracker.ceph.com/issues/45525
Signed-off-by: Patrick Donnelly <pdonnell@redhat.com>
Add the possibility of being able to run cephadm.py on clusters that
were already bootstrapped by some other task/way so you can deploy the
rest of the daemons/services.
Signed-off-by: Georgios Kyratsas <gkyratsas@suse.com>
In case the mount command in mount() fails, it would still have created
the mountpoint and network namespace for the FS's mount. Therefore, run
cleanup() and cleanup_netns() in umount() and umount_wait() even when
self.mounted is set to False.
Also, move the call to cleanup_netns() in cleanup().
Fixes: https://tracker.ceph.com/issues/45430
Signed-off-by: Rishabh Dave <ridave@redhat.com>
* refs/pull/34978/head:
qa/tasks/cephfs/mount.py: always setup the NAT rules
qa/tasks/cephfs/mount.py: fall back to use ip command to setup the bridge
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Rishabh Dave <ridave@redhat.com>
Reviewed-by: Ramana Raja <rraja@redhat.com>
If the last test failed just after the 'ceph-brx' bridge is created
but with setuping the NAT rules in iptables, so if we run the test
case again, it will just skip seting the 'ceph-brx' and the NAT rules.
Then deleting the NAT rules will get the errors like:
iptables: Bad rule (does a matching rule exist in that chain?).
Signed-off-by: Xiubo Li <xiubli@redhat.com>
CentOS/RHEL8 have abandoned the bridge-utils package so the brctl
cmd is none avalible, and on Ubuntu 18.04 and 20.04 the nmcli is
buggy to setup the bridge. So this will fall back to use ip cmd
to setup the bridge stuff.
Fixes: https://tracker.ceph.com/issues/45459
Signed-off-by: Xiubo Li <xiubli@redhat.com>
* refs/pull/34962/head:
vstart_runner.py: use tuple instead of set
Reviewed-by: Sidharth Anupkrishnan <sanupkri@redhat.com>
Reviewed-by: Patrick Donnelly <pdonnell@redhat.com>
Using python3 leads to an error that says
"TypeError: unhashable type: 'Raw'".
Fixes: https://tracker.ceph.com/issues/45446
Signed-off-by: Rishabh Dave <ridave@redhat.com>
qa/tasks/mgr: always add "application" label to pool
Reviewed-by: Alfonso Martínez <almartin@redhat.com>
Reviewed-by: Stephan Müller <smueller@suse.com>
