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
