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

[Alwin Antreich]

Hello Martin,

On Thu, Jan 09, 2020 at 02:23:07PM +0100, Martin Verges wrote:
> 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.
I hope this knowledge spreads (it's hardly hidden). ;)
A good point to start from is the release notes and our documentation [0].

I guess the past needs a little clarification (Debian Stretch + Mimic),
Fabian had a discussion upstream [1]. And as there was no supported way
to build available. We decided at this point to not burden our users
with an experimental build of Ceph. Which would also have changed
fundamental parts of the OS (eg. glibc).

> 
> 
> > 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.
Thanks.

> 
> 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.
I urge those users to also speak to us. If we don't know about possible
issues, then we can't help.

> 
> 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.
Proxmox VE's Ceph management is written explicitly for the
hyper-converged use case. This intent binds the management of Ceph to
the Proxmox VE clustered nodes and not to a separate Ceph cluster.

We provide packages specifically tested on Proxmox VE. And for its use
case, as Ceph client or cluster (RBD/CephFS services).

As user, using packages provided by a third party circumvents our
testing, possibly breaks usage (e.g., API/CLI changes) and in the end,
the user may be left with an installation in an unknown state.

When you use Proxmox VE as a client, the dashboard (or CLI) should not
be used.  Only due to the nature of Ceph's commands, some functionality
is working on the dashboard. For sure, this separation could be made
more visible.

I hopefully this explains, why we are currently against applying this
patch of yours.

--
Cheers,
Alwin

[0] https://pve.proxmox.com/wiki/Roadmap
    https://pve.proxmox.com/pve-docs/chapter-sysadmin.html#sysadmin_package_repositories_ceph
    https://pve.proxmox.com/pve-docs/chapter-pveceph.html

[1] http://lists.ceph.com/pipermail/ceph-users-ceph.com/2018-June/027366.html