librdkafka submodule
Vendors librdkafka v2.12.1 as a submodule (default) and teaches the
notification teuthology task to set up Kafka 4.x KRaft brokers. The
distro-shipped librdkafka 1.6.1 cannot SCRAM-auth against Kafka 4.x
brokers (#75900); the bundled version fixes that. Build with
WITH_SYSTEM_RDKAFKA=ON to opt back into the distro library (floor 2.6.1).
follwinf changes needed with teh submodule:
* build kafka_stub only in case of system librdkafka
* use the same header location in submodule and system
* supress compilation warning to avoid -WError issues
2.12.1 matches Fedora(44)'s current librdkafka-devel, so the vendored copy
tracks a version that distro packagers have already vetted rather than
whichever release happens to be latest upstream.
The teuthology version matrix picks one of {3.9.2, 4.1, 4.2, 4.3} per run.
3.9.2 covers the last Zookeeper-based release for the migration cohort.
4.1/4.2/4.3 track Apache's current three supported minor lines and are
resolved to the latest patch at test time via dlcdn.apache.org/kafka/, so
new patches within a supported minor need no PR update. A new minor line
(4.4) requires renaming one YAML.
* new java version (17) is needed for kafka 4.2 and up (we wil use it on
all version)
* kerberos task need to run before the kafka install task
After pulling this branch, fetch the new submodule:
git submodule update --init src/librdkafka
Fixes: https://tracker.ceph.com/issues/77336
Signed-off-by: ShreeJejurikar <shreemj8@gmail.com>
Co-authored-by: Yuval Lifshitz <ylifshit@ibm.com>
When building with DWZ enabled, the debian packaging fails with:
```
dh_dwz: error: Aborting due to earlier error
```
Running the dwz command manually reveals the root cause:
```
$ dwz -mdebian/ceph-osd-crimson/usr/lib/debug/.dwz/x86_64-linux-gnu/ceph-osd-crimson.debug \
-M/usr/lib/debug/.dwz/x86_64-linux-gnu/ceph-osd-crimson.debug -- \
debian/ceph-osd-crimson/usr/bin/ceph-osd-crimson \
debian/ceph-osd-crimson/usr/bin/crimson-store-nbd
dwz: debian/ceph-osd-crimson/usr/bin/ceph-osd-crimson: Too many DIEs, not optimizing
dwz: Too few files for multifile optimization
```
The dwz tool has a limit on the number of DWARF DIEs (Debug Information
Entries) it can process. The ceph-osd-crimson binary, being a large C++
executable with extensive template usage, exceeds this limit, causing
dwz to exit with status 1 and fail the build.
This change excludes only ceph-osd-crimson from dwz processing using
the -X flag, allowing other binaries in the package to still benefit
from DWARF compression while avoiding the build failure.
Please note, we always disable DWZ in ceph-build's ceph-dev-pipeline.
Fixes: https://tracker.ceph.com/issues/78303
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
The mgr module install rule already excluded tests/*, but that glob only
dropped the files inside tests/ and left an empty tests/ directory in the
installed tree. The ci/ directories, which hold Dockerfiles, e2e test
scripts, and cluster specs used only for upstream CI pipelines, were not
excluded at all and were shipped by ceph-mgr-dashboard and ceph-mgr-rook.
Change the install pattern from tests/* to tests so the whole directory
is pruned, and add a ci pattern. Both patterns live in the exclude list
shared by every mgr module install rule (the module list, dashboard, and
rook), so this covers all of them in one place.
This supersedes the per-package excludes added in 8a2e0eb2fc and
d74b88500b, so drop them from ceph.spec.in and debian/rules.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
The ceph-mgr-dashboard and ceph-mgr-rook packages install their entire
mgr module directory, which includes a ci/ subdirectory containing
Dockerfiles, e2e test scripts, and cluster specs used only for upstream
CI pipelines. ceph-mgr-cephadm similarly ships a tests/ directory with
Python unit tests. These files have no runtime purpose on a deployed
system and should not be shipped in the binary packages.
Exclude mgr/cephadm/tests, mgr/dashboard/ci, and mgr/rook/ci via
dh_install --exclude.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
override_dh_strip enumerates each binary package explicitly. It was not
updated when ceph-osd was split into the ceph-osd-classic and
ceph-osd-crimson implementation packages, so the OSD binaries in those
two packages are shipped unstripped (ceph-osd-crimson installs at ~4.6
GiB) and their -dbg packages are left empty.
Add the missing dh_strip invocations so the OSD binaries are stripped
and their debug symbols land in the corresponding -dbg packages, as is
already done for every other binary package.
Fixes: a37b5b5bde
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Add libjerasure-dev to Build-Depends and enable WITH_SYSTEM_JERASURE
so that the Debian package builds ec_jerasure and ec_shec plugins
against the distribution-provided libraries instead of the vendored
copies.
libjerasure-dev pulls in libgf-complete-dev, so both libraries are
covered by a single build dependency.
Add libjerasure2 to ceph-base's Depends for the runtime shared
libraries. libjerasure2 in turn depends on libgf-complete1t64.
The explicit dependency is needed because dh_shlibdeps excludes
erasure-code plugins from automatic dependency scanning (they are
loaded via dlopen at runtime).
The distro-packaged jerasure and gf-complete are from the same
upstream git snapshots (2017/04/10) as ceph's vendored copies.
gf-complete source is byte-identical. jerasure differs only in
additional null-pointer checks and error handling in jerasure.c,
plus an extra galois_uninit_field() function that ceph does not use.
All function signatures ceph depends on are present and compatible.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Since commit 9b1d524839 ("debian: mark "crimson" specific deps with
"pkg.ceph.crimson""), crimson-specific build dependencies have been
gated by the Build-Profiles: <pkg.ceph.crimson> tag. However,
debian/rules was never updated to pass -DWITH_CRIMSON=ON when this
build profile is active.
This causes builds with the crimson profile enabled to fail during
dh_install, as the crimson-osd binary is never built but the install
file tries to package it:
Failed to copy 'usr/bin/crimson-osd': No such file or directory
dh_install: error: debian/ceph-crimson-osd.install returned exit code 127
Fix this by checking for pkg.ceph.crimson in DEB_BUILD_PROFILES and
enabling the CMake option accordingly, following the same pattern used
for pkg.ceph.arrow.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Previously, ceph-osd packaging had two mutually exclusive flavors that
could only be built one at a time: one with classic OSD and another
with crimson OSD. Both provided /usr/bin/ceph-osd, making them
impossible to coexist and confusing from a user perspective.
This commit restructures the packaging to enable both implementations
to coexist on the same system:
- ceph-osd: Contains shared components (systemd units, sysctl configs,
common executables like ceph-erasure-code-tool) and depends on exactly
one OSD implementation
- ceph-osd-classic: Contains the classic OSD implementation binary and
classic-specific tools
- ceph-osd-crimson: Contains the crimson OSD implementation binary and
crimson-specific tools
The two implementation packages install different sets of file, so they
don't conflict with each other anymore, and both depend on ceph-osd for
shared resources.
Changes:
Debian packaging:
- Revert e5f00d2f
- Add ceph-osd-crimson package
- Add Recommends: ceph-osd-classic to prefer classic on upgrades
- Add Replaces/Breaks for smooth upgrades from old monolithic package
- Create separate .install files for crimson and classic osd packages
Enforce exact version matching using ${binary:Version}
RPM packaging:
- Use rich dependencies for OR requirement (classic or crimson)
- Add Recommends: ceph-osd-classic for upgrade preference
Upgrade behavior:
Users upgrading from older versions will automatically get
ceph-osd-classic due to the Recommends directive, maintaining
backward compatibility. Users can explicitly choose crimson by
installing ceph-osd-crimson, which will coexist with classic.
Switching between implementations is supported via standard package
operations, with the alternatives system ensuring /usr/bin/ceph-osd
always points to the active implementation.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
Configure the Debian build to use CEPHADM_BUNDLED_DEPENDENCIES=deb,
which instructs the cephadm build script to bundle dependencies from
system-installed Debian packages instead of downloading from PyPI.
This change addresses build failures in restricted network environments
where Debian build tools do not permit internet access. By leveraging
the Debian package support added in commit 9378a2988e1, the build now
uses python3-markupsafe, python3-jinja2, and python3-yaml packages
that are already installed as build dependencies.
This approach mirrors the existing RPM packaging workflow, ensuring
consistent behavior across different distribution package formats.
Signed-off-by: Kefu Chai <k.chai@proxmox.com>
For this, the grafana dashboards are installed directly to the
containers and later, cephadm picks it up to mount the dashboards to the
grafana container
Signed-off-by: Nizamudeen A <nia@redhat.com>
It is hard for Debian/Ubuntu users to use ceph-exporter
because it is not included in any deb packages.
This commit adds a new deb package for ceph-exporter.
Fixes: https://tracker.ceph.com/issues/64095
Signed-off-by: Shinya Hayashi <shinya-hayashi@cybozu.co.jp>
In the cases of ceph-base, ceph-common, and ceph-fuse, this picks up
that these packages contain python scripts and adds a necessary
python3 dependency. In the case of ceph-volume it additionally parses
the requirements.txt file.
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
Installation of init scripts properly belongs with dh_installinit, so
move the installation there.
That means we no longer need the override of dh_auto_build, which
simplifies the rules file.
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
debian/ceph-base.docs only referred to a README that doesn't exist, so
remove it. Because dpkg-source doesn't reflect deletions from debian/
cf the orig.tar.gz, also remove the file in dh_auto_clean.
Then do away with the removal of the empty override of dh_installdocs;
the main benefit of which here is that debian/copyright gets installed
in all of the built packages, which otherwise lack a copyright
file.
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
Bring the dh compat level to 12, the most recent supported by the
oldest supported Ubuntu LTS release, 20.04. This necessitates changes
to how initscripts & systemd packaging are done.
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
Rely on the packaging system to provide a suitable g++ of version 11
or greater, and removing the corresponding hard-coding from
debian/rules, since cmake will then find a suitable version. This
seems better than trying to hard-code a particular version in
debian/rules, and Debian package building tools like e.g. sbuild will
then do the right thing.
This enables Reef (v18.2.0) to build on Debian bookworm in a clean
chroot.
Fixes: https://tracker.ceph.com/issues/61845
Signed-off-by: Matthew Vernon <mvernon@wikimedia.org>
we use dh_python3 to define subvar of ${python3:Depends} as a part
of the runtime dependencies of python3 packages, like,
ceph-mgr modules named "ceph-mgr-*", python3 bindings named "python3-*".
but unlike python3 bindings of Ceph APIs, the ceph-mgr modules are
not packaged in a typical python way. in other words, they do not
ship a "dist-info" or an "egg-info" directory. instead, we just
install the python scripts into a directory which can be found by
ceph-mgr, by default it is /usr/share/ceph/mgr/dashboard/plugins.
this does not follow the convention of python packaging or
debian packaging policies related to python package. but it
still makes to put these files in this non-convention place, as
they are not supposed to be python packages consumed by the
outer world -- they are but plugins. and should always work
with the same version of ceph-mgr.
the problem is, despite that we have ${python3:Depends} in
the "Depends" field of packages like ceph-mgr-dashboard, dh_python3
is not able to figure out the dependencies by looking at the
installed files. for instance, we have following "Depends" of
ceph-mgr-dashboard:
Depends: ceph-mgr (= 17.0.0-12481-g805d2320-1focal), python3-cherrypy3, python3-jwt, python3-bcrypt, python3-werkzeug, python3-routes
and in the debian/control file we have:
Depends: ceph-mgr (= ${binary:Version}),
python3-cherrypy3,
python3-jwt,
python3-bcrypt,
python3-werkzeug,
python3-routes,
${misc:Depends},
${python:Depends},
${shlibs:Depends},
apparently, none of the subvar is materialized to
a non-empty string.
to improve the packaging, in this change:
* drop all subvars from ceph-mgr-*, as they
are all implemented in pure python.
* add debian/ceph-mgr-*.requires, it's content
is replicated with the corresponding requirements.txt
files.
* add python3-distutils for distutils, as debian
and its derivatives package non-essetial part of
distutils into a separate package, see
https://packages.debian.org/stable/python3-distutils
* add ${python3:Depends} so dh_python3
can extract the deps from debian/ceph-mgr-*.pydist
* update the rule for "override_dh_python3" target,
so dh_python3 can pick up the dependencies specified
in .requires file.
* remove the python3 dependencies not used by
ceph-mgr from ceph-mgr's "Depends"
Signed-off-by: Kefu Chai <tchaikov@gmail.com>
change the default value of WITH_SYSTEM_UTF8PROC from ON to OFF, so that
centos/rhel users can build with the default cmake configuration. no other
WITH_SYSTEM_* variable in ceph defaults to ON, so this is consistent
with other bundled libraries like boost and rocksdb
unfortunately, this also means that users that do have system packages
must opt-in to using them with -DWITH_SYSTEM_UTF8PROC=ON
both deb and rpm builds dependended on the previous default value, so
their logic was negated to match the new default
Fixes: https://tracker.ceph.com/issues/55114
Signed-off-by: Casey Bodley <cbodley@redhat.com>
After https://github.com/ceph/ceph/pull/44059 the monitoring/prometheus
and monitoring/grafana/dashboards directories are changed to
monitoring/ceph-mixins. That broke the shared_folders in the cephadm
bootstrap script.
Changed all the instances of monitoring/prometheus and
monitoring/grafana/dashboards to monitoring/ceph-mixins
Also, renaming all the instances of prometheus_alerts.yaml to
prometheus_alerts.yml.
Fixes: https://tracker.ceph.com/issues/54176
Signed-off-by: Nizamudeen A <nia@redhat.com>
Mixin is a way to bundle dashboards, prometheus rules and alerts into
jsonnet package. Shifting to mixin will allow easier integration with
monitoring automation that some users may use.
This commit moves `/monitoring/grafana/dashboards` and
`/monitoring/prometheus` to `/monitoring/ceph-mixin`. Prometheus alerts
was also converted to Jsonnet using an automated way (from yaml to json
to jsonnet). This commit minimises any change made to the generated files
and should not change neithers the dashboards nor the Prometheus alerts.
In the future some configuration will also be added to jsonnet to add
more functionalities to the dashboards or alerts (i.e.: multi cluster).
Fixes: https://tracker.ceph.com/issues/53374
Signed-off-by: Arthur Outhenin-Chalandre <arthur.outhenin-chalandre@cern.ch>
We wish to be able to scrape SMART and NVMe metrics from OSD and MON
nodes. For this we require / recommend smartmontools and nvme-cli
dependencies for both the ceph-osd and ceph-mon packages. However, the
sudoers file (which is required for invoking `smartctl` by user 'ceph')
was installed only in the ceph-osd package. Since different packages
cannot own the same file, and because we want to be able to scrape from
every daemon, we move the dependencies and the sudoers installation to
ceph-base. For generalization, we rename:
sudoers.d/ceph-osd-smartctl -> sudoers.d/ceph-smartctl
Fixes: https://tracker.ceph.com/issues/50657
Signed-off-by: Yaarit Hatuka <yaarit@redhat.com>
as libceph_crypto* are plugins, and they are not self-contained. they
reference symbols offered by the executable loading them. dh_shlibdep
should not complain when checking them, so add them to the exclude list.
Signed-off-by: Kefu Chai <kchai@redhat.com>
change sudoers file mode to 440 to match recommended defaults.
From the sudoers man page.
> the default file mode is 0440 (read‐able by owner and group, writable
by none).
> The default mode may be changed via the “sudoers_mode” option to the
sudoers
> Plugin line in the sudo.conf(5) file.
Fixes: https://tracker.ceph.com/issues/48169
Signed-off-by: David Turner <drakonstein@gmail.com>
Current behavior (without this patch) is:
1. cephadm package installs cephadm at /usr/sbin/cephadm
2. cephadm package installs /etc/sudoers.d/cephadm
3. !!! BUT this file refers to a non-existent executable (/usr/bin/cephadm) !!!
4. the PR that introduced this sudoers file (and this discrepancy) was merged in 2019
5. nobody noticed the discrepancy until now
My conclusion: the file /etc/sudoers.d/cephadm is not needed for cephadm to
work.
Fixes: https://tracker.ceph.com/issues/47112
Signed-off-by: Nathan Cutler <ncutler@suse.com>
The rbd-nbd daemon expects the rbd-nbd_quiesce script to be installed
in the libexec directory on all distros.
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
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>
