Bug 1884661

Summary:	Rebase librados2 to 14.x
Product:	Red Hat Enterprise Linux 8	Reporter:	Giulio Fidente <gfidente>
Component:	ceph	Assignee:	Boris Ranto <branto>
Status:	CLOSED WONTFIX	QA Contact:	ceph-qe-bugs <ceph-qe-bugs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	---	CC:	berrange, branto, coli, ddepaula, gcharot, jen, jinzhao, juzhang, lyarwood, senrique, virt-maint
Target Milestone:	rc	Keywords:	FutureFeature
Target Release:	8.0	Flags:	pm-rhel: mirror+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2022-04-02 07:27:20 UTC	Type:	Feature Request
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Giulio Fidente 2020-10-02 15:32:28 UTC

To be able to use newer features available from mimic in OSP [1], we would like for the newer versions of qemu-kvm to be built against 14.x version of Ceph

Currently it seems to be built against 12.x [2]

1. https://bugzilla.redhat.com/show_bug.cgi?id=1884322
2. http://download.eng.bos.redhat.com/brewroot/vol/rhel-8/packages/qemu-kvm/5.1.0/10.module+el8.3.0+8254+568ca30d/data/logs/x86_64/installed_pkgs.log

Comment 2 John Ferlan 2020-10-06 15:21:07 UTC

Jeff - would this be a qemu build type issue or perhaps an even more generic buildroot type problem?

Comment 3 Daniel Berrangé 2020-10-06 15:35:19 UTC

This is all going to be dependant on what version of librbd is present in the build roots for RHEL-AV stream.  If the build root is correct, it shouldn't involve any code changes in QEMU. Perhaps at most a version number tweak in the RPM specfile to express a min dependency.

Comment 4 Jeff Nelson 2020-10-07 05:20:37 UTC

I think this question needs to be answered by the ceph team; as Daniel rightly points out, qemu-kvm simply builds against whatever is in the build root. Boris, is this something you can do?

Comment 5 Jason Dillaman 2020-10-14 15:02:06 UTC

Is there any specific benefit that will require build-time use of librbd1>=14.2? Unless there is a specific new librbd API method that you are attempting to use via qemu's RBD block driver, you should just be able to install the updated packages from "rhceph-4-tools-for-rhel-8-x86_64-rpms" and qemu-kvm will utilize the new librbd1 shared library at runtime. Assuming qemu-kvm v2.12, it looks like the only build-time feature that is not enabled due to the older packages is a iovec-based IO dispatch calls.

Comment 6 Giulio Fidente 2020-10-14 15:17:42 UTC

(In reply to Jason Dillaman from comment #5)
> Is there any specific benefit that will require build-time use of
> librbd1>=14.2? Unless there is a specific new librbd API method that you are
> attempting to use via qemu's RBD block driver, you should just be able to
> install the updated packages from "rhceph-4-tools-for-rhel-8-x86_64-rpms"
> and qemu-kvm will utilize the new librbd1 shared library at runtime.
> Assuming qemu-kvm v2.12, it looks like the only build-time feature that is
> not enabled due to the older packages is a iovec-based IO dispatch calls.

hi Jason, this would be to release in OpenStack some new code which only works with mimic (or newer) clients.

Assuming we do get 14.x (nautilus) RPMs installed on the compute nodes, are qemu-kvm guests seen as mimic clients even if qemu-kvm itself is built against 12.x (luminous) libs?

Comment 7 Giulio Fidente 2020-10-14 15:18:48 UTC

(In reply to Giulio Fidente from comment #6)
> hi Jason, this would be to release in OpenStack some new code which only
> works with mimic (or newer) clients.

further details about that are in BZ#1764324

Comment 8 Jason Dillaman 2020-10-14 15:28:11 UTC

(In reply to Giulio Fidente from comment #6)
> hi Jason, this would be to release in OpenStack some new code which only
> works with mimic (or newer) clients.
> 
> Assuming we do get 14.x (nautilus) RPMs installed on the compute nodes, are
> qemu-kvm guests seen as mimic clients even if qemu-kvm itself is built
> against 12.x (luminous) libs?

Yes, the qemu-kvm clients will be seen as whatever version of librados2 is installed and being used at runtime regardless of what they were built against. 

As an aside, I too would love to see RHEL 8.x upgrade its AppStream version of the Ceph client libraries to RHCS 4 since RHCS 3 is effectively EOL (on extended support only).

Comment 9 Boris Ranto 2020-10-14 15:34:42 UTC

Doing a (major) rebase in RHEL is highly non-trivial and not something we are currently looking into.

You can always check for the availability of the API calls you need and use them if they are present. I was under the impression that qemu already does this. Am i wrong there?

If this is for openstack they did even ship their own version of ceph at some point (hopefully not anymore) so it shouldn't be a problem to implement it this way for them.

They should be seen as mimic (or up) clients, you are using the shared library that is installed on the system, not the one it was compiled against. We don't use static binaries in RHEL (there might be some rare exceptions but this is not the case).

Having said that, you will also need the Ceph server to support the calls/features so you might need to implement the checks for the API calls anyway.

Comment 10 Ademar Reis 2020-10-19 17:31:18 UTC

Re-titling the BZ and setting it to the right component (ceph), as this is not something for QEMU itself to fix.

This is a request to rebase librados2 in RHEL. QEMU simply makes use of what's available there.

A separate request can be made if there's something specific that needs to be supported in QEMU (something for us to work upstream)

Comment 14 RHEL Program Management 2022-04-02 07:27:20 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.