Re: CEPH Version choice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 5/15/23 13:03, Daniel Baumann wrote:
On 5/15/23 12:11, Frank Schilder wrote:
Because more often than not it isn't.
Sadly, I have to agree. We basically gave up after luminous, where every
update (on our test-ceph cluster) was a major pain. Until then, we
always updated after one week of a new release.

Any chance you could highlight the major pain points?  I've heard a couple of stories (especially related to swap and buffered IO), but it would be good to know what the others have been.



To add one more point..

The current Ceph version (17.x) will not be included in the upcoming
Debian 12 release to be released later this summer. This hasn't been a
problem in the past, because we just built our own backports and
everything was fine.

Nowadays, Ceph 17 doesn't even build on Debian unstable/testing because
some libraries (mostly fmtlib and others) are too new (sic!), so.. we'll
be staying with Ceph 16 on Debian 12 until we'll trash the hardware.


This is getting off-topic, but I wanted to make sure you got a quick reply because it's an important topic.  Sadly this one isn't our fault, isn't limited to Debian, and doesn't only affect Ceph. There are actually two separate problems affecting bookworm (and other very updated distros):


LibFMT:  Any OS using FMT 9.0+ is going to have issues due to a breaking change in the library:

https://www.spinics.net/lists/fedora-devel/msg303183.html

https://github.com/fmtlib/fmt/releases/tag/9.0.0

If you just need to compile ceph itself you can get around this by passing the flag to do_cmake.sh:

*./do_cmake.sh -DCMAKE_BUILD_TYPE=RelWithDebInfo -DWITH_FMT_HEADER_ONLY:BOOL=ON*

**

*Snappy: This is an even more irritating problem imho. Snappy 1.1.9 breaks RTTI runtime support and it's also breaking multiple applications including Ceph. *

**

*https://bugzilla.redhat.com/show_bug.cgi?id=1980614*

*https://github.com/google/snappy/pull/129*

**

*That second link includes a fix by a user and the response was:*

**

*"The project's CMake configuration reflects the way it's used in Google Chrome. This is the only configuration we can maintain ourselves. To be clear, this doesn't mean your changes are not valid -- I think you'll be able to use Snappy with the build tweaks you posted here just fine. It's just that we can't accept this change in the official repository."*

**

*I'm kind of in a ripping-out mood right now, but my inclination is to remove snappy support if google can't test it outside of how it's used in Chrome.*

**

*Mark *

**

..or in other words: it would be nice if you could more efforts into
upgrade-tests/QA as well as on releasing stuff that actually compiles on
non-RHEL/current Linux distributions.

Regards,
Daniel
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx

--
Best Regards,
Mark Nelson
Head of R&D (USA)

Clyso GmbH
p: +49 89 21552391 12
a: Loristraße 8 | 80335 München | Germany
w: https://clyso.com | e: mark.nelson@xxxxxxxxx

We are hiring: https://www.clyso.com/jobs/
_______________________________________________
ceph-users mailing list -- ceph-users@xxxxxxx
To unsubscribe send an email to ceph-users-leave@xxxxxxx




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux