Did you consider that this creates a new hard package dependency on the Ceph
libs? Do we really want this?

We might however consider enabling Fam's modules and create a new optional
package for the rbd block driver, which could then have a hard dependency on
the Ceph libs. On the other hand, we wouldn't know whether we should install
that package on an upgrade, so maybe such changes are more suitable for a
major version.

(In reply to Kevin Wolf from comment #1)
> Did you consider that this creates a new hard package dependency on the Ceph
> libs? Do we really want this?
> 

Yep, I know. IIRC, ceph runtime libraries are not that large or intrusive... they would be just "yet another lib that qemu depends on", so I don't see it as a big deal right now (but would happily discuss it further if you or anybody else disagrees)

> We might however consider enabling Fam's modules and create a new optional
> package for the rbd block driver, which could then have a hard dependency on
> the Ceph libs. On the other hand, we wouldn't know whether we should install
> that package on an upgrade, so maybe such changes are more suitable for a
> major version.

Yes, this is in the works. Fam is starting the discussions and coordination with Cole to get modular packages introduced to Fedora. Adopting it in RHEL will depend on how well it works in Fedora (specially the transition).

(In reply to Ademar Reis from comment #2)
> Yep, I know. IIRC, ceph runtime libraries are not that large or intrusive...
> they would be just "yet another lib that qemu depends on", so I don't see it
> as a big deal right now (but would happily discuss it further if you or
> anybody else disagrees)

I don't strictly disagree, but then I don't see the point of statically
building it in either. If we were to newly introduce Ceph, I think this is the
way we'd go because it would be easier, but now the work is already done and it
feels like doing additional work for making things less nice.

I'll happily consider doing the switch if we ever run into merge conflicts in
the rbd driver (which seems unlikely as the code didn't change in a long time
upstream), but until then, what would the advantage be?

(In reply to Kevin Wolf from comment #3)
> (In reply to Ademar Reis from comment #2)
> > Yep, I know. IIRC, ceph runtime libraries are not that large or intrusive...
> > they would be just "yet another lib that qemu depends on", so I don't see it
> > as a big deal right now (but would happily discuss it further if you or
> > anybody else disagrees)
> 
> I don't strictly disagree, but then I don't see the point of statically
> building it in either. If we were to newly introduce Ceph, I think this is
> the
> way we'd go because it would be easier, but now the work is already done and
> it
> feels like doing additional work for making things less nice.
> 
> I'll happily consider doing the switch if we ever run into merge conflicts in
> the rbd driver (which seems unlikely as the code didn't change in a long time
> upstream), but until then, what would the advantage be?

I think there are two main reasons:

 - We want it to work out-of-the-box. The way it is now, users need to install ceph conciously before they see support enabled in QEMU.

 - The current implementation is "unsafe": we never know the source of the librbd packages installed by the user as long as there's a symlink for QEMU to use. Now that they're going to be provided in RHEL, we should protect ourselves via rpm dependencies: users running CEPH from 3rd parties should not be supported.

I record responding to at least one support request via Bugzilla in the past because a user was confuse by the current behavior, so I guess there are many other hitting the frontline. I'm sure GSS will welcome this change.

(In reply to Ademar Reis from comment #4)
> 
> I think there are two main reasons:
> 
>  - We want it to work out-of-the-box. The way it is now, users need to
> install ceph conciously before they see support enabled in QEMU.
> 

Notice this is different than a package split where we have "qemu-kvm-ceph" alongside others such as "qemu-kvm-gluster", etc. My point above is that right now, ceph is special and requires something unexpected to be done before it works.

Kevin: we are newly introducing ceph (bz1149114) although client-side only. Hence, we can link dynamically, not statically, against those.


all: What is the final decision, here? Will we build dynamically against librbd or not? I'd like to know that because we do not create the qemu symlink in the current native ceph-common builds and we should probably do that in case we are not linking librbd dynamically.

(In reply to Boris Ranto from comment #6)
> Kevin: we are newly introducing ceph (bz1149114) although client-side only.
> Hence, we can link dynamically, not statically, against those.
> 
> 
> all: What is the final decision, here? Will we build dynamically against
> librbd or not? I'd like to know that because we do not create the qemu
> symlink in the current native ceph-common builds and we should probably do
> that in case we are not linking librbd dynamically.

I discussed this with Kevin and we'll indeed build dynamically. We're just waiting for the ceph package(s) to arrive before we push the patch to qemu-kvm.

Thanks.

(In reply to Ademar Reis from comment #7)
> (In reply to Boris Ranto from comment #6)
> > Kevin: we are newly introducing ceph (bz1149114) although client-side only.
> > Hence, we can link dynamically, not statically, against those.
> > 
> > 
> > all: What is the final decision, here? Will we build dynamically against
> > librbd or not? I'd like to know that because we do not create the qemu
> > symlink in the current native ceph-common builds and we should probably do
> > that in case we are not linking librbd dynamically.
> 
> I discussed this with Kevin and we'll indeed build dynamically. We're just
> waiting for the ceph package(s) to arrive before we push the patch to
> qemu-kvm.

Err... just to clarify: by "build dynamically", I mean link at build time. In other words: no symlink anymore, ceph libraries will have to be present in the build environment and the qemu rpm package will require the respective ceph library packages.

Great, just one more thing: we will probably split the ceph-devel package to librbd1-devel and librados2-devel to accommodate the fact that we are not shipping cephfs bits in RHEL 7.1 so it would be nice if you could put librbd1-devel to your build requirements and not ceph-devel (so that we won't have to deal with ceph-devel-compat right from the beginning).

I'll let you know what the actual layout is once the decision is final.

Ok, so we've decided to split the ceph-devel packages into librados2-devel and librbd1-devel so please use these -devel packages for build dependencies.

See this brew task for full layout:

https://brewweb.devel.redhat.com/taskinfo?taskID=8085393

btw: ceph is enabled only on x86_64 architecture.

Just to give a short update here: I have patches ready for this. However, the
build currently still fails because librados2-devel apparently isn't available
yet, even though Boris said it should be. Jeff Nelson is going to raise a
ticket with rel-eng.

To be explicit, when a user installs the qemu rpm package it will now also pull in the ceph-common, librbd, librados and python-ceph packages as dependencies? Is that correct?

Fix included in qemu-kvm-1.5.3-83.el7

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0349.html