Thanks for such detailed explanation, that makes sense indeed for me. On Sat, Jun 24, 2023, 00:58 <smooney@redhat.com> wrote:
I wonder what is the reason for such diversification between B and C
As C will be the next SLURP [1] release, meaning A->C upgrades must be supported. So doing a minimal version bump 2 times doesn't make too much sense to me, as long as any platform we have in PTI is not affected. Also my assumption was that all version bumps (or deprecations) ideally should happen during non-SLURP releases.
On Fri, 2023-06-23 at 17:08 +0200, Dmitriy Rabotyagov wrote: then? the short version is nova maintains two version contants for libvirt/qemu version in our code base. our current minium and our future minium so in the b cycle we are updating our current minium to what was our planned future miniutm and we are decided what to set the next annouched future minium too. there is actully no agreement on that specifically but if we were to adapt nova policy to the slurp release cycle we would want to ensure when we select a next min it is shiped in the release notes fo a SLUP release and then yes the actual bump would happen the non slurp or next sulrp release. The cadnace of when we actully do a min bump tend to be every 2-4 releases.
So what's the reason not to do this now and wait for C?
we cant with out breaking our policy of alwasy providing at least one release notice before increaing our min.
the version bump we are doing for bobcat was ment to be done in zed and antelope but got pushed out for differnt reasosn. mainly gate instablity and review badnwith.
we may or may not actully do a version bump in C but by advertising that our future min verions will move to that shiped in ubuntu 22.04. it means if we do decided to bump in C we will actully be testing with the min supported version. canonical assuming they hold to there normally pattern will be release C/2024.1 on 24.04 an also supproting it on 22.04 for upgrades. We will want to keep support for 22.04 libvirt/qemu to ensure a smoth upgrade. but we can raise our min to aling whith what is shiped on 22.04 and what is tested in our ci by doing a second version bump in ci.
The D/2024.2 cycle should see us move to 24.04 as a new base for ci and we can revaluate moving to somehting more modern again at that point.
nova generally support quite a broad range of libvirt/qemu version so while it help reduce our tech debt when we increase our min version, in reality most distros end up shipping a much newer version then we technically support.
[1]
https://governance.openstack.org/tc/resolutions/20220210-release-cadence-adj...
пт, 23 июн. 2023 г. в 16:20, Thomas Goirand <zigo@debian.org>:
Hi,
Repeating what I wrote on IRC.
On 6/23/23 16:10, Kashyap Chamarthy wrote:
- Debian 11 (Bullseye): - libvirt: 7.0.0-3+deb11u2 - qemu: 5.2+dfsg-11+deb11u2
As far as Debian is concerned, the last version of OpenStack supported on Bullseye was Zed (like every 4 OpenStack release and for each new Debian release, there's a version of Zed that I maintain for both Bullseye and Bookworm, to offer easier transitions). Everything above that, needs to run on bookworm. I will *not* do any backport for Debian 11, which is already the past for me. In this case, for Debian 12 (aka: Bookworm) we have:
- Debian 11 (Bullseye): - libvirt: 9.0.0 - qemu: 7.2
So feel free to bump up to that. If needed, I can even do backports myself for these key components, whenever they reach Testing. Probably soon libvirt 9.4.0 (which is already in Experimental, and that will probably soon reach Unstable, then testing).
I hope this helps, Cheers,
Thomas Goirand (zigo)