Hi,
On 4/11/25 18:33, Stephan Hohn wrote:
Ok the two issues I see with reef release v18.2.5
and additionally, it fails to compile again with gcc-14
(debian testing/unstable, default options).
---snip---
/build/ceph-18.2.5/src/common/options.h:132:18: error: ‘static
Option::level_t Option::st
On 2/6/25 14:12, Matthew Leonard (BLOOMBERG/ 120 PARK) wrote:
> We cannot overstate our agreement on RPM and bare metal support. We also have
> no desire or interest in being forced to containers. So we also agree to the
> other on that matter.
yes - strongly seconded from us too, thanks.
Regar
Hi,
On 10/7/24 09:27, Phong Tran Thanh wrote:
> How about the disable scrub and deep-scrub
neither scrubbing nor deep-scrubbing should be disabled, it is an
integral part of ensuring data consistency and data availability.
if you disable it, ceph will not know when/if data on the disks/ssds has
On 11/15/23 19:52, Daniel Baumann wrote:
> for 18.2.0, there's only one trivial thing needed:
> https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
or, for mainline inclusion, an alternative depends would be s
On 11/15/23 19:31, Gregory Farnum wrote:
> There are versioning and dependency issues
for 18.2.0, there's only one trivial thing needed:
https://git.progress-linux.org/packages/graograman-backports-extras/ceph/commit/?id=ed59c69244ec7b81ec08f7a2d1a1f0a90e765de0
then, the packages build fine/as-i
On 11/13/23 17:14, Luke Hall wrote:
> How is it that Proxmox were able to release Debian12 packages for Quincy
> quite some time ago?
because you can, as always, just (re-)build the package yourself.
> My understanding is that they change almost nothing in their packages
> and just roll them to f
On 11/9/23 07:35, Nizamudeen A wrote:
> On the Ceph GUI, we thought it could be interesting to show information
> regarding the community events, ceph release information
like others have already said, it's not the right place to put that
information for lots of reasons.
one more to add: putting
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.
To add one more point..
The
Hi,
> * Ceph users will benefit from both approaches being supported into the future
this is rather important for us as well.
we use systemd-nspawn based containers (that act and are managed like
traditional VMs, just without the overhead).
cephadm enforces not just containers, but particular o
On 9/17/19 8:46 AM, Ronny Aasen wrote:
> Never install packages until there is an announcement.
which defeats the purpose of having the repositories in the first place.
> IIRC developers have asked if anyone have experience with running repos
> that could assist in improving the rollout of releas
10 matches
Mail list logo
