On 10/29/18 12:42 PM, kefu chai wrote: > + 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? >> I know various users who use librados through phprados (PHP) and the rados-java (Java) bindings. Those bindings will need to be updated as well. Qemu and libvirt both mainly use librbd, but they use a very small part of librados to initiate the connection and set configuration values. >>> 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. >> Again, don't forget Qemu/KVM and libvirt who both are very heavy users of librbd Wido >>> 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 > > >
