Yes. Quincy doesn't support leveldb anymore. See https://docs.ceph.com/en/quincy/releases/quincy/#upgrading-from-octopus-or-pacific
You can show this in post_upgrade().
Git Clone URL: | https://aur.archlinux.org/ceph.git (read-only, click to copy) |
---|---|
Package Base: | ceph |
Description: | Ceph Storage cluster RADOS Object Gateway daemon, for serving RESTful traffic |
Upstream URL: | https://ceph.com/ |
Licenses: | GPL-2.0-or-later OR LGPL-2.1-or-later OR LGPL-3.0-or-later |
Submitter: | foxxx0 |
Maintainer: | pbazaah |
Last Packager: | pbazaah |
Votes: | 7 |
Popularity: | 0.144776 |
First Submitted: | 2022-08-08 09:09 (UTC) |
Last Updated: | 2025-02-13 18:29 (UTC) |
« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 11 12 Next › Last »
Yes. Quincy doesn't support leveldb anymore. See https://docs.ceph.com/en/quincy/releases/quincy/#upgrading-from-octopus-or-pacific
You can show this in post_upgrade().
So, I'm quite likely to release 17.2.5-1 this weekend.
I did hit one strange issue during tests (see below) but both initializing a new cluster, and upgrading from v16 work.
On my v16 upgrade, I encountered a segfault in a mon, due to using leveldb
as a kv_backend, which has been deprecated since at least Jewel and is not supported in Quincy.
I have no idea why, the whole test is scripted so I didn't run something weird on one of them.
Regardless, I strongly encourage anyone that runs a cluster to follow the below instructions before you start upgrading monitors.
mon
s use kv_backend rocksdbDuring testing I encountered a mon that was using leveldb
instead of rocksdb
. This is super weird, as leveldb was deprecated back in v10... and this test cluster was installed with v15... so WTF.
cat /var/lib/ceph/mon/ceph-$(hostname -s)/kv_backend
This should report: rocksdb
.
If it instead reports leveldb
you need to run the following:
(
# These assume you name your mons after your hostnames. If not, adjust accordingly
mID=$(hostname -s)
SERVICE="ceph-mon@${mID}.service"
MONMAP=$(mktemp monmap.${mID}.XXXXX)
systemctl stop ${SERVICE} && sleep 2
ceph mon getmap -o ${MONMAP}
mv /var/lib/ceph/mon/ceph-${mID} /var/lib/ceph/mon/ceph-${mID}.bak
ceph-mon -i ${mID} --mkfs --monmap ${MONMAP} --keyring /var/lib/ceph/mon/ceph-${mID}.bak/keyring
chown -R ceph:ceph /var/lib/ceph/mon/ceph-${mID}
systemctl start ${SERVICE}
)
Once you confirm that:
kv_backend
now reports rocksdb
You can remove the backup monmap:
rm -rf /var/lib/ceph/mon/ceph-$(hostname -s).bak
I've got what is likely to be the 17.2.5 release locked down, including enabling AQMP and kafka integrations.
This is also the first release (maybe ever, for Archlinux?) that will include working cython bindings for rados,rbd,cephfs libs, and the first release with fully passing make check
tests -- minus a couple that were disabled (wants sudo, docker, etc).
My only concern remaining is that with python 3.11 released, I'll need to rebuild binaries soonish.
Got my first full green v17.2.4 build this evening!
cython issues fixed, tests (mostly) working -- got one racy python test suite I CBA to fix.
I'm running a few tests around enabling rados gateway AQMP and Kafka features, but regardless of how that turns out, I need to start working on a 17.2.5 build now.
I have a working v17.2.4 build. However:
So there still is some work to be done before I'm ready to release it.
I encountered installation problems when yay attempts to install https://github.com/ceph/teuthology.git because it's trying to checkout the master branch while the project on github appears to have replaced the master by main.
I'm not aware how I would be able to fix that myself.
The error message is: =================================== log end ==================================== ERROR: could not install deps [git+https://github.com/ceph/teuthology.git@master#egg=teuthology[coverage,orchestra,test], nose]; v = InvocationError("~/.cache/yay/ceph/src/ceph-16.2.10/qa/.tox/import-tasks/bin/python -m pip install 'git+https://github.com/ceph/teuthology.git@master#egg=teuthology[coverage,orchestra,test]' nose", 1) _____ summary ______ py3: commands succeeded ERROR: flake8: commands failed ERROR: import-tasks: could not install deps [git+https://github.com/ceph/teuthology.git@master#egg=teuthology[coverage,orchestra,test], nose]; v = InvocationError("~/.cache/yay/ceph/src/ceph-16.2.10/qa/.tox/import-tasks/bin/python -m pip install 'git+https://github.com/ceph/teuthology.git@master#egg=teuthology[coverage,orchestra,test]' nose", 1)
So I discovered some failing cython bits in the CMake install. I'm not going to block releasing 16.2.10 on these though, as they are mostly part of the python API .
There may be some bits of the ceph CLI that also break because of this, but I haven't found them yet.
I'll work on addressing this either as a pkgrel increment, or as part of the push to v17
@regulator
I believe you are correct. Nothing inside the normal repos should depend on ceph anymore, however you may still have dependencies from other AUR packages.
Hi guys, Am I correct that ceph/ceph-libs is no longer required in (many) cases?
On my system it say nothing depends on ceph-libs anymore. I think it's been phased out as a dependency for samba, for example
freeage, please do not flag packages out-of-date due to issues with the package. That is for reporting new releases or changes that are required to get the package to build. Also please use English when flagging packages or making requests.
Pinned Comments
pbazaah commented on 2022-10-05 13:03 (UTC) (edited on 2022-10-05 13:03 (UTC) by pbazaah)
For future commenters:
TLDR:
https://aur.archlinux.org/pkgbase/ceph | From source build (slow)
https://aur.archlinux.org/pkgbase/ceph-bin | Pre-built binaries (fast)
Unlike the original community version, this repo builds ceph from source. Ceph is a large, complicated project so this takes several hours on a good build server.
To get a similar experience to how community/ceph worked (pre-built binaries) use ceph-bin instead.