mgr/dashboard: Adapt RBD form to new application_metadata type
Reviewed-by: Sebastian Wagner <sebastian.wagner@suse.com>
Reviewed-by: Ricardo Marques <rimarques@suse.com>
Reviewed-by: Stephan Müller <smueller@suse.com>
* refs/pull/21536/head:
qa: check old_max_mds is not wiped by marked down twice
MDSMonitor: do not wipe old_max_mds when marked down twice
Reviewed-by: Douglas Fuller <dfuller@redhat.com>
pg will be created when increasing pgp-num and pg-num. so at that
moment, PG_AVAILABILITY is reported. so whitelist it in all tests which
run rados/test.sh. that script exercises ceph_test_rados_api_list.
Fixes: http://tracker.ceph.com/issues/23763
Signed-off-by: Kefu Chai <kchai@redhat.com>
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>
...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>
