On Fri, Aug 17, 2018 at 5:30 PM David Zafman <dzafman@xxxxxxxxxx> wrote: > > > Noah, > > When running run-standalone.sh the test-ceph-helpers.sh and > ceph_objectstore_tool.py file because health won't go clean. I am > getting "message": "Module 'crash' has failed: Unknown error." > > Is there something wrong with my build tree? Or am I missing an > external python module? There's no error when running a normal vstart cluster, and when I try that test runner I can see its mgr_module_path is pointing at /usr/local, so I'd guess that's the cause. Does that test runner have special requirements around how daemons are run, or could we converge it on using vstart.sh? John > > The run-standalone.sh is a relatively new thing we added to remove some > slower tests from "make check". You could run this in your own build > tree like this. > > > cd build > > ../qa/run-standalone.sh > > You can also run a single test: > > ../qa/run-standalone.sh test-ceph-helpers.sh > > Or even a subtest > > ../qa/run-standalone.sh "test-ceph-helpers.sh test_wait_for_health_ok" > > > I see you added this code: > > commit cf292dfa8f9254e5095689c45a3d5e895e5df333 > Author: Noah Watkins <nwatkins@xxxxxxxxxx> > Date: Mon Jul 16 22:24:48 2018 -0700 > > mgr: create always_on class of modules > > 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@xxxxxxxxxx> > > > > Thanks > > David > >
