[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous releas

From: Peter Lieven
Subject: Re: [PATCH V2 1/7] block/rbd: bump librbd requirement to luminous release
Date: Mon, 15 Feb 2021 12:55:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

Am 15.02.21 um 12:51 schrieb Daniel P. Berrangé:
On Mon, Feb 15, 2021 at 12:45:01PM +0100, Peter Lieven wrote:
Am 15.02.21 um 12:41 schrieb Daniel P. Berrangé:
On Mon, Feb 15, 2021 at 12:32:24PM +0100, Peter Lieven wrote:
Am 15.02.21 um 11:24 schrieb Daniel P. Berrangé:
On Tue, Jan 26, 2021 at 12:25:34PM +0100, Peter Lieven wrote:
even luminous (version 12.2) is unmaintained for over 3 years now.
Bump the requirement to get rid of the ifdef'ry in the code.
We have clear rules on when we bump minimum versions, determined by
the OS platforms we target:


At this time RHEL-7 is usually the oldest platform, and it
builds with RBD 10.2.5, so we can't bump the version to 12.2.

I'm afraid this patch has to be dropped.
I have asked exactly this question before I started work on this series and got 

from Jason that he sees no problem in bumping to a release which is already 

for 3 years.
I'm afraid Jason is wrong here.  It doesn't matter what the upstream
consider the support status to be. QEMU targets what the OS vendors
ship, and they still consider this to be a supported version.

Okay, but the whole coroutine stuff would get a total mess with all the 
Doesn't seem like the write zeros code is adding much more comapred to
the ifdefs that already exist...

Yes, I don't like it as well, but write zeroes support was only added in 
Nautilus (14.x) and the thick provisioning

that Jason asked me to add came only with Octopus (15.x).

Would it be an option to make a big ifdef in the rbd driver? One with old code for 
< 12.0.0 and one

with new code for >= 12.0.0?
..but I don't have a strong opinion on that, since I'm not maintaining this

BTW, we will be free to drop RHEL-7 in the next development cycle of
QEMU, starting after the forthcoming 6.0.0 release is out, as it will
fall out of our OS support matrix.

Thanks for that hint. I would say lets hold this series back until Qemu 6.1.

Where can I find the OS support matrix for 6.1 - maybe we can bump the 
requirement to nautilus to

reduce the ifdef'ry further.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]