support an 'always on' class of ceph-mgr modules. the purpose of an
always-on module is to behave as built-in / non-optional functionality.
this is accomplished by treating always-on modules as enabled
irregardless of the enabled set produced by the manager monitor.
always-on modules that fail to load are reported as health errors.
always-on modules are intended to satisfy important dependencies in a
cluster. as such, the set of always-on modules is specified statically,
as opposed to a property on the Python class, to enable robust error
reporting of always on modules that fail to load.
Signed-off-by: Noah Watkins <nwatkins@redhat.com>
If an uncaught runtime exception occurs in a module constructor, then
the manager still tries to deliver notifications resulting in errors
like:
src/mgr/ActivePyModule.cc: 54: FAILED assert(pClassInstance != nullptr)
This removes the failed module from the set of active modules that
should receive command and notifications.
This also serves as a basis for accurately determining if the manager
satisifes all "always on" module constraints.
Signed-off-by: Noah Watkins <nwatkins@redhat.com>
* Assert `pg_placement_num` has the same value as `pg_num`.
* Only set `application_metadata`, if not None.
* `osd pool set` only accepts strings.
* Sync `pgp_num` with `pg_num`.
Signed-off-by: Stephan Müller <smueller@suse.com>
The snap iterator now includes the namespace type and group/trash
sub-dictionaries (if applicable). It's also possible to remove a
non-user snapshot by its id.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
for the same reason why we moved ObserverMgr out of md_config_impl<>,
"changed" cannot be shared among shards, we should move "changed" out of
md_config_impl. we can put "changed" into ConfigValues or
ConfigProxy, IMHO, it would be simpler if "changed" resides in
ConfigValues: less fragmented this way.
Signed-off-by: Kefu Chai <kchai@redhat.com>
see also the previous the commit, to reuse injectargs() and
set_mon_vals() in seastar's ConfigProxy, we need to move apply_changes()
call out of them, as this call is implemented differently in seastar's
ConfigProxy.
finalize_reexpand_meta() is not used by OSD at this moment, so we leave
it as it is for now.
* move _apply_changes() calls up into ConfigProxy
* move update_legacy_vals() out of _apply_changes() into the
callers of the latter. as it changes "values", in seastar's ConfigProxy,
it belongs to the first step of changing a config value
Signed-off-by: Kefu Chai <kchai@redhat.com>
seastar's ConfigProxy and alien's ConfigProxy follow different threading
models and expose different methods. the former updates a setting with 3
steps:
1. create a local copy of current setting, and apply the proposed change
to the copy
2. populate the updated change with a foreign_ptr<> to all shards
(including itself)
3. on each shards, call apply_changes() to get the interested observers
updated, please note, apply_changes() should only update the local
observers on current shard.
while the alien's ConfigProxy do all the job in a single synchronized
call,
but we can split it into a finer-grained steps:
1. apply the proposed change in-place
2. apply_changes() to get the interested observers updated.
so, to reuse the code across these two implementations, for instance,
set_mon_vals() will be implemented in ConfigProxy instead, so we can
have different behavior in different ConfigProxy classes. if we keep
using the existing single-piece md_config_t::set_mon_vals(), we have no
chance to differentiate the apply_changes() for seastar port. but the
alien implementation requires a grand lock protecting set_val() and
apply_changes(), so we have to move the lock from md_config_t up to
ConfigProxy. it's also simpler this way, as we don't need an extra layer
to have a dummy Mutex for seastar's ConfigProxy. as only the alien's
ConfigProxy requires the lock.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Since we are no longer using karma for the frontend unit tests, we will remove
all the related packages and configurations.
This includes the removal of the phantomjs package.
Signed-off-by: Tiago Melo <tmelo@suse.com>
Currently Angular CLI is polluting the jenkins logs, by inserting a new line
each time the build process is updated.
With this change Angular CLI will only output the necessary information about
the start and end of the build.
Signed-off-by: Tiago Melo <tmelo@suse.com>
