to build helloworld of librados, we need to install the build
dependencies.
Fixes: https://tracker.ceph.com/issues/40155
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 have switched from tmap to omap long ago.
but keep the server side implementation around, in case ancient
client is still using these tmap APIs.
also, tmap_update() is kept, because librbd is using it for v1 image
backward compatibility.
Signed-off-by: Kefu Chai <kchai@redhat.com>
include a patch so rocksdb can use libradospp instead of librados. will
upstream the patch and make it work for both pre-nautilus librados and
nautilus libradospp
Signed-off-by: Kefu Chai <kchai@redhat.com>
the goal is to decouple C++ API from C API, and to version them
differently, as they are targeting different consumers.
this allows us to change the C++ API and bumping up its soversion
without requiring consumer to recompile the librados client for
using the new librados. in this way, C++ API can move faster than
C API. for example, if bufferlist interface is changed for better
performance, and this breaks existing API/ABI, we can bump up
the C++ library's soversion, and and the C library's version unchanged
but ship the new librados's C binding. so the librados client linked
against librados's C library will be able to take advantage of
the improvement in C++ library. while the librados client
linked against C++ library won't break at runtime due to unresolved
symbol or changed structure layout.
this is massive change, the genereal idea is to
* split librados.cc into two source files: librados_c.cc and
librados_cxx.cc, the former for implementing C APIs, the later
for C++ APIs.
* extract the C++ API in librados into librados-cxx, the library
name will be libradospp. but we can change it before nautilus
is released.
* link these librados libraries with static libraries which it
depends on, so "-Wl,--exclude-libs,ALL" link flags can help
hide the non-public symbols.
* extract the tests exercising librados' C++ API into a different
source file named *_cxx.cc. for instance, to move the C++ tests
in aio.cc into aio_cxx.cc
* extract the shared helper functions which do not use any librados
or librados-cxx APIs into test_shared{.cc,h}. the "shared" here
means, *shared* by C++ and C tests.
* extract the test fixtures, i.e., the subclasses of testing::Test,
for testing C++ APIs into testcase_cxx.cc.
* update qa/workunits/rados/test.sh accordingly to add the splitted
tests
* update the consumers of librados to link against librados-cxx
instead, if they are using the C++ API.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* so we just rely on a single build system instead of two of them, the
other place we use cmake is cmake/modules/BuildRockDB.cmake.
* disable gflags when building rocksdb, it's optional and does not help
in the sense of testing librados support.
* disable prompts when installing on debian, to silence warnings like:
debconf: unable to initialize frontend: Dialog
* drop --force-yes option, as it is deprecated, and is replaced with
--allow-downgrades, --allow-remove-essential,
--allow-change-held-packages, but none of them apply in our case.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Defines asynchronous librados operations that satisfy all of the
"Requirements on asynchronous operations" imposed by the C++ Networking
TS [1] in section 13.2.7. These operations are implemented in terms of
boost::asio, but the interfaces themselves are free of boost types -
this makes the transition to std::net trivial when it's available.
These interfaces conform to the Extensible Asynchronous Model [2] that
originated in boost::asio. This model allows the last 'handler' argument
to either be a callback that gets the result, a coroutine yield_context
that will suspend until completion, or a 'use_future' tag to request the
result in a std::future (see the unit tests for examples of each). The
'Extensible' part also enables further integration with new frameworks.
For now, only async_read(), async_write(), and the read/write variants
of async_operate() are provided.
[1] Working Draft, C++ Extensions for Networking
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4711.pdf
[2] "Library Foundations for Asynchronous Operations"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3896.pdf
Signed-off-by: Casey Bodley <cbodley@redhat.com>
We now set full flag if a pool is currently running out of space and
set both full and full_no_quota flags if it is running out of quota.
Therefore the full_no_quota flag should be instead used to uniquely
identify whether we are running out of quota or not.
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
https://github.com/ceph/ceph/pull/17371 introduces support of
per-pool space-full flag, which turns out to set both
full and full_no_quota flags now if a pool is currently running out
of quota.
Actually this test is fragile as long as we keep appending new flags
at pool granularity, but let's not bother with that complexity now.
Fixes: http://tracker.ceph.com/issues/21409
Signed-off-by: xie xingguo <xie.xingguo@zte.com.cn>
/bin/bash is a Linuxism. Other operating systems install bash to
different paths. Use /usr/bin/env in shebangs to find bash.
Signed-off-by: Alan Somers <asomers@gmail.com>
1) ruleset is an obsolete term, and
2) crush-{rule,failure-domain,...} is more descriptive.
Note that we are changing the names of the erasure code profile keys
from ruleset-* to crush-*. We will update this on upgrade when the
luminous flag is set, but that means that during mon upgrade you cannot
create EC pools that use these fields.
When the upgrade completes (users sets require_osd_release = luminous)
existing ec profiles are updated automatically.
Signed-off-by: Sage Weil <sage@redhat.com>
