There are some up-front checks in DaemonServer
but it shouldn't assume that its checks are
necessarily going to match the choices about
how ActivePyModules composes its ::modules member,
so let's have some extra checks to avoid
risk of crashing mgr on commands sent to
unhealthy/unloaded modules.
Signed-off-by: John Spray <john.spray@redhat.com>
We execute modules even if can_run=false, so that it is possible
to load them for running their selftest hooks. However,
we already raise health messages about the fact that they're
enabled but can't run, so we don't want to also raise
health messages about whatever exceptions they raise
from serve()
Signed-off-by: John Spray <john.spray@redhat.com>
the influx plugin requires influxdb python module to function, but
influxdb mgr plugin is optional for users who don't use influxdb.
so it's marked "Suggests" at this moment before we use a more flexible
packaging scheme.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Fix for bug introduced with 096668ec5d:
In file included from src/objclass/objclass.h:13:0,
from src/cls/hello/cls_hello.cc:37:
src/include/rados/objclass.h:31:1: error: ‘CEPH_CLS_API’ does not name a
type; did you mean ‘CEPH_CAP_ANY’?
CEPH_CLS_API void name##_cls_init()
^
/develop/ceph/source/ceph/src/include/rados/objclass.h:31:1: note: in
definition of macro ‘CLS_INIT’
CEPH_CLS_API void name##_cls_init()
^~~~~~~~~~~~
Signed-off-by: Danny Al-Gaaf <danny.al-gaaf@bisect.de>
Avoid completing a write until luminous peers also apply the change.
This is overkill, but works around a problem where completing our write
here allows the next read to start too early. This is because the
PrimaryLogPG is handling the write-to-read ordering, but completing the
write releases the write lock in the PG.
Signed-off-by: Sage Weil <sage@redhat.com>
fetch_remote_obj() only gets 16k blocks from libcurl, which leads to a
much worse compression ratio than the 4m blocks in normal PUT requests
Fixes: http://tracker.ceph.com/issues/23547
Signed-off-by: Casey Bodley <cbodley@redhat.com>
...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>
