mgr/dashboard: add some test for controllers/pool.py
Reviewed-by: Avan Thakkar <athakkar@redhat.com>
Reviewed-by: Nizamudeen A <nia@redhat.com>
Reviewed-by: Pere Diaz Bou <pdiazbou@redhat.com>
doc: remove extra comma.
This commit remove extra comma of "To disable prediction,:".
Fixes: https://tracker.ceph.com/issues/53433
Signed-off-by: devlikai <likai_lc@inspur.com>
But, do not throw away the old style mount syntax since we would
want to continue testing it since users (scripts) might still be
using it.
Signed-off-by: Venky Shankar <vshankar@redhat.com>
Old mount device (source) have the following problems:
- mounts to the same cluster but with different fsnames
and/or creds have identical device string which can
confuse xfstests.
- device shown in /proc/mounts is different that what
is used to mount.
New proposed syntax is as follows:
# mount -t ceph cephuser@<cluster-fsid>.mycephfs2=/path
The cluster-id is optional but is always passed to the kernel
via mount() syscall (by fetching it from cluster configuration
file if available).
The mount helper tries the mounting the file system with
the new device syntax, falling back to using the old
syntax if required.
Signed-off-by: Venky Shankar <vshankar@redhat.com>
This will be required when switching to new mount device
syntax when cluster fsid will be passed to kernel as mount
option.
Signed-off-by: Venky Shankar <vshankar@redhat.com>
With new mount device syntax monitor host(s) can be passed
during mount as option parameter. This option is not mandatory
as it can be fetched from the cluster configuration file if
available.
Signed-off-by: Venky Shankar <vshankar@redhat.com>
In f76c02a658 we may leave out the placement
key when it is empty. If we take that path, we need to tolerate specs
that are missing that key.
Fixes: f76c02a658
Signed-off-by: Sage Weil <sage@newdream.net>
* refs/pull/44030/head:
mgr/cephadm: add some debug output for serve loop
ceph-volume: adjust arguments for 'ceph-volume raw activate'
ceph-volume: add raw support for db/wal for list and activate
Reviewed-by: Sébastien Han <seb@redhat.com>
Take a list of devices, so that we can selectively activate a raw osd
with db/wal.
Remove the argument type kludge introduced in 2c228a9a40
since it is no longer needed.
Note that we're making this change because (1) it allows db/wal and (2)
because there are no known users of 'raw activate'. The only known user
is via 'ceph-volume activate' and we've fixed that caller in this commit.
Signed-off-by: Sage Weil <sage@newdream.net>
Currently 'prepare' doesn't support db/wal, but we want it in list and
activate because 'ceph-volume activate ...' tries raw before lvm.
Note that I'm not sure we really want to accept --block.db and --block.wal
here at all.
Fixes: 3d7ceec684
Signed-off-by: Sage Weil <sage@newdream.net>
We cannot schedule a daemon start if there is another daemon action
with a higher priority (including stop) scheduled. However,
that state isn't cleared until *after* the osd goes down, the
systemctl command returns, and mgr/cephadm gets around to updating
the inventory scheduled_daemon_action state.
Semi-fix: (1) wait for the orch status to change, and then (2)
wait a few more seconds after that.
Signed-off-by: Sage Weil <sage@newdream.net>
In process of tests, we met some inconsistent-data problem. Test case
mainly use write,then discard to detect data consistent.
W/o pwl, write/discard are synchronous ops. After write, data already
located into osd. But w/ pwl, we use asynchronous api to send ops to
osd.
Although we mare sure send order. But send-order don't makre sure
complete order. This mean pwl keep order of write/discard. But it
don't keep the same semantics which use synchronous api. W/ pwl, it make
synchronous to asynchronous. For normal ops, it's not problem. But if
connected-commands w/ overlap, it make data inconsistent.
So we use BlockGuard to solve this issue.
Fixes: https://tracker.ceph.com/issues/49876
Fixes: https://tracker.ceph.com/issues/53108
Signed-off-by: Jianpeng Ma <jianpeng.ma@intel.com>
crimson/common: don't assume pointer-from-SharedLRU can't outlive it.
Reviewed-by: Chunmei Liu <chunmei.liu@intel.com>
Reviewed-by: Samuel Just <sjust@redhat.com>
Re-initializing the same datacryptor, causes a memory leak of the old encryption key.
This commit fixes this issue.
Signed-off-by: Or Ozeri <oro@il.ibm.com>
