Now is a good time to start requiring
modules to explicitly list their configuration
settings, so that we can do a proper job of
migrating configuration from old config-key style,
i.e. knowing what's a config setting and what's
a KV store item.
Throw an exception if a module tries to
access a setting outside their schema, so
that we have some confidence that the schema
is complete.
Signed-off-by: John Spray <john.spray@redhat.com>
This is still completely legal, but isn't going
to have the effect they wanted if they were
trying to set a configuration option for a mgr module.
Signed-off-by: John Spray <john.spray@redhat.com>
The _prefix variant was only used for data-ish things,
so we can just move it over to operate on store instead
of config, rather than having a _prefix variant for both.
Signed-off-by: John Spray <john.spray@redhat.com>
A quickie heuristic, but sufficient to avoid picking
up e.g. SSL certs and trying to cram them into
config values.
Signed-off-by: John Spray <john.spray@redhat.com>
...and remove redundant config-key lines (these are applied
to mgr anyway in the next block, and mgr even has a broader
config-key permission in the line above).
Signed-off-by: John Spray <john.spray@redhat.com>
The locking and blocking around this was a bit
tricky. Do the simple thing, and pull the
load_store out to Mgr so that it can be safely
done as part of the background_init process (just drop
Mgr::lock across blocking actions).
Signed-off-by: John Spray <john.spray@redhat.com>
This is a follow-up fix of https://github.com/ceph/ceph/pull/21578,
in which I forget that erasure-coded-pools share the same logic
when determining the async_recovery_targets..
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
"ceph fs set cephfs allow_multimds false" is deprecated, and multimds is
enabled by default, so "ceph fs set cephfs max_mds 4" won't fail with
the default settings.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Theoretically peers which have a longer list of objects to recover
shall equivalently take a longer time to recover and hence have a
bigger chance to block client ops.
Also, to minimize the risk of data loss, we want to bring those broken
(inconsistent) peers back to normal as soon as possible. Putting them
into the async_recovery_targets queue, however, did quite the oppsite.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
cmake: hide symbols import from other libraries in libcls_*
Reviewed-by: Jason Dillaman <dillaman@redhat.com>
Reviewed-by: Casey Bodley <cbodley@redhat.com>
to silence the warnings like
CMake Warning at CMakeLists.txt:73 (find_package):
By not providing "Findgflags.cmake" in CMAKE_MODULE_PATH this project
has
asked CMake to find a package configuration file provided by "gflags",
but
CMake did not find one.
Could not find a package configuration file provided by "gflags" with
any
of the following names:
gflagsConfig.cmake
gflags-config.cmake
Add the installation prefix of "gflags" to CMAKE_PREFIX_PATH or set
"gflags_DIR" to a directory containing one of the above files. If
"gflags"
provides a separate development package or SDK, be sure it has been
installed.
Signed-off-by: Kefu Chai <kchai@redhat.com>
so they will not be involved when resolving symbols. ld tries to
keep a shared library around even if it fails to load it if it offers
some unique symbols. in that case, the library will not be properly
unloaded, and even worse it will interfere with following dlopen()
calls, because it is marked with NODELETE by dlopen(). if it has some
unresolved symbol and does offer some "unique" symbols required by
the library to be loaded, the library will fail to load, despite the
fact that the "unique" symbol is also offered by the executable.
for more details, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60731 and
https://sourceware.org/bugzilla/show_bug.cgi?id=14577
Fixes: http://tracker.ceph.com/issues/23517
Signed-off-by: Kefu Chai <kchai@redhat.com>
somehow this was breaking the seeding of thread-local engines on gcc.
we'll have to investigate this further, but for now i'm reverting this
piece to get messengers working again
Fixes: http://tracker.ceph.com/issues/23778
Signed-off-by: Casey Bodley <cbodley@redhat.com>
Updated the dashboard feature list in the documentation to mention
the possibility to list Ceph pools and the RGW users and their buckets.
Signed-off-by: Lenz Grimmer <lgrimmer@suse.com>
