[pve-devel] [PATCH ceph 1/2] fix Ceph version string handling

[Martin Verges]

Hello Thomas,

1. we provide 14.2.5, the latest stable release available (we have upcoming
> 14.2.6 already on track)
>

Good to know, does not seem to be a knowledge that some proxmox users have
nor was it the case in the past.


> If you have custom patches which improve the experience I'd suggest
> up-streaming them to Ceph or, if they affect our management tooling for
> ceph, telling us here or at bugzilla.proxmox.com and/or naturally
> up-streaming them to PVE.
>

As a founding member of the Ceph foundation, we always provide all patches
to the Ceph upstream and as always they will be included in future releases
of Ceph or backported to older versions.

The Ceph integration from a client perspective should work as with every
> other
> "external" ceph server setup. IMO, it makes no sense to mix our management
> interface for Ceph with externally untested builds. We sync releases of
> Ceph
> on our side with releases of the management stack, that would be
> circumvented
> completely, as would be the testing of the Ceph setup.
>
> If people want to use croit that's naturally fine for us, they can use the
> croit managed ceph cluster within PVE instances as RBD or CephFS client
> just
> fine, as it is and was always the case. But, mixing croit packages with PVE
> management makes not much sense to me, I'm afraid.
>

I agree that user should stick to the versions a vendor provides, in your
case the proxmox Ceph versions. But as I already wrote, we get a lot of
proxmox users on our table that use proxmox and Ceph and some seem to have
an issue.

As my fix does not affect any proxmox functionality in a negative way, no
will it break anything. Why would you hesitate to allow users to choose the
Ceph versions of their liking? It just enables proxmox to don't break on
such versions.

--
Martin Verges
Managing director

Hint: Secure one of the last slots in the upcoming 4-day Ceph Intensive
Training at https://croit.io/training/4-days-ceph-in-depth-training.

Mobile: +49 174 9335695
E-Mail: martin.verges at croit.io
Chat: https://t.me/MartinVerges

croit GmbH, Freseniusstr. 31h, 81247 Munich
CEO: Martin Verges - VAT-ID: DE310638492
Com. register: Amtsgericht Munich HRB 231263

Web: https://croit.io
YouTube: https://goo.gl/PGE1Bx


Am Mi., 8. Jan. 2020 um 18:06 Uhr schrieb Thomas Lamprecht <
t.lamprecht at proxmox.com>:

> On 1/8/20 5:27 PM, Martin Verges wrote:
> > Thanks, I added that for the future.
>
> Thanks.
>
> > I'm more used to the much more user friendly github / gitlab.
>
> That's rather subjective, I for one, find mailing list much more enjoyable
> and
> easier for review and development work - to each their own.
>
> > However we provide our own croit Ceph debian repository that a lot of
> > people use to get newer, better Ceph versions into your software.
>
> We always follow upstream closely and are among the first to test and
> report
> issues or send fixes, especially if they affect the Debian based builds of
> Ceph and/or our integration with Ceph.
> I'm not sure how you can provided better and newer Ceph builds for Proxmox
> VE
> as:
> 1. we provide 14.2.5, the latest stable release available (we have upcoming
>    14.2.6 already on track)
> 2. we explicitly build and test Ceph on Proxmox VE, i.e., to make it as
> first
>    class enterprise ready as possible, especially if paired with PVE.
>
> If you have custom patches which improve the experience I'd suggest
> up-streaming them to Ceph or, if they affect our management tooling for
> ceph,
> telling us here or at bugzilla.proxmox.com and/or naturally up-streaming
> them
> to PVE.
>
> > One of your proxmox users came to us, complaining that our package named
> > "ceph version 14.2.5-1-g23e76c7aa6
> > (23e76c7aa6e15817ffb6741aafbc95ca99f24cbb) nautilus (stable)" breaks the
> > proxmox software.
>
> The Ceph integration from a client perspective should work as with every
> other
> "external" ceph server setup. IMO, it makes no sense to mix our management
> interface for Ceph with externally untested builds. We sync releases of
> Ceph
> on our side with releases of the management stack, that would be
> circumvented
> completely, as would be the testing of the Ceph setup.
>
> If people want to use croit that's naturally fine for us, they can use the
> croit managed ceph cluster within PVE instances as RBD or CephFS client
> just
> fine, as it is and was always the case. But, mixing croit packages with PVE
> management makes not much sense to me, I'm afraid.
>
> Thanks,
> Thomas
>
>