Re: Ceph Mimic on Debian 9 Stretch

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

 



Hi Fabian,

On Wed, 13 Jun 2018, Fabian Grünbichler wrote:
> On Mon, Jun 04, 2018 at 06:39:08PM +0000, Sage Weil wrote:
> > [adding ceph-maintainers]
> 
> [and ceph-devel]
> 
> > 
> > On Mon, 4 Jun 2018, Charles Alva wrote:
> > > Hi Guys,
> > > 
> > > When will the Ceph Mimic packages for Debian Stretch released? I could not
> > > find the packages even after changing the sources.list.
> > 
> > The problem is that we're now using c++17, which requires a newer gcc 
> > than stretch or jessie provide, and Debian does not provide backports of 
> > the newer gcc packages.  We currently can't build the latest Ceph for 
> > those releases.
> 
> IMHO this is backwards. if you want to support distro X you should take
> care to not need toolchain features that are not included in distro X.

Well, I thought we did.  When we were making the C++17 decision we 
verified that we could do builds on Ubuntu and CentOS using a newer 
compiler toolchain.  My assumption was that since both of these distros 
had backports that pretty much everyone did.  Clearly I was wrong.

> [...]
> effectively this means the current Xenial builds are about as safe and
> production-ready as doing your own gcc backports for Stretch - i.e., not
> very.

I missed this nuance as well.

> > We'd love to build for stretch, but until there is a newer gcc for that 
> > distro it's not possible.  We could build packages for 'testing', but I'm 
> > not sure if those will be usable on stretch.
> 
> saying you'd love to build for a distro, while effectively making sure a
> build according to that distro's release policies is impossible without
> major effort by someone else does strike me as a bit of a hollow
> statement. in the end this is a further nail in the coffin of upstream
> support for the Debian(-based) distros, with only the latest (1.5 months
> old!) Ubuntu LTS being properly supported.

I think we need to be clear about the use of the term "support" here.  I 
was careful to say we'd like to *build* for Debian, but I'm not sure what 
organizations out there are offering formal *support* for any of the 
ceph.com packages (in the sense of providing technical support for bug 
escalations or any guarantees around stability etc).  This incident is 
perhaps an indication that those organizations should become more involved 
in the upstream development and decision-making process.

> I hope we find some way to support Mimic+ for Stretch without requiring
> a backport of gcc-7+, although it unfortunately seems unlikely at this
> point.

It is not practical to reverse the dependency on C++17.  A lot of C++17 
code has already made it into the tree, and the use of projects that 
require it (notably Seastar) is a *big* part of our plans going forward to 
improve performance on flash devices.

Again, I would still like to provide these builds.  If the requirement to 
do so is a high level of assurance that the backported compiler used is 
solid and the resulting builds have been tested, then that will take some 
additional effort--at a minimum, adding stretch to the set of OSes that we 
test in the sepia lab.  This is probably not that much work, TBH, but 
does require someone who cares to become engaged in the testing effort.  
There are daily and weekly standups you can join, and of course 
discussions take place on IRC (#sepia) and over email (ceph-devel and 
ceph-maintainers).

The immediate practical issue/question, IIRC, is simply for someone to 
verify whether a build using the debian testing version of gcc will 
produce a package that can be installed without additional dependencies on 
stretch.  Or maybe this question was already answered and a backport is 
definitely needed.  Regardless, it seems to me like the compiler version 
in testing would be an appropriate choice for a gcc backport to stretch.

One final note: we didn't move to C++17 for no reason: we did so because 
it is difficult to move the Ceph project forward without taking advantage 
of the new language features.  It took us a *long* time to get to C++11 
because of paranoia around distro support, but we finally realized that we 
could move more quickly if we rely on the compiler backports available in 
most distros (tho clearly not as many as we thought!).  I wish we had 
moved much sooner with C++11, and I still think this was the right 
decision with respect to C++17.  I'm sorry that this has caused problems 
with Debian, but I think with your (or someone's) help we can mitigate the 
damage with testing.

Thanks!
sage
_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

[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