Apologies for resurrecting this thread, but do have a plan forward for QEMU's librados2 dependencies post-Nautilus upgrade? Do we need to create a librados2-compat RPM/DEB that has a dummy librados2 library? Right now, there isn't a functional QEMU testing environment in the lab since it will get automatically removed when Nautilus is installed. On Wed, Nov 7, 2018 at 2:48 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > On Tue, Nov 6, 2018 at 5:00 AM Jason Dillaman <jdillama@xxxxxxxxxx> wrote: > > > > FYI -- it seems like the librados3 change has caused all the QEMU > > teuthology tests to fail since now qemu gets uninstalled when the > > newest version of Ceph is installed [1] (due to its dependency on > > librados2): > > > Jason, thanks and sorry for the inconvenience . the change to remove > the conflict/replaces on librados2 is still under testing. see > https://github.com/ceph/ceph/pull/24896/commits/ce2d8bd2d53a1f8c5b76399633667518516e234c > . i will try to fix it ASAP. > > > > > 2018-11-05T23:53:42.206 > > INFO:teuthology.orchestra.run.smithi074:Running: u'sudo > > DEBIAN_FRONTEND=noninteractive apt-get -y --force-yes -o > > Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" > > install ceph-mds=14.0.0-4803-gb738aa2-1bionic > > radosgw=14.0.0-4803-gb738aa2-1bionic > > rbd-fuse=14.0.0-4803-gb738aa2-1bionic > > librbd1=14.0.0-4803-gb738aa2-1bionic > > ceph-fuse=14.0.0-4803-gb738aa2-1bionic > > python-ceph=14.0.0-4803-gb738aa2-1bionic > > ceph-mgr=14.0.0-4803-gb738aa2-1bionic > > ceph-common=14.0.0-4803-gb738aa2-1bionic > > ceph=14.0.0-4803-gb738aa2-1bionic > > libcephfs-dev=14.0.0-4803-gb738aa2-1bionic > > ceph-test=14.0.0-4803-gb738aa2-1bionic > > librados3=14.0.0-4803-gb738aa2-1bionic > > libcephfs-java=14.0.0-4803-gb738aa2-1bionic > > libcephfs2=14.0.0-4803-gb738aa2-1bionic > > libcephfs-jni=14.0.0-4803-gb738aa2-1bionic' > > ... > > 2018-11-05T23:53:42.626 > > INFO:teuthology.orchestra.run.smithi079.stdout:The following packages > > will be REMOVED: > > 2018-11-05T23:53:42.627 > > INFO:teuthology.orchestra.run.smithi079.stdout: librados2 > > qemu-block-extra qemu-system-common qemu-system-x86 qemu-utils > > 2018-11-05T23:53:42.627 > > INFO:teuthology.orchestra.run.smithi079.stdout:The following NEW > > packages will be installed: > > 2018-11-05T23:53:42.627 > > INFO:teuthology.orchestra.run.smithi079.stdout: ceph ceph-base > > ceph-common ceph-fuse ceph-mds ceph-mgr ceph-mon ceph-osd > > 2018-11-05T23:53:42.628 > > INFO:teuthology.orchestra.run.smithi079.stdout: ceph-test curl > > formencode-i18n jq libcephfs-dev libcephfs-java libcephfs-jni > > 2018-11-05T23:53:42.628 > > INFO:teuthology.orchestra.run.smithi079.stdout: libcephfs2 libcurl4 > > libjq1 libjs-sphinxdoc libjs-underscore libleveldb1v5 > > 2018-11-05T23:53:42.628 > > INFO:teuthology.orchestra.run.smithi079.stdout: liblttng-ust0 > > liboath0 libonig4 librados3 libradospp1 libradosstriper1 > > > > http://pulpito.ceph.com/jdillaman-2018-11-05_18:12:54-rbd-wip-jd-testing-distro-basic-smithi/ > > On Tue, Oct 30, 2018 at 11:07 AM kefu chai <tchaikov@xxxxxxxxx> wrote: > > > > > > On Tue, Oct 30, 2018 at 2:41 AM Jeff Layton <jlayton@xxxxxxxxxx> wrote: > > > > > > > > On Mon, 2018-10-29 at 10:38 -0700, Gregory Farnum wrote: > > > > > On Mon, Oct 29, 2018 at 6:50 AM Sage Weil <sweil@xxxxxxxxxx> wrote: > > > > > > On Tue, 23 Oct 2018, kefu chai wrote: > > > > > > > any concerns? > > > > > > > > > > > > I seem to remember from the last time we talked about this that we were > > > > > > worried about having to build and ship librados2 in addition to librados3 > > > > > > (e.g., in nautilus), vs just maintaining luminous/mimic long enough for > > > > > > packages to transition to the v3 SONAME. I can't remember exactly why > > > > > > though...? > > > > > > > > > > Well it sounds like Wido explained that; some librbd users are > > > > > directly accessing librados functions as part of initial setup (for > > > > > some reason...): > > > > > > > > > > On Mon, Oct 29, 2018 at 4:48 AM Wido den Hollander <wido@xxxxxxxx> wrote: > > > > > > Qemu and libvirt both mainly use librbd, but they use a very small part > > > > > > of librados to initiate the connection and set configuration values. > > > > > > > > > > Now it may be that the C API doesn't actually change, so those > > > > > projects won't need to change their source code, but they will need to > > > > > update to point at the librados3 library rather than the librados2 > > > > > one, right? > > > > > -Greg > > > > > > > > We've been naming -devel packages without the major library version > > > > number in them, so as long as the C API functions that the project is > > > > using haven't changed, bumping the soname shouldn't require any > > > > changes, period. Projects with sane build configuration will just link > > > > against whichever version is present at build time. > > > > > > > > That said, things like build scripts that install certain pacakges may > > > > need updating if they are pulling in (e.g.) librados2 explicitly. > > > > > > thank you Jeff! i am actually s/librados2/librados3/ and/or > > > s/librados-devel/libradospp-devel/ in some of our qa scripts =). > > > probably i will miss some of them, but will fix them once they > > > surface. > > > > > > > -- > > > > Jeff Layton <jlayton@xxxxxxxxxx> > > > > > > > > > > > > > -- > > > Regards > > > Kefu Chai > > > > > > > > -- > > Jason > > > > -- > Regards > Kefu Chai -- Jason
