This flag is used in the inventory reporting and available is deemed more
appropriate. Furthermore this fixes a bug where rejected_reasons
accumulated duplicate entries.
Fixes: http://tracker.ceph.com/issues/36701
Signed-off-by: Jan Fajerski <jfajerski@suse.com>
Separate diskprediction local cloud from the diskprediction plugin.
Devicehealth invoke device prediction function related on the global
configuration "device_failure_prediction_mode".
Signed-off-by: Rick Chen <rick.chen@prophetstor.com>
The ServiceDescription object just holds a list of ServiceLocation
objects. Eliminate ServiceLocation and merge it into the
ServiceDescription class. Have describe_service return a list of
ServiceDescriptions.
Suggested-by: Tim Serong <tserong@suse.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
There's currently no way to enumerate the services that the
orchestrator backend knows about. Add a "service ls" command
that will list them with some basic info, subject to filters
given on the command line.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Rework the describe_service operation for rook to allow listing of
services, with optional filters for service type, id and nodename.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
log is not very visible from user's perspective. we'd better return the
error message using the input parameter, if the technique is
unsupported.
also, remove the trailing newline, as `ss` will be sent back to user,
it's the the front-end's responsibility to format the error message.
Signed-off-by: Kefu Chai <kchai@redhat.com>
This reverts commit c5bafae6fd.
in 37f73607 and 3ec41030, we detect invalid "k". and we should always
detect invalid combinations of parameters in
ErasureCodeInterface::init(), and return -EINVAL instead of "autotune" them
as put in the commit message of c5bafae6, if the profile is invalid for
given erasure plugin. so ErasureCodeBench::encode() and
ErasureCodeBench::decode() will bail out with the error message returned by
ErasureCodeInterface::init() if the parameters are not valid.
also, i checked all ErasureCodeInterface::init() implementations, none
of them is overwriting the settings without returning a non-zero return
code. so we are not overriding or autotuning the settings specified by
user.
Fixes: http://tracker.ceph.com/issues/16500
Signed-off-by: Kefu Chai <kchai@redhat.com>
ceph-mgr: hold lock while accessing the request list and submitting request
Reviewed-by: Boris Ranto <branto@redhat.com>
Reviewed-by: Kefu Chai <kchai@redhat.com>
before this change, the `need_open_db` parameter is passed to the
constructor of BlueStore as `min_alloc_size`. and rocksdb will fail to
repair because Repairer::Run() also tries to acquire the db lock, and it
will fail to do so if the lock file is already acquired by
BlueStore::_mount().
Signed-off-by: Kefu Chai <kchai@redhat.com>
before this change, we assume that the variable set if rados::radospp is
found will be radospp_FOUND, but this is a feature cmake 3, see
https://cmake.org/cmake/help/v3.3/module/FindPackageHandleStandardArgs.html
while the cmake shipped by centos is cmake 2.8.12, where the variable
name will be <UPPERCASED_NAME>_FOUND, see
https://cmake.org/cmake/help/v2.8.12/cmake.html#module:FindPackageHandleStandardArgs
in the test of test_envlibrados_for_rocksdb.sh, we are using cmake not
the cmake3 offered by EPEL7, so RADOSPP_FOUND will be set instead. that's why
executable env_librados_test will fail to link against rados::radospp.
as rados::radospp won't be defined if radospp_FOUND is not defined/set.
after this change, the 2nd mode of FIND_PACKAGE_HANDLE_STANDARD_ARGS()
is used instead to ensure that radospp_FOUND is defined even if cmake
2.8.12 is used.
also, the message() commands for debugging purpose are removed.
Signed-off-by: Kefu Chai <kchai@redhat.com>
we use the playbook of "testnodes.yml" defined by ceph-cm-ansible for
initializing test nodes, and the role of "testnode" is used by
testnodes.yml. "testnode" requires "qemu-system-x86" or "qemu-kvm"
package to be installed. the qemu in turn depends on librbd1 and
librados2.
before librados3 was introduced, this worked perfectly. because in ceph
repo, qa/packages/packages.yaml defines the default set of packages the
"install" tasks should install. and in that yaml file, librados2 was
listed. so the package management system will overwrite the librados2
installed by ansible playbook with the version specified by the
"install" task, as apt/yum thinks this is what user requires explicitly,
so it's fine to install a different version of librados2.
after librados3 was introduced, librados2 was removed from
qa/packages/packages.yaml. because, by default, we need to install
librados3 instead of librados2 for ready a nautilus cluster. but the
problem is, the packge list also applies to "install" tasks installing
releases before nautilus, where we still need to replace the librados2
installed by ansible.
so, to address this issue, "librados2" is added to "extra_packages" of
the "install" tasks of tests installing old releases to install
librados2 explicitly instead of as a dependency of other ceph packages
like librbd1.
Signed-off-by: Kefu Chai <kchai@redhat.com>
