...for recent config changes. Explain about MgrModule.OPTIONS,
and explain the new store/config distinction.
Signed-off-by: John Spray <john.spray@redhat.com>
They need these to do upgrades properly. Where there
was an existing structure describing config, merge
these together to avoid having two lists of options.
Signed-off-by: John Spray <john.spray@redhat.com>
Modules will now only migrate items from config-key
into config options if they appear in the module's
schema.
Signed-off-by: John Spray <john.spray@redhat.com>
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>
