This provides an 'iostat' and 'top'-like IO monitor for all
RBD images
Fixes: http://tracker.ceph.com/issues/37913
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The ambiguous shebang now produces an error in rawhide and halts the
build. In f29 this was a warning. Add python3 as a dependency for
ceph-fuse.
Fixes: http://tracker.ceph.com/issues/37787
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
Currently rbd-mirror and radosgw packages installation won't create the
Ceph directories in /var/lib/ceph since they depend on ceph-common
only. ceph-base is responsible for creating these directories.
Since ceph-base requires ceph-common then let's use ceph-base as a
dependency.
Fixes: http://tracker.ceph.com/issues/37620
Signed-off-by: Sébastien Han <seb@redhat.com>
This is only required to get the spec file to build in the OpenSUSE
Build Service (OBS). Also, this change could potentially make the
package impossible to install together with grafana (if the latter
owns the same directories with different ownership/permissions).
Therefore, make the change specific to SUSE.
Fixes: http://tracker.ceph.com/issues/37485
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Signed-off-by: Tim Serong <tserong@suse.com>
Cython version 0.29 removed the support for python subinterpreters,
which completely breaks ceph-mgr funcionality.
See cython repo commit:
7e27c7cd51
Fixes: http://tracker.ceph.com/issues/37472
Signed-off-by: Ricardo Dias <rdias@suse.com>
The %bcond_with and %bcond_without macros are confusing to folks who
don't do a lot of RPM packaging work. Let's try to help these folks out!
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Fedora 29 still ships a Python 2 binary, but some of Ceph's build
dependencies are only available in py3 versions there. In other
words, from F29 on, it is no longer possible to do a py2 Ceph build
on Fedora, even if a python2 binary exists on the system.
If that were not enough, the Python 2 that ships with Fedora 29 is
linked against a non-compatible version of OpenSSL.
Before this commit, install-deps.sh was overriding the spec file's
Python build setting based on the presence or absence of a python2
binary. As the bug cited below indicates, this was not a good idea.
It's better for the spec file to be explicit about which OS versions
are py2 and which are py3, and just stick to that.
Fixes: http://tracker.ceph.com/issues/37301
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
Signed-off-by: Nathan Cutler <ncutler@suse.com>
Currently /var/lib/ceph/bootstrap-rbd-mirror is absent, which means we
need to create it manually in order to pool the
client.bootstrap-rbd-mirror key.
Signed-off-by: Sébastien Han <seb@redhat.com>
be more explicit on what we are packaging. because only
libceph-common.so.${soversion} will be packaged, since libceph-common.so
won't be installed by cmake anymore.
Signed-off-by: Kefu Chai <kchai@redhat.com>
Due to ABI breakage in libtcmalloc.so.4 we need to specify the minimum
version to be used at runtime to be greater than or equal to the version
used at build time.
Fixes: http://tracker.ceph.com/issues/36508
Signed-off-by: Brad Hubbard <bhubbard@redhat.com>
Currently, we do pass the hardened CFLAGS and CPPFLAGS when building the
code. However, we do not pass the hardened flags to the linker. This
means that the binaries are linked without the options like -Wl,-z,now.
As a result, we do not fully harden the binaries that we build.
This commit fixes this by passing the RPM_LD_FLAGS to the linker so the
builds are linked with the properly hardened flags.
Fixes: http://tracker.ceph.com/issues/36316
Signed-off-by: Boris Ranto <branto@redhat.com>
make sure we only build with the higher version of gperftools on
distros where both 2.4 and 2.6.1 are packaged. see
https://git.centos.org/summary/rpms!gperftools.git . at the time of
writing, gperftools 2.6.1 is packaged for CentOS/RHEL 7, if gperftools
(>= 2.4) is required by Ceph, and user already has this version
installed, when new Ceph packages are installed, the updated gperftools
2.6.1 version won't be installed as a dependency. when launching
Ceph compiled with tcmalloc enabled, we will have
symbol lookup error: ceph-osd: undefined symbol: _ZdaPvm
so, by bumping up the required version of gperftools, the updated
gperftools will be installed.
see https://software.opensuse.org/package/gperftools, openSUSE/SLE offer
2.5. so they are safe at this moment.
Fixes: http://tracker.ceph.com/issues/35969
Signed-off-by: Kefu Chai <kchai@redhat.com>
6dd06b0c34 introduced RPM packaging of cephfs-shell
This initial packaging was Fedora-only, but colorama and cmd2 *are* packaged
for both openSUSE and SLE.
Note: there is no py2-compatible version of cephfs-shell.
Signed-off-by: Nathan Cutler <ncutler@suse.com>
* refs/pull/23240/head:
qa/suites/rados, qa/workunits/rados: Add suite/workunit for ceph-crash
add ceph-crash service
common/options: enable mgr 'crash' module by default
global/signal_handler: add 'done' file to signal crashdump is ready
Reviewed-by: Sage Weil <sage@redhat.com>
ceph-crash runs from systemd and watches /var/lib/ceph/crash
for crashdumps, posting them to the mgrs using the mgr's
crash plugin
Signed-off-by: Dan Mick <dan.mick@redhat.com>
because RHEL/CentOS 7 only offers fmt-devel 3.0.2, while seastar
requires >= 4.0.0, < 5.0.0, and on openSUSE Leap 15, we have
libfmt-devel 5.x.
Signed-off-by: Kefu Chai <kchai@redhat.com>
1. cryptopp-devel was moved to the distro-specific section by
aeb974b913, then
96196e9d77 reintroduced it in the
non-distro-specific section, breaking install-deps.sh for SUSE
2. fmt-devel is called libfmt-devel on SUSE
Fixes: install-deps.sh on SUSE
Signed-off-by: Nathan Cutler <ncutler@suse.com>
python-ceph-argparse is required by ceph_volume_client.py. hence we do
need list it as a dependency of python-cephfs.
Fixes: http://tracker.ceph.com/issues/24919
Signed-off-by: Kefu Chai <kchai@redhat.com>
This reverts commit c0b7aab381.
python3-ceph-argparse is required by ceph_volume_client.py. hence we do
need it as a dependency of python3-cephfs.
Signed-off-by: Kefu Chai <kchai@redhat.com>
in `cephfs.pyx` we `cimport rados`, and in
LibCephFs.create_with_rados(), Rados.cluster is accesssed without GIL,
so we need to import the rados module for cephfs to ensure that it's
safe to access this attribute without GIL.
dh_python2 and dh_python3 cannot fill ${python:Depends} and
${python3:Depends} with this dependency, so we need to set it
explicitly.
Fixes: http://tracker.ceph.com/issues/24918
Signed-off-by: Kefu Chai <kchai@redhat.com>
