Debian has adopted FHS 3.0 with Debian Policy Standard version 4.4.0,
and now defaults to /usr/libexec for libexecdir as well. This is
present in Ubuntu 20.04 LTS, for example.
Signed-off-by: Neal Gompa <ngompa13@gmail.com>
in 589626464d, the core modules are moved
into ceph-mgr-modules-core. but the upgrade path from older ceph-mgr was
broken by this change.
Signed-off-by: Kefu Chai <kchai@redhat.com>
ceph-mgr depends on it in the sense that these plugins are
a hard dependency of ceph-mgr. like cmake depends on cmake-data,
even if the later cannot function on its own without the former.
the reason why we need a separated package is that mgr modules
are written in python, and should be arch independent. this change
helps the downstream to understand this and help to minimize the
divergence between upstream and downstream, because distros like
debian and its derivatives encourage splitting architecture independent
data into its own package.
see
https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#architecture-independent-data
also, the python related runtime dependencies are also moved into
ceph-mgr-modules-core.
if a python dependency is shared by another ceph-mgr-* package and
ceph-mgr-modules-core. it's only added to ceph-mgr-modules-core for
simplicity and consistency. as the name of dependency might vary
on different distros, so it's tedious and error-prone to repeat
these conditons and checks.
Signed-off-by: Kefu Chai <kchai@redhat.com>
cephadm mounts `/run/lvm` into OSD containers, which only exists,
if `lvm2` is installed on the container host. Otherwise we cannot
start ceph-volume or osd containers.
Fixes: https://tracker.ceph.com/issues/43368
Signed-off-by: Sebastian Wagner <sebastian.wagner@suse.com>
as a C++ project, we should depends on g++. actually, GCC-7 is able to
support C++17. but we use C++17 features extensively, and have been
running into GCC bugs every now and then. so would be ideal if we can
use newer GCC if possible.
we've dropped the support of ubuntu/xenial. while on ubuntu/bionic, only
GCC-7.4 is available. so let's require g++ (>= 7) then.
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
When a secret and/or the mon addrs are not specified by the admin,
then mmap a MAP_SHARED buffer and spawn a child process to get that
info. For safety reasons, the child drops all capabilities other than
CAP_DAC_READ_SEARCH (to ensure that it'll be able to read the keyring,
should one be found). To achieve this, we add a new dependency on
libcap-ng.
Add a new C++ file with a single routine that will create a CephContext,
get a list of monitor addresses and scrape the keyring for a secret for
the specified cephx user.
If that info is found, then it is copied to fixed-length buffers in the
MAP_SHARED area and the child exits successfully.
The parent will then vet the returned info and copy it into the
appropriate fields if they are currently blank.
Fixes: https://tracker.ceph.com/issues/16656
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Adds a mgr module to provide integration between
Ceph and the kubernetes events API within the rook-ceph
namespace. It provides several commands to view event
status including;
ceph k8sevents list .... show all k8s related events
ceph k8sevents ceph .... show events generated from this
module
ceph k8sevents status .. show status of the tracker threads
and counts of tracked events
Events sent to kubernetes are sourced from the
a) clog: ceph healtchecks and admin commands
b) explicit checks: hosts, pools and OSD states are checked
every 'n' seconds
Signed-off-by: Paul Cuzner <pcuzner@redhat.com>
these dependencies are only used for building python-saml which is in
turn used for the SAML support. this feature is tested using
`test_sso.py` while performing dashboard tests. we do not package or
ship python-saml along with other Ceph packages. so let's move these
dependencies to the "make check" sections in ceph.spec.in and
debian/control for simplifying install-deps.sh.
Signed-off-by: Kefu Chai <kchai@redhat.com>
but we still enable it in `run-make-check.sh`
* cmake: disable SPDK by default
* run-make-check.sh: enable WITH_SPDK so at least we can ensure it
builds
* deb,rpm: add uuid-dev / libuuid-devel as a "make check" dependency
Fixes: https://tracker.ceph.com/issues/41330
Signed-off-by: Kefu Chai <kchai@redhat.com>
the dashboard requires python-routes via cherrypy/_cpdispatch.py during runtime
but the cherrypy debian package only recommends it and doesn't depend on it
Fixes: https://tracker.ceph.com/issues/24420
Signed-off-by: Paul Emmerich <paul.emmerich@croit.io>
what we need is "libnl-genl-3-dev", libnl-3-dev should be a dependency
of "libnl-genl-3-dev". the only reason we would have added it, is if
the package maintainer of "libnl-genl-3-dev" fails to do so. and
the packages of "libnl-genl-3-dev" on both debian and ubuntu just look
correct in this perspective.
so let's remove this.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* debian/: remove ceph-crimson-osd package.
* debian/control: set `CEPH_OSD_BASENAME` env variable, which
will be consumed by `ceph-osd.install`. alternatively, we could
rename crimson-osd to ceph-osd in `override_dh_auto_install`,
but let's go with this way at this moment, unless `mv` in
`override_dh_auto_install` is proved to be better.
* ceph-osd.install: replace ceph-osd with crimson-osd if
`CEPH_EXTRA_CMAKE_ARGS` has `WITH_SEASTAR` in it. this only
happens when we are packaging the "crimson" flavor packages from
jenkins.
* ceph-osd.install: `chmod +x` this file, as we need to use
`/usr/bin/dh-exec` as the interpreter of it to perform variable
substitution and install.
Signed-off-by: Kefu Chai <kchai@redhat.com>
This commit adds "patch" as an explicit build dependency. Before, the RPM
build was installing it in the build environment via some mechanism that I
don't entirely understand.
The "patch" command is used by the BuildBoost cmake module.
Fixes: http://tracker.ceph.com/issues/40175
Signed-off-by: Nathan Cutler <ncutler@suse.com>
this package is commented out using `# Crimson`. and it will be enabled
only if we are building "crimson" flavor builds.
this package depends on ceph-osd, because it'll basically be a drop-in
replacement of ceph-osd. and it shares all the dependencies of ceph-osd.
so let's just reuse ceph-osd package for now.
Signed-off-by: Kefu Chai <kchai@redhat.com>
The next patch adds netlink support to rbd-nbd. This patch just adds the
build related changes to bring in the netlink lib and test and build
against it.
Signed-off-by: Mike Christie <mchristi@redhat.com>
Instead of self-written validation methods to validate IPv4 and IPv6 addresses.
Use Python's standard library functions `ipaddress`.
Signed-off-by: Ashish Singh <assingh@redhat.com>
ceph-common depends on librados2, but ceph-immutable-object-cache only
uses librados2's C++ API, so librados2 would suffice.
rpmbuild is able to figure out the .so dependencies, and let
ceph-immutable-object-cache depend on the package which offers
librados2, but we'd better make sure immutable-object-cache is linked
against the librados2 of the same version, to ensure that librados2
offers the correct C++ symbols. as we only version the C++ API in the
librados2 after nautilus.
Signed-off-by: Kefu Chai <kchai@redhat.com>
* refs/pull/26237/head:
Revert "qa: update test_envlibrados_for_rocksdb.sh for libradospp split"
doc/librados: explicitly mention that the C++ API is not stable
ceph.spec: force use of upgrade devtoolset-gcc under RHEL 7
librados: add symbol versioning to the C++ API
librados: add symbol versioning to the C API
librados: revert librados3/libradoscc back to librados2
Reviewed-by: Kefu Chai <kchai@redhat.com>
The future goal would be to change the version for each Ceph major
release to ensure C++ applications will need to be recompiled against
the librados C++ API since we don't guarentee ABI stability.
Fixes: https://tracker.ceph.com/issues/38177
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
