- don't specify ceph.py options in the ceph.py
- instead, specify them in the per-version facet
Note that we don't currently have a way to do v2 only for the mon IPs, so
in the v2only cases, we are still binding the mons to v1.
Signed-off-by: Sage Weil <sage@redhat.com>
mgr/dashboard: Add separate option to config SSL port
Reviewed-by: Ernesto Puerta <epuertat@redhat.com>
Reviewed-by: Sebastian Wagner <swagner@suse.com>
Reviewed-by: Tatjana Dehler <tdehler@suse.com>
* refs/pull/27169/head:
common/config: parse --default-$option as a default value
Reviewed-by: Sébastien Han <seb@redhat.com>
Reviewed-by: Neha Ojha <nojha@redhat.com>
Sometimes it is useful to specify an alternative default value for an
option via the command line such that it has a lower priority than the
mon config database, config file, the rest of the command line, or the
environment.
Signed-off-by: Sage Weil <sage@redhat.com>
Leave repair pg state on until recovery finishes or a new scrub starts
Fixes: http://tracker.ceph.com/issues/38616
Signed-off-by: David Zafman <dzafman@redhat.com>
With discard_granularity set to alloc_size, we no longer get object
size alignment from blk_bio_discard_split().
This assumption is pretty deeply ingrained in krbd_data_pool.sh, so
make it explicit. For krbd_fallocate.sh, just fix the expectation.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
The test case is issuing discards that span two objects: the tail of
the first object is truncated, the head of the second object is zeroed.
These discards aren't serial, so there is a race:
discard i ~ i + 1: truncate i, zero i + 1
discard i + 1 ~ i + 2: truncate i + 1, zero i + 2
can be executed as
truncate i + 1, zero i + 2, truncate i, zero i + 1
For object i + 1, the sequence ends up being truncate tail, then zero
head. This zero op is munged to truncate on the OSD, resulting in size
0 instead of OBJECT_SIZE / 2.
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This way it can be used to fast cancel/undo the last command.
Also make the tip message a litter bit nicer..
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
Allow auto_repair for replicated bluestore pools
Regular scrub within auto repair parameters will trigger deep scrub
New state failed_repair if PG repair attempt could not fix everything
Set failed_repair if not possible to repair anything
Fixes: http://tracker.ceph.com/issues/38616
Signed-off-by: David Zafman <dzafman@redhat.com>
Fix for argument handling of create_ec_pool()
Always pass a value for allow_overwrites for consistency
Caused by: 3ca750d41d
Signed-off-by: David Zafman <dzafman@redhat.com>
- start with msgr2 enabled (defaults)
- run nautilus branch for workunits
- drop msgr2 enable step at teh end
- add octopus placeholder (although it is empty for now)
Signed-off-by: Sage Weil <sage@redhat.com>
* refs/pull/27112/head:
qa/suites: do not test luminous-x upgrade path
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Neha Ojha <nojha@redhat.com>
qa/objectstore: test with reduced value of osd_memory_target
Reviewed-by: Brad Hubbard <bhubbard@redhat.com>
Reviewed-by: Sage Weil <sage@redhat.com>
Reviewed-by: Mark Nelson <mnelson@redhat.com>
in this change,
* suites/rados/upgrade: luminous-x-singleton => mimic-x-singleton
* suites/upgrade: luminous-x => nautilus-x
we support upgrade from n to n+2 release. otherwise monitor refuses to
do so:
mon.a@-1(probing) e1 current monmap has min_mon_release 15 (luminous)
which is >2 releases older than me 15 (octopus), stopping.
Fixes: https://tracker.ceph.com/issues/38845
Signed-off-by: Kefu Chai <kchai@redhat.com>
The changes of this PR were done while trying to fix the failing test. The problem has been solved by another PR, but the changes are worth to be integrated because they help debugging and an additional test has been added (check if previously active manager is listed as standby).
Signed-off-by: Volker Theile <vtheile@suse.com>
mgr/orchestrator: Add error handling to interface
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Juan Miguel Olmo Martínez <jolmomar@redhat.com>
Reviewed-by: Tim Serong <tserong@suse.com>
There is a lot of good stuff going on here, but nobody is investing in xio
and it is not expected to be the path forward for RDMA. If that ever
changes, we can resurrect the code. Until then, let's clean up the tree
and reduce friction for changes going forward.
Signed-off-by: Sage Weil <sage@redhat.com>
