John,
We have a fix in:
https://github.com/ceph/ceph/pull/23637
David
On 8/20/18 1:23 AM, John Spray wrote:
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
