+ ceph-user for more inputs in hope to get more inputs from librados and librbd 's C++ interfaces. On Wed, Oct 24, 2018 at 1:34 AM Jason Dillaman <jdillama@xxxxxxxxxx> wrote: > > On Tue, Oct 23, 2018 at 11:38 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > > > we plan to introduce some non-backward-compatible changes[0] in > > librados in the coming nautilus release. to be specific, these changes > > are not API/ABI compatible with existing librados2. so i think it's > > time to bump up the soversion of librados from 2 to 3. as bumping up > > soversion is a major change in the life cycle of a library, i think we > > will expect following changes: > > > > 0. piggyback more non-backward-compatible changes listed in > > https://pad.ceph.com/p/librados3 in this change, so we can have less > > soversion bump up. > > 1. in nautilus, librados3 and librados3-{dev,devel} will be packaged > > instead, librados2* will be maintained in LTS releases. > > Just note that this is going to have a potential ripple effect on > non-Ceph packages that use librbd1 if they are also (incorrectly) > specifying a dependency on librados2 [1]. > > > 2. we will have separated C++ and C API librados after this change. so > > librados3 will only provide the C API of librados, the C++ API will be > > offered by libradospp, (the name may vary if you suggest a better > > one). and they will be versioned and packaged separately, and will not > > depend on each other. a PR is posted to do this, see [1] > > Do we have a good idea and/or list about who uses the librados C++ > API? I seem to vaguely recall perhaps one or so external users. If > librgw/RGW and librbd eventually switch over to something similar to > the API being worked on by Adam [2] and if there are no external users > of the C++ API, should we take the time now to kill all the legacy C++ > API methods prior to the release of Nautilus? > > > 3. in order to enable user to install librados2 and librados3 at the > > same time, libceph-common.so will be versioned since nautilus. > > libceph-common.so is an internal shared library used by ceph > > libraries, tools and daemons. librados depends on libceph-common. > > 4. some executables/libraries' dependencies will be updated > > accordingly . for instance, librbd will depend on libradospp. > > > > if this model works fine, i guess we probably could expand it to librbd. > > It would be interesting to get a feel for who (if anyone) actually > uses the librbd C++ interface before heading down that path. AFAIK, > it's probably really only the rbd CLI tool -- and that's basically for > the convenience of C++-style containers. If it's not being used by > anyone else, perhaps our time could be better spent deprecating the > library for external use to focus our development and maintanence > efforts on the C (and wrapped-C) interface. > > > any concerns? > > > > BTW, we discussed this topic last year the same time, see > > https://www.spinics.net/lists/ceph-devel/msg38830.html =) > > > > --- > > [0] for instance, https://github.com/ceph/ceph/pull/24498 > > [1] https://github.com/ceph/ceph/pull/24616 > > [2] a trello card for librados3: > > https://trello.com/c/pmRkawYV/165-librados3-api-update-cleanup > > > > -- > > Regards > > Kefu Chai > > [1] https://src.fedoraproject.org/rpms/qemu/blob/f29/f/qemu.spec#_192 > [2] https://github.com/ceph/ceph/pull/16715 > > -- > Jason -- Regards Kefu Chai
